Answer
How do you prevent automation from creating more work?
Remove the manual step it replaced, keep the exception rate low, and refuse to review output nobody was reviewing before.
Remove the step it replaced rather than running both, keep the exception rate low enough that the queue clears, and do not create a review activity for output that previously went unreviewed.
There are three ways an automation increases work and all of them are avoidable. The old step survives alongside the new one. The exceptions it produces accumulate faster than they are cleared. Or it creates a review activity that did not exist before, because the output now needs approving where the equivalent human work did not.
The surviving step is the simplest and the most common. Parallel running is correct for a period and it has to end, and it frequently does not, because nobody decides when. The old process continues at reduced volume, the knowledge that it exists fades, and the business is maintaining two paths for one job. Setting the end date when parallel running starts is the whole of the fix, and it costs one sentence.
Exception accumulation is the second, and it is a rate problem rather than a design flaw. If exceptions arrive faster than they are cleared, the queue grows without limit and the automation has converted a distributed workload into a concentrated one. This is fixable by reducing the exception rate — usually by handling the two most common causes — and it needs to be visible, which means counting exceptions rather than experiencing them.
Invented review is the third and the most insidious because it looks like diligence. If a process previously ran without anyone checking the output, and the automated version has a review step, the automation has added work. Sometimes that is correct: the previous absence of checking was a risk and the new visibility is a gain. Often it is not, and the review exists because the output is machine-generated rather than because it needs reviewing. Asking what was checked before is the way to tell.
A fourth cause is worth adding: automations that generate output nobody asked for. A daily report, a summary, a notification stream. Each item is small and each requires someone's attention, and the aggregate is a new reading obligation created by a project intended to reduce work. Output should go where a decision is made, and output nobody acts on should be removed rather than tolerated.
The test that catches all four is to measure the human time on the process afterwards and compare it with before. This is rarely done, because the saving is assumed at the point of building and nobody returns to check. Businesses that measure frequently find the saving is real and smaller than expected, and that a specific one of the four causes accounts for most of the difference.
An automation that adds a checking task to a process nobody was checking has not saved time, it has invented a job.
Siddharth Sharma, Context Theory
Related questions
How long should parallel running last?
Long enough to compare outputs across a representative period, which usually means one full cycle of whatever the process is — a month for monthly work, a fortnight for daily work with weekly variation. The important part is that the end is decided at the start, because an open-ended parallel period does not end on its own.
What if the review is genuinely needed?
Then it is part of the cost and belongs in the calculation rather than being treated as overhead. An automation that saves twenty minutes and requires five of review has saved fifteen, which is still worth having and is a different number from the one in the business case. The problem is only the review nobody decided to add.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Parallel running frequently does not end because nobody decides when, leaving the business maintaining two paths for one job while knowledge of the manual path fades, so the end date must be set when parallel running begins. | Identifying which processes in the business are currently running in both automated and manual form. |
| Response | Where exceptions arrive faster than they are cleared, the automation has converted a distributed workload into a concentrated queue, which is a rate problem addressable by handling the two most common causes. | Comparing the exception arrival rate against the clearance rate over a month. |
| Constraint | A review step added because output is machine-generated rather than because it needs reviewing constitutes invented work, distinguishable by asking what checking the process received before automation. | Establishing whether the pre-automation version of the process had any review step. |
| Buying behaviour | Measuring human time on the process after automation is rarely done because the saving is assumed at build time, and businesses that measure typically find a real but smaller saving attributable to one specific cause. | Timing the human effort on the process before and after automation. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one