Multi-Account Management for Agencies
Running hundreds of client accounts: naming schemes, credential hygiene, proxy allocation, team access and clean handover when a client leaves.
- multi-accounting
- proxy-management
An agency running a handful of client accounts can hold the details in someone's head. At fifty or a hundred, the same operation needs naming conventions, an allocation record and an access model, or it starts losing accounts to avoidable mistakes.
This is the operational side: how to organise accounts, addresses and people so nothing depends on one person's memory.
The three artefacts
Everything else follows from keeping these three in sync.
1. The profile registry. One row per account: profile id, client, platform, country, address binding, assignment date, owner. This is the document you consult when an account is challenged.
2. The address allocation record. One row per endpoint: which profile holds it, since when, and its history. Prevents two profiles sharing an address and prevents a retired address being recycled onto a fresh account.
3. The authorisation record. Which client authorised you to run which account, and when. This is a compliance artefact, not just an operational one, and it is what you produce if a platform asks who operates an account.
Keep all three outside the browser tool. Import databases get lost on reinstall.
Naming that carries its own documentation
A name should tell an operator the facts they need without opening the registry.
<client>-<platform>-<country>-<purpose>-<seq>
For example northwind-instagram-pl-brand-003. Four properties follow from reading the name: who it belongs to, what platform, where it should exit, and what it is for.
Two rules make the convention worth having. The country code in the name must match the bound address, which turns a paste error into something visible. The sequence must be monotonic per client, so gaps indicate a retired account.
Credential hygiene
The rule is one credential per account, held in a password manager with the client and purpose recorded, and never shared between people or profiles.
Specific practices that prevent the common incidents:
- No credentials in chat. They end up in search histories and exports.
- No credentials in the profile name. The browser's profile list is not a secret store.
- Rotate on staff departure, per client, and log which accounts were rotated.
- Separate recovery details per account, since a shared recovery email links accounts faster than any technical signal. The reasoning is in Signals That Link Accounts.
For the endpoint credentials specifically, the two styles and their trade-offs are in Proxy Authentication Explained.
Address allocation
The allocation model has one non-negotiable rule: one account, one address, held for the account's life.
Per client, allocate a block of addresses in the client's country. Assign within the block so a client's accounts share a country but never an endpoint.
Practical constraints:
- Keep the allocation in the client's market. An account registered in one country and operated from another is a mismatch, per Why Antidetect Browsers Need Proxies.
- Use static addresses for accounts that log in regularly. Account work wants stability, and the case is made in ISP Proxies for Account Management.
- Keep research traffic off account addresses. Competitive and rank checks should rotate on a separate pool, as in Proxies for SEO Monitoring.
- Retire rather than recycle. An address that was on a restricted account should not be reassigned to a new one. The reputation travels with it.
The team access model
Three roles cover most agencies, and mapping people to them prevents the usual accidents.
| Role | Can do | Cannot do |
|---|---|---|
| Operator | Open assigned profiles, run assigned accounts | Rebind addresses, add or remove profiles |
| Team lead | Assign profiles, request rebinds, onboard clients | Rotate credentials, change billing |
| Account owner | Everything for that client | Anything for another client |
Two principles sit behind the table. Access follows client boundaries, not seniority, so an account owner for one client has no access to another. And rebinding an address is a controlled action, logged, rather than something anyone does to fix a slow session, because a changed address mid-life is a visible signal, as described in Rotating IPs for Browser Profiles.
Handover
Account handover is where agencies leak value and create risk. A clean handover has five steps.
- Confirm authorisation for the transfer from the client, in writing.
- Rotate credentials for every account changing hands.
- Transfer ownership at the platform level through each platform's own mechanism, not by handing over a login.
- Record the address reassignment or release it, and retire anything that was on a restricted account.
- Archive the profile metadata, keeping the operational history for reference and deleting what you no longer need.
The archive step matters for the retention side of Data Collection Ethics for Engineering Teams, since client account records are business data with a retention question attached.
Scaling the operation
Three signs that the process needs tightening, all of which appear before a serious incident: an account is challenged and no one can say which address it used, two profiles turn out to share an endpoint, and a departed operator's credentials are still active.
Each maps to one of the three artefacts. If the registry, the allocation record and the authorisation record are current, none of them happens.
For the platform-specific guidance, see Managing Multiple Social Accounts Safely, Managing Multiple Gmail Accounts and Managing Multiple Facebook Ad Accounts. For the solution context, Multi-Accounting.