How much really goes through untouched

Every automation programme reports a straight-through processing rate: the share of cases that went from arrival to completion without a person touching them. It sits on the steering-committee slide, it carried the business case, and it is the easiest number in the programme to improve without anything improving.

None of this requires bad faith. It only requires four definitions that nobody wrote down, each of which the delivery team settled in whichever way made the work look like progress.

Four ways the rate flatters

The denominator shrinks. Only cases that entered the automated path are counted. Cases rejected at intake, sent to manual handling by a pre-filter, or never attempted because their type is not supported yet simply disappear. Narrow the scope and the rate goes up.

The touch is not counted. Somebody approved a batch from a dashboard in one click. Somebody fixed master data so that a case could pass. An exception was resolved in another system and the case came back in as new. Under the definition the tooling uses, none of these is a touch.

It is measured too early. A case counts as straight-through at the moment it is posted. The credit note three weeks later, the customer complaint, the manual reversal — none of it reaches the metric. A case that went through untouched and wrong is worse than one that stopped, and the rate scores it as the best possible outcome.

One number covers unlike work. An average across simple and difficult case types. Growth in the simple volume lifts the rate while the difficult cases get no better at all.

Infographic

The slide rate and the honest rate

The slide rate

• –Counts what entered the automation
• –A touch means manual handling only
• –Measured at the moment of posting
• –One average across all case types

The honest rate

• →Counts everything that arrived
• →Any human action is a touch, bulk ones included
• →Restated after the correction window
• →Reported per case type, against a baseline

What an honest rate looks like

The denominator is everything that arrived. Including what was rejected or routed around the automation. Report coverage — the share the automation even attempted — separately from success within that coverage. Both are useful; mixed together, neither is.

A touch is any human action on the case. Bulk approvals and data fixes made so that the case could pass included. If the tooling cannot record that, recording it is the first thing to build.

It is restated after the correction window. Measure again once reversals, corrections and complaints have had time to surface, and count cases that went through and were corrected later as failures. Show them separately as well: they are the expensive ones.

It is split by case type. A few lines, one per type, instead of one average that hides where the work is.

It has a baseline. Measured on the current process, before anything changes, under the same definitions. Without it there is nothing to compare with, only a number that went up. It is also the one part of the measurement that cannot be added later, because by then the old process is gone.

The rate is not the goal

Straight-through processing is a means. What operations leaders actually care about is the cost and time per case and the errors that reach a customer. A process with a modest rate and fast, well-designed exception handling can beat one with an impressive rate and an exception queue nobody owns. Time spent waiting in that queue belongs in the cost per case too: a case that sits for days waiting for a decision can easily cost more than one handled by hand on the day it arrived.

Report three numbers together: the honest rate per case type, the cost per case including exceptions, and the errors found downstream. Any one of them can be gamed. Gaming all three at once is much harder.

Why programmes resist this

The honest rate is never higher than the reported one: every definition above either adds cases to the denominator or removes them from the numerator. And it is usually reported by the people whose work it measures. That is not a character flaw; it is an incentive.

The fix is procedural. Agree the definitions before the first measurement, give the number to somebody outside the delivery team, and publish it when it drops. A programme that does this looks worse for a quarter and is believed from then on, which is worth more.

Agreeing the measurement before anything is built is part of how we run AI transformation work: two or three numbers, defined up front and measured before the change, so that the later comparison is honest by construction.