The account records that save you later
The account records that save you later
Every proxy port I provision gets named to a fixed pattern: a label, the customer’s email, then eight characters of unique id. In a dashboard it looks like clutter. It means that six months later, when somebody asks who a port belonged to before it was recycled, the answer is written on the object itself.
Accounts do not give you that. You cannot name a marketplace profile after the card that funds it, so the record has to be kept somewhere else, by hand, and built to be read at the one moment you cannot log in.
That is the least interesting discipline in this whole subject and it decides more outcomes than the technical layer does.
Eight fields and nothing clever
One row per account. Anything more ambitious dies within a month, because the format that survives is the one you can fill in without thinking at midnight.
- the mailbox the account was created with, written out in full, including the domain
- the payment instrument: type, issuer, last four digits
- the phone number on it, if any, and whether you still control that number
- the device or browser profile it belongs to
- the network path it exits on
- the creation date, to the day
- who has access right now
- what it is for, in one sentence a stranger would understand
That last field does more than it looks like it does. When you are trimming costs, the accounts you cannot describe in a sentence are the ones to close. If you cannot say what it is for, you have answered the question.
Note what the row is missing. No warm up stage, no fingerprint template, no rotation notes. Those belong in an operating sheet, which is a different document with a different job. This one records provenance: where the account came from and what it is tied to.
The two fields that carry the weight
Of the eight, the mailbox and the payment instrument do most of the work, for two different reasons.
The first is that they are the strongest joins between accounts. A card and a recovery address get verified by a party outside the platform, and they are expensive to duplicate honestly, so an account graph keys on them heavily. That is a separate article and I will leave it there.
The second reason gets overlooked. These are the fields you are asked about. When a platform, a payment processor, a bank or a buyer wants to establish that an account is genuinely yours, the questions land on the opening mailbox, the funding instrument, and the creation date. Nobody has ever asked me about a canvas fingerprint.
So record the original mailbox, not the current one. Those drift apart over a couple of years, and the original is the one that appears in the earliest confirmation email and in the platform’s own records.
For the card, issuer plus last four is enough to identify it and useless to anyone who steals the sheet. I spent a year writing “prepaid card” in that column. Then a chargeback landed and I had three prepaid cards active in the month it referred to, and no way to tell which one had paid for what without pulling statements.
A record stored inside the fleet is not a record
This is the one careful people get wrong, and it is worth more space than the rest.
A locked account takes its own history with it. When the mailbox stops opening, every signup confirmation sitting inside it is gone at the same moment. A document in the drive attached to that identity goes with it. Notes kept inside the account’s own notes feature go with it.
So the sheet cannot live in anything it describes. Not in a document owned by one of the fleet’s identities. Not in a mailbox that is also a recovery address for other accounts. Not in a browser profile you might burn next quarter.
Mine used to. For about a year my account map was a spreadsheet in a drive belonging to one of the identities in the fleet, and that same identity was the recovery address for several other accounts. It felt tidy. Everything about that operation lived in one place, which was exactly the problem.
It hit a verification wall on a Tuesday, asking for a phone number I no longer had. At the precise moment I needed to know which accounts depended on that identity, the file listing them was behind the same wall. Rebuilding it took a weekend of bank statements and inbox searches, to recover a picture I had already written down once.
The correction cost nothing. The map moved to a separate identity on separate infrastructure that touches no platform I operate on, and it has stayed there. It also needs a copy on a different machine, restored from at least once, because a backup nobody has tested is a belief.
Pointers, never secrets
No passwords in the sheet. No 2FA seeds, no full card numbers, no recovery codes.
The row holds pointers: a vault item name, four digits, an address, an identifier. Enough to find the thing, never enough to use it. Secrets go in a password manager with per item access. Mine live in Bitwarden, split into collections, so a contractor gets the handful of items their job needs and cannot see anything else.
That split is what makes the sheet usable. A file stuffed with live credentials cannot be opened in front of a contractor or an accountant, so it stops getting read, and a record nobody reads has already failed.
I will say the blunt version, since people do argue with me about this. A shared spreadsheet with real passwords in it is worse than no documentation. It is one file that hands over an entire operation, synced to devices you have never seen, in a share link somebody forwarded once in 2024 and forgot about. I would rather an operator kept nothing.
The folder behind the row
The row is an index. A few things have to be kept whole, in a folder per account.
Keep the original signup confirmation. It carries the date, the address it was sent to, and the platform’s own wording, which is a stronger claim than anything you type yourself.
Keep your copy of any identity document you supplied. If you uploaded a passport page or a business registration to clear a verification, keep exactly what you sent and the date you sent it. Being asked a second time and supplying something slightly different is worse than never having been asked.
Keep receipts and invoices tied to the account. Dull paperwork, and it is what establishes that there is real activity underneath the login.
And export while exports still work. Platform data tools usually keep running through a restriction and stop dead at termination.
Then add one dated line every time something material changes: new payment method, new number, a person added, an automation switched on, moved to a different exit. When something breaks, the useful question is what changed in the week before. Nobody remembers accurately. Everybody thinks they do.
I keep this as a single column with dated entries stacked in it. Ugly and sortable, ten seconds to append. More than once it has pointed straight at a change I had forgotten making.
Access is a name plus a leaving date
The access field has to hold a name. “The VA” is not a name.
It also has a second half most people skip: what happened when that person stopped working with you. Which accounts they touched, what got rotated on their last day, and the date it was rotated. If you cannot answer that for somebody who left six months ago, they still have access and you are guessing at how much.
What a buyer actually asks
Fleets get transferred more often than people plan for. Accounts get sold, a client wants their asset handed back, a partner comes in, an operation gets wound down.
Someone bought ten lines from me recently and paid up front, and before he paid he asked for the activation date on each one. He was right to. My own backlink ledgers work the same way: a TSV where a row marked as placed means I owe that link, and I check it before deleting anything, because a record is the only thing standing between you and destroying an obligation you forgot about.
An operator with a row per account answers a diligence conversation in a few minutes. An operator without one answers confidently from memory and gets caught out on the second follow up question, which reads worse than admitting there are no records.
So here is the position I will defend. I would take a documented account created six months ago over an undocumented one created six years ago. The aged account is a story. The documented one is an asset, because somebody other than the seller can verify it.
The quarterly read
Put a date in the calendar every three months. It takes an afternoon and it runs in two passes.
The first pass checks the sheet against reality. Is that card still live. Is that number still yours, or did the prepaid line lapse and get recycled to a stranger by the telco. Does the mailbox still open. Is the person in the access column still working with you. Records rot silently and nothing tells you when a field has gone stale.
The second pass reads down each column looking for a value that appears twice. Two accounts on one number, two on one card, two pointing at the same recovery address. You will find at least one the first time you do this. Usually the recovery address, sometimes the payout destination.
When you find a repeat, fix it slowly, one account at a time, spread over weeks. Changing the same field across a batch in one afternoon is a loud pattern in its own right.
Accounts churn. Some get banned, some get retired, some get sold. The sheet outlives all of them, and after a few years it is worth more than most of the individual rows in it.
The stack we run and the guides behind it are at Multi Account Ops.
Get new guides and videos first — join the Telegram channel.