Automation rate

What is automation rate?

Automation rate is the share of cases in a process that reach the end without a person touching them. Count the cases that ran on their own, divide by the cases that went through the process, multiply by a hundred.

The name changes with the room. In payments it is the straight-through processing rate, which IBM describes as the percentage of transactions processed automatically. In accounts payable it is the touchless rate, defined by Celonis as the share of invoices processed without need for human intervention. In insurance it is the share of claims that settle without a handler ever opening the file.

It is also the easiest number in operations to quote without saying anything. When two companies both report seventy percent, they are almost never counting the same thing, and neither of them is lying.

The number means nothing until you fix the numerator and the denominator

Four questions decide what your rate measures. Answer them in writing and leave the answers alone for a year.

Does an approval count as a touch? A case that ran itself and then waited for a manager to click approve is not the same as a case nobody opened. Both answers are defensible, and only one of them is yours.

Do the cases the automation refused to start on count at all? A rule that drops a case before the flow begins, because the supplier is unknown or the document type is not recognised, still leaves work for somebody. Keeping those out of the denominator is the most common way a rate gets flattered, usually by accident.

Is the denominator everything, or only what is in scope? An in-scope rate tells the build team how well the automation works on the cases it was designed for. A whole-process rate tells the business how much manual work is left. Publish the second and keep the first for the builders.

Is one item a case, an activity or an event? UiPath's process mining documentation defines automation rate as the percentage of events that are automated. A 2019 analysis in Compact by KPMG's Dutch practice defines it as the ratio between activities performed by a system user and all activities performed. Insurance and payments count whole cases. Take a five-step process where the same one step always needs a person: four of five activities run automatically, so the activity rate is eighty percent, and no case gets through untouched, so the case rate is zero. Both are correct, and only one of them tells you whether anyone got their afternoon back.

Four honest versions of the same rate

1. Fully touchless. Nobody opened, corrected, chased or approved the case. This is the strictest reading, and the right one for any number you show outside your own team.

2. Touched once. One human step, nearly always an approval. This is the honest headline where a control is mandatory, such as under four eyes or segregation of duties. Zero is not available there, so measuring against zero only makes the process look worse than it is.

3. Automated but reviewed. The system decided and a person confirmed. This is the right number while a new rule set runs under supervision, and it needs an end date next to it, because a review step meant to last six weeks that is still there after two years is a manual process with extra clicks.

4. Started automatically, finished by hand. The case entered the flow and dropped out along the way. That is a coverage rate, not an automation rate.

How the number gets gamed without anyone lying

Charles Goodhart wrote in 1975 that any observed statistical regularity tends to collapse once pressure is put on it for control purposes, and Marilyn Strathern gave it the line everyone repeats: when a measure becomes a target, it ceases to be a good measure. Gwyn Bevan and Christopher Hood, writing in Public Administration in 2006 about targets in the English health service, named the mechanism. A target is a part standing in for a whole, and once people are judged on the part, the part and the whole drift apart.

It happens in three ways, and none of them puts a false number on a slide. Narrowing the scope: the project starts with the three suppliers who send clean structured data, hits ninety percent on them, and reports ninety percent. Moving the hard cases out of the count: complex cases get their own queue, handled by the two people who know the product, and that queue sits outside the measured process. Counting a rubber stamp as no touch: a manager approving two hundred cases a day is not reviewing two hundred cases, and treating that as untouched assumes the approval is doing work it is not doing, which is the ground automation bias grows on.

Each is a reasonable local decision by somebody whose project review depends on a number going up. That is why the definition belongs to whoever owns the process, not to whoever owns the automation.

Two worked examples

The rate goes up and the process gets worse

A distributor handles about 1,000 sales orders a month, of which 620 need no touch, so 62 percent. Orders drop out mostly on a price check: any line more than 1 percent off the customer price list stops for review.

The team widens that tolerance to 5 percent. The next month 780 of the 1,000 run straight through, so 78 percent, sixteen points from one change. Credit notes go from 6 a month to 40, each costing roughly 25 minutes across sales, finance and a call to the customer, so the 34 extra ones add about 14 hours a month on top of the margin given away.

The rework happened after the case was closed, so it never entered the denominator. A rate that jumps right after a threshold change deserves a look at the correction count first.

The rate goes down and that is the right answer

The same distributor opens about 400 new customer accounts a year. Anything under 2,500 euro of requested credit is approved automatically with no check, so the rate is 88 percent, and bad debt written off runs at roughly 24,000 euro a year.

They add one rule: a new customer with no trading history goes to a person, whatever the amount. Automatic approvals fall to 284 of 400, so 71 percent. Those 116 cases take about ten minutes each, some 19 hours a year, and write-offs fall to about 7,000 euro. Seventeen points of automation rate bought back around 17,000 euro for 19 hours of work, and on the dashboard the project looks like it went backwards.

What has to sit next to it

Four numbers on the same page stop the rate being misread. Exception reasons, ranked: every case that leaves the automated path gets a reason code, and once a month somebody reads the top three. Rework or reversal rate: corrections, credit notes and reopened cases after closing. Cycle time: how long a case takes from arrival to done, queues included. Cost per case: loaded staff time plus software divided by volume, recomputed each quarter instead of copied from the business case.

Automation rate versus cycle time

Each of the two hides what the other one shows. Automation rate hides time: a case can be fully touchless and still take four days, waiting for a nightly batch, then for a supplier to answer, then for the payment run. Nobody touched it, so it counts as automated, and the customer waited four days. Cycle time hides effort: a case can be done in two hours because three people dropped what they were doing, which is fast on the customer's clock, expensive in hours, and stops working the week volume doubles.

Together they answer two questions, how much human effort a case costs and how long it takes, so a project that moves only one of them should say which one it was aiming at.

Setting a target and working the exception list

There is no universal good number, because a rate depends on your definition, your case mix and how much judgement the process genuinely needs. Any benchmark you read was measured on somebody else's mix under somebody else's definition, which is why the invoice automation entry spells its numerator out before it quotes a figure. The useful target is your own number from a quarter ago plus the reason it moved, and a rate that moves for a reason nobody can explain is a measurement problem rather than an operations result.

Chasing the last twenty points is usually the wrong project. The first sixty came from cases that look like each other. What is left is judgement calls, cases where the source data is wrong at the source, and situations that happen four times a year. Every extra point costs more than the one before, because the remaining cases are not variations on one problem. They are twenty separate problems.

The better project is the exception list. Split the ranked reason codes in two. Some are fixable at the source: one customer whose order reference never exists in your system, one article with a stale price, one buyer who never raises a purchase order. Those disappear when somebody makes a phone call, and they take a slice of the rate with them. The rest will always need a person, and the work there is to turn their fifteen minutes into three, with the case, the failed check and the proposed correction on one screen and escalation rules deciding who sees it and by when. A process where an exception is cheap to handle beats a process with a higher rate and a painful tail, and only one of those two shows up on the dashboard.