Capacity, Not Headcount

The fourth slide of the steering committee deck had one number on it: 3.5 FTE, or full-time posts. The project was an order desk automation for a distributor, and the finance lead had worked out that reading, checking and typing in orders took three and a half people's time. The first question, as in many first meetings: how many posts does this save?

The more useful question: how many quotes went out late last quarter, and how many of those customers ordered somewhere else? No report held that number. Everyone knew the two people sales called when a customer wanted something off-catalogue. They set the pace, and the slide had no line for them.

The headcount case is the easiest number to write

A headcount saving is certain, immediate and fits on one slide; salary times people is a number finance already trusts. Erik Brynjolfsson explained the pull in "The Turing Trap" (Dædalus, 2022): labour is the largest visible cost, and replacing a task avoids the harder work of redesigning how the operation runs. The other side is invisible: a late quote leaves no trace in any report; the customer simply orders elsewhere. Once the saving is counted, the operation is sized for the demand it had on the day of the cut.

That works for a business that plans to stay the size it is. Many don't: they have more orders coming, a new market to open, a large customer wanting faster turnaround. For them the question is how much more demand the same operation can take on, and how fast. A project built to remove two people answers with a smaller team and a system that has stopped learning.

Cheap answers make knowledge the scarce input

Reading an invoice or drafting a reply now costs very little, and every competitor can buy the same AI. What separates one distributor from another sits elsewhere.

At the order desk it sat with two people. One knew which substitutes each large customer would accept without being asked. The other could tell from the wording of an email that a buyer was comparing quotes and needed an answer that afternoon, not on Thursday. Neither was written down, both decided whether orders were won, and an AI reading the emails had access to neither.

We start from the step that limits demand

We start from the step that limits how much demand gets served, not the biggest block of effort: the queue that makes customers wait, the check only one person can do, the report that arrives too late to act on.

To find it, we pull timestamps from the order or ticket system and look for where work waits, not where it's worked. Then we ask the team one question: when something unusual comes in, whose name gets said? Where the waiting and the same two names meet, that's usually the bottleneck.

At the order desk, it wasn't order entry. It was the off-catalogue and special-terms cases, which waited for one of two people and held up everything behind them. So the system reads every order, checks it against the catalogue, the price agreement and stock, and puts the routine ones through. The hard cases reach the two experts with the groundwork done: the customer's history, the likely substitutes, the margin at stake. They decide, and their day moves from typing in easy orders to the cases only they can settle.

What the experts see matters as much as which cases they get. A field experiment with 758 BCG consultants (Dell'Acqua and colleagues, Harvard Business School, 2023) found that on a task just outside what the AI could do well, consultants using it were 19 percentage points less likely to reach the right answer than those working without it. The cases we send to experts tend to be exactly those, so there the system brings the evidence and doesn't propose an answer. The expert reads the history and the margin, not a suggestion to agree with.

The trap is sending everything unclear to the experts. The bottleneck has then moved, not gone. We limit what reaches them to cases where their knowledge changes the answer, and we track how long their queue waits as a measure of its own.

The system spreads expert judgement

Exceptions go by subject, not by who is free: substitutes to whoever knows that customer's products, terms to whoever negotiated the agreement. Each decision is stored as a small record: the system's proposal, the expert's action, a reason code and one line of text. Every week we sort those records by reason. A reason that repeats becomes a rule. A case where the expert overruled the system becomes a test case it must pass before any change goes live.

Instinct gets the same treatment. When an expert holds an order because it doesn't look right, we ask for one line on what they saw. Often it's a pattern nobody had named: a new delivery address on a large first order, a price request that undercuts every earlier one. Once named, it's checked on every order, not only the ones that expert happens to see.

Over time, a newer colleague sees the same evidence and earlier reasoning on each case. Brynjolfsson, Li and Raymond studied an AI assistant in a customer support team ("Generative AI at Work", NBER, 2023) and found the largest gains among less experienced support agents. Their evidence suggests the tool carried the practices of the best agents to everyone else. Routing by subject and turning decisions into rules aim at the same effect.

It takes expert time, and we put it in the plan: about an hour a week per expert in the first months for the reason review, falling as the rules settle. Leave those hours out, and the system stops improving early.

What we tell the CFO who asks for the headcount case

The value statement agreed before the build carries three or four of these:

• Demand served. Orders, quotes or cases cleared within the target time at the peak, with the same team.
• Response time. From customer request to useful answer, taken from system timestamps.
• Work turned away or delayed. Quotes past their promised time, orders lost with "no response" as the reason in the sales system, cases escalated because the team was full.
• Room for the next step. Whether a new market, customer or product line can be taken on without a new team to run it.

Where volume doesn't grow, the same capacity shows up as hires not needed as it rises. What to do with it is the business's decision.

What we decline

We turn down work where the only stated goal is a smaller team, because the system needs the corrections of the people that plan removes. We also decline a quieter version of it: building a system on corrections from experts who already know they're being replaced. Their corrections thin out, the edge cases go unnamed, and the system learns mainly the easy ones. And we don't report posts saved as the headline number, even when asked. Time saved can sit in the detail.

Two salaries saved is a number that stops moving the day it's counted. Two experts who spend their week on the cases that need them can find the next bottleneck.