Automation projects follow a predictable cost curve: the first 80% of cases — the common, well-structured, high-volume ones — automate fast and cheap. The remaining 20% are edge cases, ambiguous inputs, and genuine judgment calls, and the cost of automating each additional percentage point rises steeply. Teams that don't recognize this curve keep investing engineering effort chasing full coverage, well past the point where a human reviewing exceptions would have been cheaper.
Why the last 20% resists automation
- It's disproportionately made of genuine exceptions — the cases that reach this tier often exist because they don't fit the pattern the automation was built to recognize.
- Each additional edge case requires its own handling logic — unlike the first 80%, which shared common patterns, the remaining cases are frequently each other's own special case.
- The cost of a wrong automated decision here is often highest — edge cases are disproportionately the ones with unusual context that matters, exactly where an automated misjudgment is most damaging.
The decision framework
At each additional percentage point of coverage, compare the marginal engineering cost of automating it against the cost of a human handling that same volume of exceptions. There's a crossover point — often well before 100% — where a human-in-the-loop review queue is simply cheaper and more accurate than continued automation investment. Finding that crossover point is a calculation, not a guess.
The right target usually isn't '100% automated.' It's 'automated to the point where the review queue is small enough that a human handling it is a rounding error, not a bottleneck.'
What this means for scoping
Budget and design for a human review path from day one, not as a fallback bolted on when the automation inevitably misses cases. A well-designed exception queue with good context is a feature, not an admission of failure — and it's usually the cheapest way to handle the last 20% that will ever exist.