How to Structure an Agency Workspace for Multiple Clients

Every guide to setting up an agency workspace starts in the same place: create a project per client. It is the obvious move, it works for about four clients, and it quietly becomes the reason your process stops improving. By the tenth client you are not running one agency, you are running ten slightly different ones, and nobody can afford to fix all of them at once.

What is the actual unit of an agency workspace?

The repeatable delivery, not the client. Clients are data — names, rates, contacts, scope, what they are allowed to see. The delivery is the thing you have opinions about, improve over time, and want identical everywhere, and it is the thing a per-client structure quietly forks.

In Atwork that distinction is the whole design: the process lives in the sheet and its views, while the client is a field on the work. One board, filtered fourteen ways, rather than fourteen boards that drifted apart.

Look at the stage names in the top half. Brief, production, approval. Brief, in progress, review. Intake, production, sign-off. Nobody decided those should differ; three people set up three clients in three different weeks. Now no report spans all of them, and no new hire can learn one process.

Which parts should be shared, and which should vary?

One question per item settles it: does this genuinely change for every client, or should it be identical everywhere? Most things people copy per client belong in the first column, and copying them is what creates fourteen maintenance jobs.

The test is maintenance, not neatness. If improving something means editing it in more than one place, it is in the wrong column — and you can predict with total confidence that it will be improved in one place and not the others.

• Stages and what they mean belong to the agency. A client does not get their own definition of "in review".
• The brief format belongs to the agency, because it is how work gets started correctly.
• The definition of done belongs to the agency, and it is the single highest-return thing on the list.
• Scope and exclusions belong to the client, and they genuinely differ — see how to stop over-servicing retainer clients.
• Visibility belongs to the client, and it is a permission rather than a structure.

Doesn't a shared workspace leak one client's work to another?

No, and this is the assumption that drives most of the duplication. What a client can see is a permission question, answered by what you share with them, not by where the rows are stored. Those are two different problems, and solving the first with the second is what costs you the process.

This matters because the fear is real and the remedy is wrong. Nobody wants Kestrel reading Northwind's work. But an internal board holding both, with a client portal that exposes exactly one, achieves the isolation the client cares about while leaving you a single process to run. What your client should actually see in a portal covers where that line sits.

If your answer to "can they see each other's work" changes how your team's own board is built, you have let a permission question redesign your operations.

What about the client who really does work differently?

Some do, and that is a real exception rather than a reason to fork everything. The honest version is to write the exception down as an exception — this client approves in two stages, this one wants Friday reporting — and hold it as data on that client, so it is visible and reversible.

The failure to avoid is the silent fork: someone adds a stage for one client, nobody records why, and eighteen months later no one can tell whether it is a genuine requirement or an accident. An exception with a reason attached can be reviewed. A duplicated board cannot, because nobody remembers what was deliberate.

That last row is a real concession. If most of your clients genuinely run on unrelated processes, per-client structure costs you less, and you should weigh it honestly rather than take our word for it.

How do you add the fifteenth client without a setup day?

Make the setup a template rather than a memory. Adding a client should be adding a row and applying a template that creates the standing work — the recurring deliverables, the reporting cadence, the onboarding checklist — rather than someone recreating last time's structure from a copy.

The practical test is whether a new client can be running correctly without the person who set up the last one. If the answer is no, your structure lives in somebody's head, and that person is now a dependency for growth as well as a flight risk. The agency client onboarding checklist covers what that first week should contain.

What does this mean for reporting?

Everything, which is why it is worth getting right before you have fourteen clients rather than after. Cross-client questions — who is over capacity, which accounts are slipping, where the month actually went — are trivial when all the work sits in one structure and impossible when it does not.

This is the quiet cost of per-client workspaces. It is not the setup time; it is that the questions you most need answered as you grow are exactly the ones a forked structure cannot answer. Agency capacity planning and agency utilisation rate both assume you can see across clients at once.

Where should you start this week?

Open two of your client setups side by side and list every difference. Then mark each one deliberate or accidental. Most agencies find that nearly all of them are accidental, which is good news: accidental differences can be standardised without a conversation with anyone.

Pick the single stage name that differs most and make it the same everywhere. That one change makes your first cross-client view possible, and the view is what makes the rest of the argument for itself.

The Agency Client Delivery template ships this structure already built, and the agencies overview covers the wider setup.

List the differences between two client setups and mark each one deliberate or accidental. Standardise the accidents this week. Start free