Translated from the Japanese original on mureo.jp.
“The operator changed and suddenly the same account performs differently.” If you look after multiple clients at an agency, you have probably run into this at least once. Quality varies by operator and decays at every handover. A veteran’s instinct stays inside that one person.
Chalk the cause up to “differences in operator skill” and the only remedies left are hiring and training. But much of what is actually going on is a matter of mechanism rather than skill. What a judgment was based on is not recorded, so the next person cannot reproduce it. Here we break down why multi-client operations become key-person dependent — that is, dependent on one specific individual’s undocumented knowledge — and what to design in order to level quality.
Why key-person dependency happens
The criteria for judgment live only in someone’s head “This client prioritizes conversion volume over CPA.” “This product peaks in September.” These premises usually sit in the operator’s memory. Because they are not written down, whoever takes over judges from the numbers alone and cannot arrive at the same conclusion.
It runs on instinct rather than procedure The more experienced the operator, the more the way of spotting anomalies and the order of remedies is in their body. Being able to move quickly is an advantage, but that speed disappears without ever being explained.
The reason for a change is not recorded The console keeps a record of what was changed, not why. Looking back six months later, you cannot tell the intent at the time, so you cannot judge whether it is safe to touch.
Every client has a different context Take on ten companies and you have ten sets of circumstances. They cannot be reduced to a company-wide manual, and individual notes do not get shared. The middle ground is what tends to be missing.
Common remedies, and their limits
Write manuals They help, but platform specifications keep changing, so a manual starts going stale the moment updates stop. You need to budget for the cost of maintaining it.
Automate reporting Working hours definitely go down. But what goes down is the effort of aggregation; judgment stays with the human. It does not reach the substance of key-person dependency.
Add people You get more hands, but adding people without criteria actually widens the variance.
None of these are wasted; it is a question of order. Adding tools or people before setting criteria is unlikely to produce much effect.
The foundation for running multiple clients in parallel
Before getting to leveling quality, a word on how the foundation is built. Handling ten companies mixed together in one place makes accidents likelier to begin with. When we built the mureo ad-ops platform, this separation was the first thing we decided.
Separate the working environment per client Isolate one client as one environment. Numbers, settings, and accumulated knowledge do not mix. Whether it is five companies or fifty, only the number of environments grows; the shape of operations itself stays the same.
Authenticate once, and override only where needed Connect Google’s MCC or Meta’s Business Manager once at the operator level, and override only for clients with particular circumstances. Redoing authentication every time a client is added is friction that compounds with volume, so it is worth eliminating up front.
See the state of every client at a glance, first thing Opening every client’s console one after another eats the whole morning. Line them up by state — healthy, watch, needs attention — so you can start with the accounts that need you.
Designing to level quality
Once the foundation is in place, decide these four. This is the part that bears directly on key-person dependency.
1. Put the criteria for judgment in a file that every diagnosis references Write out persona, strengths, brand thinking, and goals into one file per client. What matters is not stopping at writing it. Unless daily diagnosis always references that file, the criteria just sit there unused. Make it referenced and judgment shifts from “cheapest CPA first” to “closest to the business goal first.”
2. Make read-only the default and state the scope of delegation explicitly Letting a brand-new operator touch budgets and bids straight away is too risky. Set the default to viewing and proposals, and put approval in front of changes. Also make it possible to flip the whole environment to read-only with a single switch, so you can widen what you delegate safely. Leave diagnosis and reporting running; stop only changes. During training, in a screen-shared meeting, or in a sensitive delivery window, this shape is practical.
3. Record changes in a form you can revert What was changed, why, and when. Keep it append-only, and make it possible to roll back when needed. The console’s change history does not keep the “why,” so this fills that gap. The history of judgment carries over when operators change, and you can answer a client’s questions with a record.
4. Split knowledge into two layers: operator-wide and per client This one is a source of accidents if you do not split it. Mixing insight that applies to all operators, like “here is how to think about bidding,” with individual circumstances, like “this client peaks in September,” lets one account’s premises leak into another. Split the layers, share the common layer across the team, and keep the individual layer closed inside that client. In this shape, judgment stays consistent as the team grows, and knowledge stays with the company when operators change.
Before you bring in AI
Delegating operations to an AI agent has recently become a realistic option. The speed of the work definitely goes up. But delegate without the four points above and the AI will look only at the surface of the numbers and quickly execute changes that look plausible. The faster it is, the faster the mistakes spread.
Put the criteria for judgment in place before you bring in the tool. The order is the same here. Bringing AI into real operations is covered in Can you automate ad ops with Claude Code?.
Summary
Key-person dependency is less a problem of operator ability than a problem of a mechanism that does not record judgment. Separate environments per client, put criteria in a file and have it referenced, decide the scope of delegation, keep changes and their reasons, and split knowledge into two layers. With these in place, quality is less likely to drop when operators change, and you get out of the state where every new hire widens the variance. Building this design in from the start is also why we build mureo.