Running multi-account operations as a team

The system you already have

Most desks that run accounts on behalf of other people arrive at the same three tools without deciding to. A spreadsheet lists the accounts. A password manager holds the logins. A group chat is where the work actually happens. None of the three is a mistake; the problem lives in the seams between them.

The spreadsheet is accurate as of whenever somebody last edited it. The password manager knows who can open a vault, not who used a credential at eleven on a Tuesday. And the group chat is where credentials end up anyway: a pinned message with a login in it, a screenshot of a one-time code, a "can you get into the client's ads account for five minutes". It all looks like it is working right until one of three days: the day a contractor leaves, the day a client asks who touched their account, the day an account is restricted and nobody can reconstruct why.

What follows is a way of running that desk. Most of it is practice rather than software, and where Argus does not do what the playbook wants, that is said.

One account, one profile, and a name a stranger can read

The unit of work is not a login, it is a browser profile: its own storage, its own cookie jar, its own device identity, its own exit address. Two accounts in one browser are, to the platform, one account, linked on the first page load. The mechanics of why are a separate subject; the rule is one account, one profile, with no exception for "just to check something".

Then name it so somebody who joined on Monday can read the list on Tuesday. Three parts, ordered by how often you filter on them: <client> · <platform> · <market or role>, giving Northwind · Meta Ads · UK and Ridgeline · Amazon Seller · DE. Dull, correctly sorted, legible without anybody being asked.

Four fields do the organising around that name. In Argus: a folder, up to five tags, a status label you invent yourself, free-text notes.

Field	What it holds	Rule
Folder	The client or the brand	A profile lives in exactly one. If you want it in two, you want a project
Tags	Platform, market, risk tier	Three in practice. A sixth tag is a folder trying to happen
Status	Where the account is in its life	warming, live, resting, restricted, retired — agreed once
Notes	Anything that would otherwise be a message	Who set it up, whose entity it belongs to, what support said in March

A status is only worth having if changing it is somebody's job. Decide who moves an account from warming to live, and on what evidence, or the column is decoration within a month.

Folders file things; projects hold a job together

A folder answers where do I file this. It tidies one list, and a profile sits in exactly one. That is right for a client and wrong for a piece of work, because a piece of work is never only profiles: it is the proxies behind them, the cookie sets that keep them signed in, the automations that run them and the table those automations fill, each on a different screen.

A project answers what is this for. It spans every tab, and the same shared proxy can serve more than one, which a folder cannot express. What makes it safe to use liberally is that membership is a link rather than a move: adding a profile to a project does not take it out of its folder and does not stop it working anywhere else. Deleting the project deletes the grouping and nothing else. When a piece of work ends, archive it instead.

So: folders by client, projects by engagement. Pick the project on any tab and the tab narrows to its things, which is how somebody on a roster of four hundred profiles sees only the eleven that are theirs this week. But narrowing a view is a working scope, not a permission boundary.

Hand over the account, not the password

The reason to stop sharing logins is attribution: an action taken with a login six people know is an action nobody performed. The NCSC puts it in one line — "sharing accounts negates the benefit of authenticating a specific user" (NCSC password guidance) — and Google says the same about its own product: "If many people need to use your Google Ads Account, don't have them share the same username and password" (Google Ads Help).

The practice that replaces it is four steps.

1. One person signs in by hand, the slow way, with the second factor on their own device.
2. Save that session as a cookie set.
3. Assign the set to the profile. It is now part of what the profile is, alongside its fingerprint and its proxy.
4. Give the next person the profile. Not the password.

The cookies are seeded into the session at launch, so whoever opens the profile lands already signed in. The designer swapping a creative and the account manager pulling a report both get inside without holding the credential, and without waiting on the phone that receives the codes. That is session import doing an organisational job rather than a technical one.

Four limits, because a team that does not know them meets them at the worst moment:

• A saved session is a credential, not a limited copy of one. Whoever opens that profile can act as the account: post, delete, reply, read the private inbox. Hand a profile over as carefully as a password.
• Sessions expire. A password change, a platform security sweep or a sign-out elsewhere ends one, and somebody signs in by hand again. Normal, not a fault.
• Signing out inside the profile ends it for everybody. Say this on day one.
• A bad leaver is not revoked by unassigning a profile. Change the password, force a sign-out everywhere, rebuild the session. NIST names the obligation directly: change shared authenticators "when individuals are removed from the group" (SP 800-53 Rev. 5, AC-2).

One point specific to advertising, which agencies get wrong in the contract more often than in the tooling. Where a platform offers a real delegation model, take it instead of a shared session. Meta's business portfolios let a client keep the ad account and the Page and grant your business partner access to them (Meta Business Help Centre). Google Ads is blunt about ownership: even where your manager account owns a client account, "the client account still owns its data and has the ability to remove ownership access by unlinking" (Google Ads Help). Write that into the engagement on the way in. Keep profiles and cookie sets for the long tail with no delegation model at all.

Onboarding a contractor: the first hour

Two facts about Argus shape this list. Seats belong to a workspace rather than to a person, and the workspace carries the plan (seat counts by tier). And a member of a workspace can reach the workspace: there is no way today to grant somebody profiles but not proxies. Scope is a convention, not a lock.

• Check the machine first. Argus runs on Apple Silicon Macs and on Windows; there is no Linux build and no mobile app. A day-zero conversation, not a day-three surprise.
• Add the seat and record the date. It keys the offboarding list.
• Walk the naming convention and the five status words before they touch a row.
• Hand over one project — its profiles, its runbooks, its table — not a tour of the workspace.
• State three rules out loud: never sign out inside a profile; never open a client account outside its own profile; never reuse a proxy across clients.
• If they will drive the app from their own scripts, issue them their own key for the local API, scoped to the folders you name and revocable. That is the one genuine per-person boundary Argus has today.

Offboarding is the same list, backwards

Revocation on the day is the one thing every framework agrees on. CIS Safeguard 6.2 asks for a documented process for "revoking access to enterprise assets, through disabling accounts immediately upon termination, rights revocation, or role change of a user" (CIS Controls v8.1). Run it identically every time, including amicable departures: a procedure you only follow when worried is one you have not tested.

• Remove the seat first, before the handover conversation.
• For every account they could open, decide rotate now or rotate later and write the decision down. A bad leaver means everything rotates now.
• Rebuild the cookie sets for anything rotated and reassign them to the same profiles.
• Revoke the API keys they created.
• Withdraw partner access on the platforms that grant it, in both directions.
• Move the profiles they held to a status the next person will read, so nothing sits in live with nobody on it.
• Reassign the projects. One with no named owner is an account that quietly stops being warmed.

The hard part is one Argus cannot help with. There is no activity log, so you cannot go back and ask what somebody opened in their last fortnight. Which is why the control is rotation rather than investigation: if you cannot audit the past, shorten the window in which the past matters.

Write down four things

Written practice fails predictably: somebody documents the setup once, nothing updates it, and six months later it is actively misleading. Keep the writing small and beside the work.

Site reliability engineering has the most developed version of this habit, and its definition transfers. Google's SRE Workbook describes a playbook as "high-level instructions on how to respond to automated alerts" and says such guides "reduce stress, the mean time to repair (MTTR), and the risk of human error" (SRE Workbook); PagerDuty publishes its internal version for the same reason, to "prepare new employees for on-call responsibilities" (PagerDuty). Substitute "a restricted ad account" for "an automated alert" and nothing changes. A runbook is written for somebody tired, under time pressure and without your context.

Four documents, and no fifth until you have missed one.

The register. One row per account: the label, the sign-in address, the market it is registered in, which profile holds it, which proxy that profile uses, whose legal entity it belongs to. Everything else references this. In Argus it is a dataset — a table the workspace owns rather than a file on one laptop, which an automation can read and write back into.

The rules of the site. What does this platform, in this market, actually permit? Some marketplaces allow a second seller account outright, some on written approval, some not at all. Record the answer, the date and the wording, because "I think it's allowed" is not a record. Argus keeps accounts you are entitled to run from contaminating each other; it does not turn an account you may not hold into one you may, and our acceptable use policy draws that line in the same place.

The procedure. How to do the thing that keeps going wrong: rebuilding a session, warming a new ad account, checking a proxy before you trust it. Four headings work — what this is for, the steps, what the outputs mean, what it deliberately does not do. The last is the one people skip and the one that prevents the most damage.

What broke, and what it looked like. A selector that moved, an account with a quirk, a dashboard that words a suspension differently from every other. This makes the second incident cheaper than the first.

The starter packs ship in this shape, so load one and rewrite it rather than starting from a blank page. One caveat to design around: a project's brief, notes and runbooks live on the machine you wrote them on and are not synced. Teammates see the project and everything linked into it, but not those notes — so anything the desk depends on has to be copied somewhere the desk can reach.

The weekly review

Thirty minutes, the same slot, one person driving. The NCSC asks that account management include a "'joiners, movers and leavers' policy, so access can be revoked when no longer needed, or changed for movers" (10 Steps to Cyber Security); CIS puts a floor under the cadence, asking you to validate active accounts "on a recurring schedule at a minimum quarterly" (Safeguard 5.1). On a desk this size, quarterly is too slow.

Look at	Where	What "bad" looks like
Proxies	The proxy library	A failed check, an exit that changed country, a term expiring inside a week, a datacenter exit where you intended residential
The calendar	Schedule	Days marked missed, meaning the machine was closed
Statuses	The profiles list	Anything still warming after six weeks, or live with no owner
People	The workspace members	Anybody who left, and anybody who joined without going through the onboarding list
The register	Your dataset	Rows reading signed out, and rows with no profile, market or owner — the accounts nothing will ever check

Scheduled entries fire only while the launcher is open, and a slot it was closed for is marked missed and skipped rather than caught up later. Rightly so: a scrape due at 03:00 running when somebody opens a laptop at 09:00 is a surprise rather than a service. But it makes "was the machine awake" a real weekly question.

What you can and cannot audit today

Three questions come up in every review of a shared-account setup. Answered honestly, for Argus as it stands:

Who has access? The workspace member list, exactly. Seats and the subscription belong to the workspace rather than to a person, and only the owner can buy — worth knowing before somebody creates a second workspace and expects it to inherit a plan.

What can this person reach? Everything in the workspace. There is no per-resource permission model: no read-only folders, no profiles-but-not-proxies. If your decision depends on that, it is a no rather than a nearly, and the teamwork page says so in the same words.

Who launched this profile last Tuesday? You cannot answer that. There is no activity log.

Which leaves the audit trail you write yourself: the register, the notes on a row, the status labels, and the rows an automation files as it goes. That is a records discipline rather than a logging feature, and it holds only if updating a row is part of the work rather than something attempted at month end. A client who requires demonstrable per-user access control is met with contracts and platform-native partner access, not with a browser.

The one-page version

1. One account, one profile. Never two accounts in one browser.
2. Name profiles client · platform · market, and hold the convention.
3. Folders by client, projects by engagement.
4. Five status words, agreed once, and one named person who moves them.
5. Nobody gets a password. They get a profile that opens signed in.
6. Where the platform offers partner access, take it and put it in the contract.
7. Onboard against a written list, machine check first.
8. Offboard against the same list backwards, on the day, every time.
9. Keep four documents: the register, the rules, the procedure, and what broke.
10. Thirty minutes a week: proxies, sessions, missed days, statuses, people, gaps.

None of that requires our software. It requires somebody to own it. The tooling only decides how much of it you do by hand — and if you want the version with the accounts, proxies and cookie sets already in one place, the agency setup is this playbook with the screens attached.