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

Several thousand hours a year. That was the saving in a business case a CFO had prepared for her board before we were involved, for an invoice automation. 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.

The number was not dishonest. It was wrong in the ordinary way most AI value numbers are wrong, and a year later the CFO would be the one asked where the hours went.

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 every workflow we build 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.

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. Multiply elapsed time by volume and call it effort, and all the waiting is counted as work. That is where the several thousand hours came from.

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 pointless 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. Where a stagger is impossible, every concurrent change is listed in the value statement and, where possible, measured on its own. Sometimes the cleanup delivers more than the system, and the statement says so.

Capacity is measured at the peak

For most operations the real value is capacity: how much more volume the same team can absorb before it becomes the bottleneck. It is also the measure that connects to growth, which is usually why the company is investing.

Measured on an average day, capacity is flattering and useless. 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 changed bank account caught, 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. 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.

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. Measured this way, good work rarely needs help to look valuable.