Capacity, Not Headcount

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

The more useful question was a different one. How many quotes went out late last quarter, and how many of those customers ordered somewhere else? That number was not in any report. Everyone knew the two people sales called when a customer wanted something off-catalogue. Those two people set the pace for the business, 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 line, and replacing a task avoids the harder work of redesigning how the operation runs. The other side of the ledger is invisible by construction. A quote that went out too late leaves no line in any report; the customer simply orders elsewhere. Once it is booked, 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 businesses paying for automation do not. They have more orders coming, a new market to open, a large customer asking for faster turnaround. For them the question is how much more demand the same operation can take on, and how fast it can respond. A project scoped to remove two people answers with a smaller team and a system that has stopped learning.

Cheap answers make context the scarce input

Reading an invoice, classifying an email or drafting a reply now costs very little, and every competitor can buy the same models on the same terms. The part of the work that separates one distributor from another sits elsewhere.

At the order desk it sat with two people. One knew which substitutions 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 piece of knowledge was written down, and both decided whether orders were won. A model reading the order emails had access to neither.

We start from the step that caps demand

We start from the step that caps demand 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 ticketing system and look for where work waits, not where it is 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 is usually the constraint.

At the order desk, the constraint was not order entry. It was the off-catalogue and special-terms cases, which waited for one of two people and set the pace for 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 substitutions, the margin at stake, and they decide. Their day moves from keying easy orders to the cases only they can settle.

What the experts see on those cases 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 model 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 the ones outside that frontier. So on those cases the system brings the evidence and does not propose the answer. The expert reads the history and the margin, not a suggestion to agree with.

The trap in this design is sending everything unclear to the experts. Then the bottleneck has moved, not gone. We cap what reaches them to cases where their knowledge changes the answer, and we track the age of their queue as a measure in its own right.

The system is built to spread expert judgement

Exceptions route by context, not by who is free: a substitution question goes to the person who knows that customer's product line, a terms question to the person who negotiated the agreement. Each decision is stored as a small record: what the system proposed, what the expert did, a reason code and one free-text line. Every week we sort those records by reason. A reason that repeats becomes a rule. A case where the expert overruled the system becomes an evaluation case, and the system has to pass it before any change goes live.

Instinct gets the same treatment. When an expert holds an order because it does not look right, we ask for one line on what they saw. Often it is 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 is checked on every order, not only the ones that expert happens to see.

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

This takes expert time, and we put it in the plan rather than hoping for it: about an hour a week per expert in the first months for the reason review, falling as the rules settle. A project that budgets the build and leaves out the hours of the people who teach it tends to get a system that 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 CRM, 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 does not 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 the same thing: building a system on corrections from experts who already know they are being replaced. Their corrections tend to thin out, the edge cases go unnamed, and the system learns mainly the easy cases.

And we do not report FTE saved as the headline number, even when asked. Time saved can sit in the supporting detail.

A saving is booked once

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