Half a Day of Nothing

The question

I keep watching companies flip between these two setups every couple of years, and I do not 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. Nobody brings a number.

So I worked one out. On the setup below it comes to about sixteen people, which is 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.

Before any of the math, the obvious objection, and it is a fair one. When a client has a real emergency, nobody wants to be handed to whoever happens to be free and start explaining from the beginning. A dedicated pod buys them somebody who already knows, and that is worth something real. The math below does not price it, which is why there is a section near the end that tries to.

It is still worth doing the math first, because it is the only way to find out what that is costing you.

Or skip the argument and go straight to the calculator →

The two numbers that decide it

It comes down to two numbers, and 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 is the one worth pinning down. Call it the context penalty.

So: how big does the penalty have to be before pods are actually cheaper?

At two people's worth of work per client, a shared person would have to take 73% longer. Not on the awkward tickets. On every single request, all day, forever.

Here is where that comes from. Each client sends enough work to keep two people busy, but two people cannot 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 ahead, and every one of those sixteen is reserve you no longer buy ten separate times. The shared team only gives that back by getting slow enough to need forty anyway, and 73% is how slow that is.

So almost none of it is about how fast anybody works. It is 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 are nine people better off pooling.

Why the gap is so big

None of this is because pooled people 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 did not come.

Which shows up as occupancy. The pod runs at 50%, the pooled team at 83%. Put that on a clock and it stops being a percentage.

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, which is bigger

There is something else going on, and in some functions it dwarfs everything above.

Think about 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 is a build step: reporting, templates, playbooks, onboarding material, QA rubrics, tooling, the deck somebody rebuilds every quarter.

Where the two forces meet

Put the two together and you get one number you can do in your head. Reusable work does not carry a context penalty, because a query does not care whose data it is filtering. The slowdown only ever applies to the one-off part.

Say a third of the work is one-off, and a shared person is 40% slower on that part. Then the penalty you actually pay is 40% of a third. About 12%.

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

Try it with your numbers

What the math cannot 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 be worth more than the headcount it saves.

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 is worth something real even when it is worth nothing 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. Handling time never moved. It shows up as errors and rework, and there is 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 judgement call somebody makes in public, every time.

The whole argument, on one chart

Two questions put any function somewhere on this. How much work does one client generate, and how much of the work gets built once and reused. The line between the two regions is the crossover math from earlier rather than my opinion.

How to actually run this

This is roughly an afternoon if your ticket data is not a disaster, 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 actually works in that window. That is the bottom axis of the chart above.
3. Tag fifty tickets reusable or not. Fifty, not ninety days of them. 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 did not. If assignment has always been dedicated you will have to guess, which is fine. Move the slider above and see whether your guess even changes the answer. Usually it does not.
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 do not will be obvious.
6. Price the premium on the ones that do not. Headcount difference times loaded cost, against the revenue on the accounts you would be moving into a queue. That is the number you take into the room.