Waiting, Touch and Rework: Measuring What AI Changes in Operations

Several thousand hours a year. That was the saving in a business case for an invoice automation, written before we were involved and built the way most such cases are built. The calculation multiplied the number of invoices by the time an invoice used to take from arrival to payment. Most of that time had been waiting: in an inbox, in an approver's queue, for a warehouse to post a receipt. Nobody had been working on the invoice for most of those days. Automation would shorten the wait. It would not return hours nobody had spent.

Every input to the number was correct. The method was the problem, and it is a common one: it counts waiting as work. A year after go-live, the board would have asked where the hours went, and nobody could have pointed to them.

McKinsey's State of AI survey (March 2025) found that most organisations using generative AI were not yet seeing a material effect on enterprise-level earnings. Part of that gap is real. Part of it, in our experience, is measurement: value claimed in a form nobody can find afterwards. So the work starts with a value statement, agreed before the build and reported against after it.

Every case splits into waiting, touch and rework

We split the life of a case into three parts, each measured from its own source. Waiting is time with nobody working on the case: in an inbox, in an approval queue, blocked on a missing goods receipt. Touch is time a person actively works on it. Rework is touch that happens again because the first attempt was wrong or incomplete.

Elapsed time is the sum of the three, and it comes from system events: received, first opened, status changed, approved, posted, paid. Touch and rework come from timing a sample of real cases across a full period that includes a month-end. Never from interviews, because people remember the hard cases, forget the easy ones and cannot tell working from waiting. Self-reports are unreliable even about AI itself. In a randomised study METR published in July 2025, experienced software developers took 19% longer on tasks where AI tools were allowed, and still believed afterwards that the tools had made them 20% faster. If that is how well engineers can judge their own speed, a finance team's estimate of hours saved is not a measurement.

The split shows where value will come from before anything is built. Automation removes most of the waiting, much of the rework and a smaller share of the touch, because the hard cases still need people. In the invoice case, most of the several thousand hours were waiting.

Waiting is paid for in cash, not salaries

Removing waiting is still valuable. It is just valued in a different currency. An invoice that waits past its discount date loses the early payment discount. A customer order that waits for a credit check waits in the customer's inbox too. A receivable that waits for a matched payment sits on the balance sheet as working capital. None of that is payroll, and none of it shows up in hours.

So the value statement prices waiting where it lands: discounts captured against discounts available, days from order to confirmation, days sales outstanding for the segment the workflow touches. These are numbers a CFO already tracks and can check without us. Touch and rework, the time people genuinely spend, are the only part that belongs in a capacity measure.

A staggered rollout is the counterfactual

Every value claim has to answer what would have happened without the system. Implementation always changes other things at the same time. Master data gets cleaned, suppliers are asked to include order numbers, a redundant approval step disappears. All of these improve the numbers. None of them is the AI.

The cleanest answer we have found is a staggered rollout. In a group with several entities, markets or teams, the workflow goes live in some before others. For a few periods the entities without it are the comparison, exposed to the same season, the same volume trend and, if they get it too, the same cleanup. The difference between the groups is the system's effect, and it varies, so the statement reports it by segment, team or case type rather than as one number for the whole operation. Where a stagger is impossible, each concurrent change is listed and, where possible, measured on its own. Sometimes the cleanup turns out to matter more than the system, and the statement says that too.

Capacity is measured at the peak

For most operations the value that matters is capacity: how much more volume the same team can absorb before it becomes the bottleneck. That is the number a growth plan needs.

Measured on an average day, capacity looks better than it is. We measure it at the month-end peak: volume cleared within the deadline on the busiest days, and the size of the review queue left behind. A team that now clears the peak comfortably, where before it slipped into the next month, has capacity a CFO can plan growth against.

At a beverage manufacturer, invoice to purchase order to receiving to payment went from 3 days to 15 minutes, with 94% of invoices matched without a person. That is an elapsed-time and matching-share measure from system timestamps before and after. It shows suppliers paid on time and a finance team no longer on the critical path. It is not a claim about hours, headcount or revenue, and we do not present it as one.

Revenue and errors avoided need direct evidence

Faster quoting may win more orders. Sometimes the link is real, and it is almost never measured. We claim a revenue effect only when the client has measured it with a method that would survive a finance review: a comparison group, or a before and after on a quantity the workflow directly controls, such as requests that previously went unanswered.

Errors avoided get the same discipline. A duplicate payment stopped, a difference found before the close: each counts only when the system flagged it and a person confirmed it as a real problem, valued at the amount at risk, not at a guess about consequences.

The value statement has a fixed shape

The statement a sponsor receives holds three to five measures, never twenty. For each: definition, source system, period, baseline, current value, and what else changed in the same period. A number whose method cannot be given in one sentence stays out. Every gain is shown next to what it costs to run: the model and infrastructure, and the review time the system asks of people, which is the cost business cases most often leave out. The measures are fixed before the build and do not change after go-live because another one looks better.

Two further rules. A number the system reports about itself, such as its match rate or straight-through share, is checked against the ERP's and the bank's own records before it goes in. And reporting starts from the first full period that includes a month-end, because the first weeks mix the novelty of a new process with the disruption of learning it. Economists see the same dip at the scale of whole economies: Brynjolfsson, Rock and Syverson's "The Productivity J-Curve" (2021) describes how the unmeasured effort of adopting a new technology makes measured productivity look worse before it looks better. A sponsor who knows the dip is coming does not mistake it for failure.

Two sentences per number

Before a value statement goes to a board, the sponsor answers one question about each number, out loud: how was this measured, and what else changed in the same period? If the answer takes more than two sentences or includes the word "estimated", the number is not ready.