In a supplier's demo, each incoming case (an invoice, a customer email, an order) arrives, the system reads it, matches it against the records, and closes it. Then the next one, and the one after that. The supplier is not cheating. Those cases really do clear, and they really are the bulk of the volume. What nobody opens is the other folder: the cases the system passed over.
There is a familiar argument that the hours an automation saves never show up in delivery, because nobody decided in advance where they should go. This piece is about something harder than that. Automation can add work. The cases it cannot handle come back to a person, in smaller numbers, usually harder, and often without the context the old process gave them.
Where the work goes after the automated step gets faster
The mechanics are not subtle once you look for them. An automation is built against the routine shape of the work, because that is the shape you can describe in rules or train a model on. It takes the routine cases. What stays behind is everything irregular, and irregular cases were never evenly distributed across the old workload. They were already the ones that took longest.
Then two more things get added that did not exist before. Someone has to check a sample of what the automation decided, because nobody signs off on an unchecked machine making commitments to customers or suppliers. And some share of the automated decisions turn out wrong and come back, usually later, usually from the customer, which is the most expensive moment to find out.
As an illustration, take this example: invoice matching. The system matches invoice, purchase order and delivery note, and clears the ones where all three agree. What is left on the desk is the invoice where the quantity differs by two units, the one billed in a different currency, the one for an order someone changed by telephone and never wrote down. Those used to arrive mixed in with the simple ones. Whoever worked through the stack had seen forty invoices from that supplier that week and knew which of its branches habitually ships short. Now the hard one arrives alone, twice a day, with none of that around it. The time per invoice goes up, and the person handling it is working with less.
A second illustration, with the same shape: inbound customer email. The automation answers the standard requests well. What reaches a person is the angry one, the one with three unrelated questions in it, and the one that refers to an answer the automation already gave and got wrong, so the conversation has to be reconstructed before it can be continued. Add the daily sample check on the automated replies. Total human minutes can rise while the share of emails answered without a human also rises.
Both numbers are true at the same time, which is why step-level reporting does not catch it.
A step-level metric counts what the automation handled. It has no column for what it handed back, none for the sample check, and none for the case that came back from the customer three weeks later.
And the dashboard the supplier ships is built only from what the automation handled.
Where this has been measured
The place with hard measurement is software development, where one step, writing the code, got much faster and the steps after it did not. I went through those numbers in an earlier piece on why saved hours have nowhere to go, so I will add only one detail here. In 2025, DORA, the long-running research programme on software delivery, added a fifth metric called Rework Rate: the share of work spent fixing or redoing things, compared with work that moves something new forward. They added it because counting finished work had stopped telling them whether teams were really doing better. Rework is exactly the cost this piece is about, and it took a dedicated measurement to make it visible.
I have my own version of this, in a production workflow I run where AI produces the first version of each piece of work. It works. The first version used to take most of a day and now takes minutes. What did not get faster was my review, which still takes hours per piece, and which now has more arriving into it. So the limit on how much finished work comes out of that workflow is set entirely by how much reviewing I can do in a week. Adding another AI step to produce first versions would not produce one additional finished piece. The measurement that would have told me this earlier is how long one piece takes from arrival to finished, and I was not tracking that number, because the fast part felt like progress.
None of this is an argument against automating. In that workflow I would not go back, and the arithmetic holds whenever two conditions are true: the share of cases that leave the automated path stays small, and those cases are not much harder than the average case used to be. Plenty of office processes meet both, such as standard order entry, address changes and recurring monthly reconciliations. The point is that both conditions are measurable before you widen anything, and almost nobody measures them.
What to measure instead
There are three numbers to track, and a company of fifty people without an IT department can collect all of them.
- How long one case takes from start to finish, from the moment the request arrives to the moment it is done and nobody will touch it again, including the exceptions, the sample checks and the cases that came back. Measure it for a few weeks before you automate, and the same way afterwards. A clock and a spreadsheet are enough.
- The share of cases that leave the automated path, and how much time your team spends on them each week, compared with the time the whole process took before.
- Rework: how many finished cases are reopened, and how late. Late reopening is the one that costs real money, because by then a supplier has been paid or a customer has been told something.
Give those three numbers one named owner, the person who already answers for that process day to day. That should not be a committee, or the supplier who sold you the tool.
Before renewing the licences or putting two more people on the system, run that measurement for one month. If the automated step got faster and the time per finished case did not move, the work has shifted into the exceptions and the checking, and that is where to go looking for it.
Original article: https://unlockedconsulting.ai/blog/the-step-got-faster-and-the-process-got-slower
