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

Several thousand hours a year: the saving in a business case for invoice automation, written before we were involved. It multiplied invoice count 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 confirm the goods had arrived. Nobody worked on the invoice most of those days. Automation would shorten the wait, not return hours nobody had spent.

Every input was correct. The method counted 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 company-wide earnings. Part of that gap is real. Part, 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 it: in an inbox, in an approval queue, blocked on missing information. Touch is time a person actively works on it. Rework is touch that happens again because the first attempt was wrong or incomplete. Run claims or referrals rather than invoices? The split is the same.

Elapsed time is the sum of the three, and it comes from the timestamps the systems already record: received, opened, approved, paid. Touch and rework come from timing a sample of real cases across a full month, including the busy month-end. Never from interviews: people remember the hard cases, forget the easy ones and cannot tell working from waiting. 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 engineers misjudge their own speed that much, a 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 less 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, in a different currency. An invoice that waits past its discount date loses the discount for paying early. A customer order that waits for a credit check waits in the customer's inbox too. Money a customer owes, waiting for their payment to be matched, is cash the company can't use. 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, the average days customers take to pay in the part of the business the workflow touches. A CFO already tracks these and can check them without us. Only touch and rework belong in a capacity measure.

Going live in stages gives the comparison

Every value claim has to answer what would have happened without the system. A project always changes other things too: records get cleaned up, suppliers are asked to include order numbers, a pointless approval step disappears. All improve the numbers. None is the AI.

The cleanest answer we have found: in a group with several companies, markets or teams, go live in some before others. For a few months the units without it are the comparison, exposed to the same season, the same volume and, if they get it too, the same cleanup. The difference between the groups is the system's effect, and it varies, so we report it by team or case type rather than as one number. Where that is impossible, each other change is listed and, if possible, measured alone. Sometimes the cleanup matters more than the system, and the statement says so.

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, and on an average day it 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, the path from invoice to purchase order to goods received to payment went from 3 days to 15 minutes, with 94% of invoices matched without a person. That is elapsed time and share matched, from system timestamps before and after. It shows suppliers paid on time and a finance team no longer holding up the process. 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; it is almost never measured. We claim a revenue effect only when the client has measured it in a way that would survive a finance review: a comparison group, or a before and after on something the workflow directly controls, such as requests that used to go unanswered.

Errors avoided get the same discipline. A duplicate payment stopped, a mismatch found before the books are closed for the month: each counts only when the system flagged it and a person confirmed it as real, 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, starting value, current value, and what else changed in the same period. A number whose method can't be given in one sentence stays out. Every gain sits next to what it costs to run: the AI and hosting, and the review time the system asks of people, the cost business cases most often leave out. The measures are fixed before the build, not swapped after go-live for one that looks better.

Two more rules. A number the system reports about itself, such as how many cases it matched alone, is checked against the ERP's (the core business system's) and the bank's own records first. And reporting starts from the first full month, because the first weeks mix a new process with the disruption of learning it. Brynjolfsson, Rock and Syverson's "The Productivity J-Curve" (2021) describes the same dip across whole economies: the hidden effort of adopting a new technology makes productivity look worse before it looks better. A sponsor who expects the dip doesn't 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.