What has to be reported alongside it?

An error rate, always and without exception. A straight-through rate that rose while errors rose describes a system passing cases it should have stopped on, and nothing whatever in the headline figure distinguishes that from the improvement everybody hoped they were buying.

Why did our progress slow down?

Because the easy cases went first. Each subsequent band of cases is harder than the last, so early gains are not a guide to later ones, and a plan assuming steady progress towards full automation overruns in an entirely predictable direction.

Why does the rate move when we have changed nothing?

Because it depends on what arrives as much as on what you built. A new product, a change in what customers send or a supplier altering a format all move it, so a fall is a prompt to look at the input rather than a verdict on the system.

Glossary

Straight-through processing

A case that completes from start to finish with nobody touching it, and the figure such projects are most often judged on.

In plain terms

Cases that go all the way through on their own. It is the number the funding rests on, and by itself it says nothing about whether those cases came out right, which is the other half of the same question.

Why it matters

Because it is the single figure a project is judged by, and it can be improved by letting more cases through unchecked. That change and a genuine improvement look identical in the number, and only the error rate beside it tells them apart.

How it works

It counts cases that finish without anybody touching them. That is a clean definition and a narrow one: it says how many went through, and nothing whatever about how many went through correctly.

It has to be read with an error rate. A rate that rose while errors rose is a system passing more of the cases it should have stopped on, which is a worse outcome reported as a better one.

What counts as a case decides the number. Excluding the awkward categories from the denominator raises it without changing anything, so the definition needs settling before the measurement rather than during the review of it.

The last stretch costs far more than the first. Early gains come from the cases that were already nearly automatic, and each subsequent band is harder, so a plan that assumes steady progress towards everything will overrun in a predictable way.

Full automation is rarely the right target. Some cases are genuinely better handled by a person, and a project aiming at completeness ends up building unreliable handling for rare situations rather than admitting that they belong to somebody.

It is a share, so it is worth knowing what it is a share of. A rate rising while total volume falls can leave the absolute number of cases needing a person unchanged, which is the figure staffing actually depends on and the one a percentage hides.

The rate moves when the world does, not only when you improve. A change in what customers send, a new product or a supplier changing a format all shift it without anybody touching the system, which is why a falling rate is a prompt to look rather than a verdict.

Two ways the rate goes up

That third line is worth more than it looks, because it is a check somebody can make without any new instrumentation. When automation genuinely improves, the cases left over are the difficult residue and the queue gets harder per item. When a system has simply loosened, the queue gets easier, because the cases that would have been stopped were the borderline ones and they are now going through unexamined. Anybody working that queue will tell you which is happening within a week if asked, and almost nobody is asked, because the question is answered from a dashboard instead. The general form is worth carrying to any automation metric: when a number improves, find somebody downstream of it and ask whether their work got harder or easier, then check that the answer is the one the improvement implies. It takes a conversation and catches the class of problem that reporting is structurally unable to show.

Seen in the wild

A rate that rose after the difficult category was quietly excluded from the count.
Make
Early automation gains slowing sharply once the easy cases were done.
Zapier
A rate falling because an upstream format changed rather than because anything broke.
n8n

Common misconceptions

People assume

A higher rate is always better.

In fact

It rises when a system stops checking as well as when it gets better, and the two are indistinguishable in the figure. Without an error rate beside it, a rise cannot be interpreted at all.

People assume

The target should be everything.

In fact

Some cases are better handled by a person, and each additional band costs more than the last. A project aiming at completeness usually ends up building unreliable handling for rare cases instead of leaving them where they belong.

Questions

What has to be reported alongside it?: An error rate, always and without exception. A straight-through rate that rose while errors rose describes a system passing cases it should have stopped on, and nothing whatever in the headline figure distinguishes that from the improvement everybody hoped they were buying.
Why did our progress slow down?: Because the easy cases went first. Each subsequent band of cases is harder than the last, so early gains are not a guide to later ones, and a plan assuming steady progress towards full automation overruns in an entirely predictable direction.
Why does the rate move when we have changed nothing?: Because it depends on what arrives as much as on what you built. A new product, a change in what customers send or a supplier altering a format all move it, so a fall is a prompt to look at the input rather than a verdict on the system.