Process automation has a well-defined edge. Inside it, a tool is excellent: given a case that matches the shape it was built for, it runs the steps faster and more reliably than a person. Outside it, the tool stops and waits.
That boundary is where most of the remaining manual work lives — and it's worth being precise about why.
The exception rate is the whole story
Take a process with ten steps that a workflow tool handles perfectly. Say nine out of ten cases run start to finish without intervention. That sounds like ninety percent of the work is gone.
It isn't, because the tenth case doesn't cost a tenth of the effort. It costs more than an unautomated case would have. Someone has to notice it stopped, reconstruct what state it stopped in, work out what the tool was trying to do, resolve the thing that didn't fit, and either restart the process or finish it by hand.
The nine cases that went through cleanly produce no work at all. The whole cost of the process is concentrated in the exceptions, and automating the happy path leaves that cost almost entirely intact.
Why the exceptions cluster around people
It's not a coincidence that the cases falling outside the script are usually the ones involving another human.
A step that reads from a database either works or fails loudly. A step that asks a customer for three documents can come back with two documents and a question, or three documents of which one is for the wrong period, or an out-of-office, or nothing at all for nine days, followed by a photo that's too dark to read.
None of those are system failures. They're ordinary outcomes of asking a person for something. But they're all outside the shape a workflow diagram can practically anticipate, and each one ends the same way: the process stops and waits for a human to interpret it.
Anticipation doesn't scale
The instinctive fix is to widen the script — add a branch for the wrong period, a branch for the unreadable file, a retry for the silence.
This works for a while and then stops working, for a structural reason. Each new branch handles one specific deviation, but deviations combine. A document that is both for the wrong period and partially illegible, from a client who then goes quiet, isn't three handled cases. It's a new case, and it falls through.
The set of things that can happen in a conversation is not a list you can finish writing.
The alternative is deciding at runtime
The other approach is to stop trying to enumerate deviations in advance and instead evaluate each response when it arrives: what came back, what the process still requires, and what to do about the difference.
That's a different kind of system. It doesn't need a branch for "document is for the wrong period" because it isn't matching against a list of known deviations — it's comparing what it received against what it needs, and the wrong period is simply one of many ways those can fail to match.
What it does need is a clear boundary for its own judgment. A system that can respond to anything is also a system that can respond wrongly to anything, which is why the useful version of this has an explicit line: resolve what's mechanical, escalate what's genuinely a decision, and make the escalation carry enough context that the person picking it up isn't starting cold.
What to actually measure
If you're assessing whether a process is worth handing over, the throughput number is the wrong one to look at. Two questions are more useful:
What fraction of cases currently require a person to intervene at least once? That's the real target, and it's usually much higher than people expect — closer to a third than a tenth in any process that involves collecting something from a customer.
When a case does need a person, how long does it take them to work out where it stopped and why? That reconstruction time is invisible in most process metrics and is often the single largest cost in the workflow.
Automating the steps only moves the first number. It's the second one that determines whether the process actually got cheaper.