Every automation is scoped against a process as somebody describes it. Enquiry arrives, gets logged, gets qualified, gets a quote, gets chased. Then it meets the work as it actually arrives, and the description turns out to have described only the easy cases.
01 — What happened
The pattern is old, well documented and almost never priced into a business case: real processes have a long tail of variants, and the tail is where the effort hides.
Process mining — reconstructing what a process actually did from the event data left in business systems — has measured this. In his overview of the field, Wil van der Aalst of RWTH Aachen puts the distribution plainly: “most processes have a Pareto distribution, e.g., 80% of the cases can be described by only 20% of the process variants.” The comfortable reading stops there. The next sentence matters more: “the remaining 20% cannot be discarded since these cases cover the remaining 80% of the process variants and often also the majority of performance and compliance problems.”
It gets more lopsided. He notes logs where “95% of the cases can be described by less than 5% of the process variants”, leaving the remaining 5% to “consume most of the resources due to rework and exception handling.” And he is describing purchase-to-pay and order-to-cash, where “it is not uncommon to find thousands of process variants.”
What has changed is how many businesses face the decision. The U.S. Chamber of Commerce’s 2026 Empowering Small Business report, published on 2 October 2026, found 66% of US small businesses using AI, up eight points in a year, with 41% running six or more technology platforms. More businesses are scoping more automations than ever — most against the described path.
02 — Why it matters
A process description is a story about the typical case. An automation meets every case. Three things follow.
The saving does not arrive. You automate the clean path, the awkward cases still reach a person, and because they take longer than average the queue gets harder rather than shorter.
You may have automated the wrong 80%. The tail carries “the majority of performance and compliance problems”, so automating the common path rarely de-risks anything. The rework, the chased approvals, the orders that went out wrong — those live in the variants, untouched.
And the third, which is why this matters more in 2026 than in 2019: a deterministic automation fails loudly on an exception — the field does not match, the script stops, somebody gets an error. An AI agent does not stop. It improvises, plausibly, and you find out later.
The research is sobering on exactly that point. A 2026 Princeton preprint by Stephan Rabanser, Sayash Kapoor, Arvind Narayanan and colleagues measured reliability across fourteen models on two agent benchmarks: “recent capability gains have only yielded small improvements in reliability,” and “outcome consistency remains low across all models” — meaning “agents that can solve a task often fail to do so consistently.” Severe failures are rare, but the authors note rare ones “can carry significant costs”, citing a coding assistant that deleted a production database despite explicit instructions.
The tail is the least repetitive, least documented, highest-consequence part of your process — precisely where inconsistency is most likely and most expensive.
03 — The economics
The number that decides an automation is not how many cases you handle. It is the share it can finish, end to end, without a person deciding anything.
Take an illustrative service business with, say, 500 inbound enquiries a month. The vendor case is built on 500. Assume about 70% are standard — a clear request, a known service, an address inside the normal area — and 30% are not: existing customers on special terms, multi-site jobs, requests needing a survey before anything can be priced.
Automate the standard 70% and 350 cases flow. The remaining 150 arrive at a person, as before, and payroll is unchanged: 150 unpredictable cases still need somebody present through working hours. The saving is capacity, not cash — the distinction behind hours saved is the wrong way to value an automation.
Now the cost the business case omits: the automation must recognise which cases are its own, and that recognition is imperfect. Suppose 10% of the 350 it accepts turn out mid-flow to be exceptions: 35 cases a month part-processed wrongly. Each costs more than it would have manually: undoing what was done, and sometimes a customer who has already had the wrong quote. Assume recovery at three times manual handling — conservative once a customer is involved — and those 35 cases consume the equivalent of roughly 105 manual handlings: about a third of the 350-case gain, before supervision.
The tail grows with you. At 500 enquiries a month a 30% tail is 150 cases. At 1,500 it is 450; at twenty minutes each — exceptions being the slow cases — that is about 150 hours a month, most of a full-time role. Businesses automate to avoid a hire, then make the hire anyway, because what they removed was the easy volume.
Detection is worth more than execution. Improving recognition from 90% to 98% above cuts misrouted cases from 35 a month to seven — on the same assumptions, roughly 84 handlings’ worth of recovery, without automating a single extra case. Where the exception rate is high, the cheapest build is the one that sorts work correctly, not the one that does it. Worth more still: fewer variants. If a quarter of your exceptions exist because the intake form never asked whether a job is single-site, the fix is a question, not a system.
04 — What businesses should do
Count the tail before you build anything. Take the last month of real cases — not a workshop description — and sort them into “went the standard way” and “did not”, with one line on why for each exception. If your business handles 500 enquiries a month manually, the figure that decides the business case is not 500; it is how many of those 500 could have been completed without a person making a judgement call. Keep the log: it is the only way to tell whether the tail is shrinking.
Automate a path, not a process. Write the entry condition explicitly: new enquiries, for these services, inside this area, no existing contract. A narrow automation with a clean boundary beats a broad one that guesses.
Define the fallback before the happy path. Every automation needs specified behaviour for “this is not one of mine”: stop, log it, hand it to a named person. With agents this is not optional, because an agent facing an unfamiliar case will proceed by default.
Test for consistency, not capability. Run ten real cases, three of them awkward, ten times each, and look at the variance, not the best run. A system that is right nine times in ten and silently wrong once is worse than one that refuses the case outright.
Sort before you automate. If more than about a third of cases need a judgement, build routing and detection first and leave the work to people.
05 — Where technology fits
For many businesses the first build here is not an automation at all. It is somewhere cases are recorded with their outcome, so the tail can be counted.
If you cannot say how many of last month’s jobs went the standard way, that is a system-of-record problem rather than an AI problem — one record of the work, in one place, with the exception reason captured as a field rather than buried in a note. Usually that means a CRM or a connected system, the same gap behind the real cost of disconnected business systems.
Where the clean path is high-volume and well-bounded, the right build is usually deterministic and dull: routing, validation, a reliable handover between two systems: fixed cost, no improvisation, little supervision. Connecting systems that lack a sensible interface has got cheaper, as automating software that has no API describes. AI belongs where a task needs judgement at volume and a wrong answer is cheap and visible: classifying enquiries, drafting a first reply for review. Keep it off the tail, where wrong answers are expensive and quiet — and near exceptions an agent needs its own account, scoped permissions and an audit trail, where most AI automation gets stuck.
The legitimate no: if your exception rate is 50% and the reasons differ every month, you do not need an AI system for this yet, and possibly not any system. You have a commercial problem wearing a technology costume: too many ways of doing the same job, or an offer with too many variants to operate consistently. That is a decision about how the business runs rather than what it buys.
06 — RevenueStack’s take
Our view: the significant number in an automation decision was never the volume. It is the share of work that can be finished without a decision — the one figure nobody brings to the meeting, because it is the only one a vendor’s calculator cannot supply.
Demonstrations are built on the main path because it demonstrates well. The tail does not demo. It also does not disappear: after the build it is still there, concentrated, harder, and plainly somebody’s job.
The sharper conclusion argues against buying software more often than for it. Where a process has drifted into many variants, standardising it is usually a bigger lever than automating it. Removing a variant costs a conversation and a changed form. Accommodating one costs a feature, for as long as the system lives. Most businesses have more of the first available than they think, and it makes everything built afterwards cheaper.
Sources
- Process Mining: A 360 Degree Overview — Wil M.P. van der Aalst, RWTH Aachen — Process Mining Handbook, Springer, 2022
- Towards a Science of AI Agent Reliability — Rabanser, Kapoor, Kirgis, Liu, Utpala and Narayanan, Princeton University (arXiv preprint), 2026-02-18
- Empowering Small Business: The Impact of Technology on U.S. Small Business — U.S. Chamber of Commerce Technology Engagement Center, 2026-10-02
