Half a Day of Nothing

The question

I keep watching companies flip between these two setups every couple of years, and I don't think either side is being unreasonable. The debate just runs on instinct, so it ends up wherever the most senior person in the room already was.

On the setup below, the math comes to about sixteen people, which was more than I expected.

Picture ten clients, each with support written into the contract. Give every client a named person who learns their quirks. Or build one shared team that covers everything and shares what they learn.

Both are defensible, and which one is right for you changes as you grow.

The obvious objection is fair: when a client has a real emergency, nobody wants to be handed to whoever's free and start explaining from the beginning. A dedicated pod gives them somebody who already knows, and that matters. The math below doesn't price it, so there's a section near the end that tries to.

I'd still do the math first, because it's the only way to find out what that's costing you.

Or skip ahead to the calculator →

The two numbers that decide it

You probably know both of them roughly already. The first is how much work each client generates, counted in people rather than tickets. The second is how much slower a shared person is on anything that needs client-specific knowledge. That second one is the whole case for pods, so it's the one to pin down. I call it the context penalty.

The chart shows how big that penalty has to be before pods come out cheaper.

At two people's worth of work per client, a shared person would have to take 73% longer on every request, all day, including the routine ones.

Each client sends enough work to keep two people busy, but two people can't cover it. Requests arrive in clumps, so somebody has to be free when three land at once. A pod needs four: two working and two in reserve. Ten of those is twenty working and twenty in reserve. Forty people.

Pool all ten clients and the reserve gets shared, because one client's quiet hour covers another client's bad one. The same twenty people's worth of work now needs four in reserve instead of twenty. Twenty-four people.

So pooling starts sixteen people ahead, all of it reserve you're no longer buying ten times over. The shared team only loses that lead if it gets slow enough to need forty people anyway, and that's 73% slower.

The gap comes almost entirely from ten small teams each buying their own reserve, against one team that buys it once.

Most estimates of that penalty land around twenty or thirty percent. Even at thirty, you're nine people better off pooling.

Why the gap is so big

Pooled people don't work faster. Dedicated people just spend more of the day waiting.

Those sixteen people were reserve, sitting in ten separate places waiting for a clump that mostly didn't come.

The pod runs at 50% occupancy, the pooled team at 83%. The chart below shows both over a working day.

Where pooling stops helping

Pooling works by covering one client's bad week with another client's quiet one. That only holds if the bad weeks fall in different places.

The second force: reuse

In some functions, reuse matters more than everything above.

In a reporting team, somebody structures the query once and builds the report once, then filters it per client, so the second client costs almost nothing and neither does the tenth. Split that into pods and ten people end up building the same thing.

Eight times the hours, for the same fifteen reports. And it turns up anywhere there's a build step: reporting, templates, playbooks, onboarding material, QA rubrics, tooling, the deck somebody rebuilds every quarter.

Putting the two together

Combine them and you get one number you can work out in your head. Reusable work doesn't carry a context penalty, because a query doesn't care whose data it's filtering. The slowdown only applies to the one-off part.

Say 30% of the work is one-off, and a shared person is 40% slower on that part. Then your real penalty is 40% of 30%. That's 12%.

The crossover for a client this size was 73%. Twelve is nowhere near it, so you pool. That's the whole calculation, and it's what the sliders below do.

Try it with your numbers

What the math can't price

Everything above is about cost, and cost is the easy part to measure. Three things sit outside it, and any one of them can outweigh the headcount you'd save.

Somebody to call. When a deal is on the line, nobody wants to start from the beginning with a stranger. A pod buys a named person, for the client and for your own account team. That has real value, even if it doesn't show up on a spreadsheet.

Switching cost. The model assumes a request takes the same time whatever came before it. A pooled operator jumping from a regulatory edge case to an onboarding setup to a broken pipeline before lunch is paying a recovery penalty. It doesn't show up in handling time. It shows up as errors and rework, and the model has no line for either.

Whose emergency wins. In a pod, priority is local and obvious. You have one client, so you work on their most urgent thing. In a pool, two critical requests arriving together is a judgment call somebody makes in public, every time.

The whole argument, on one chart

Two questions place any function on this chart: how much work one client generates, and how much of the work gets built once and reused. The line between the two regions comes from the crossover math earlier.

How to run this

This is roughly an afternoon if your ticket data isn't a mess, and most people can stop at step three.

1. Pull 90 days of requests by client. Your ticket system already has this. Resolved items, grouped by account.
2. Turn volume into people. Count times average handle time, divided by the hours one person works in that window. That is the bottom axis of the chart above.
3. Tag fifty tickets reusable or not. You don't need ninety days of them. Fifty is enough to tell 20% from 70%. If reuse comes back high, stop here, centralize the build, and the rest of this barely matters.
4. Estimate the penalty on the bespoke part. Compare handle time when somebody who knew the account picked it up against somebody who didn't. If assignment has always been dedicated you'll have to guess, which is fine. Move the slider above and see whether your guess changes the answer. Usually it doesn't.
5. Put each client on the chart. Load along the bottom, reuse up the side. Most will land well inside pool, and the ones that don't will be obvious.
6. Price the premium on the ones that don't. Headcount difference times loaded cost, against the revenue on the accounts you'd be moving into a queue. That is the number you take into the room.