The last 20 percent: why half-automating a process can cost more than not automating at all
Automating the easy 80 percent of a process sounds like a clear win. What it actually does is hand the hardest cases to a person who now knows less about the work than before. Why the leftover cases often cost more than running the whole thing by hand.
The demo always uses the clean record
There is a version of every automation that gets shown off, and it is always the same version. A tidy record goes in. It moves through each step. The right thing comes out the other end. The standard customer, the normal order, the input that fits the form exactly. It works, and usually it works well.
The demo never includes the customer with two shipping addresses. Or the order where someone left a required field blank. Or the name with a character the integration chokes on. Those cases are not unusual. They are just not part of the story you tell when you want to prove the thing runs.
That gap is where a lot of automation budgets quietly leak. The 80 percent that sail through were always the easy part. Almost any tool could have handled them. The question that actually decides whether the project pays for itself is the one nobody puts in the demo: what happens to the 20 percent that do not fit the pattern?
The leftover work does not vanish, it moves
No automation handles every case. It takes the part that bends neatly into rules and leaves the rest. That rest does not evaporate. It lands on a person.
This is the bit almost nobody thinks through before signing off. Before the automation, one person handled all the cases, the simple ones and the hard ones. They had a rhythm. They knew the odd exceptions by heart. They carried the whole process in their head. After the automation, that person only sees the hard cases now, which are exactly the ones with no clean pattern. Their whole day turns into a pile of edge cases, stripped of the context the easy cases used to supply.
The automation did not take the work off their plate. It took the easy work and concentrated the hard work.
Why the remainder costs more than the spreadsheet says
A single exception often takes more time after automation than it did before, not less. That sounds backwards. The reason is simple. Before the person can touch the case at all, they first have to work out what the automation already did and what it skipped. Did it half-create the record? Did the confirmation email already go out? Is the status sitting on "processing" while nobody is actually processing anything?
They used to run the case start to finish and always knew where they stood. Now they are dropping into the middle of something a machine began and then walked away from. That handoff is expensive. It eats time, it eats focus, and it is a reliable source of mistakes, because the person is building on a state they did not create themselves.
Do the math once. If the automation takes 80 percent of the cases, but the remaining 20 percent each take twice as long as they used to, you have saved far less than the headline number promised. In some processes I have looked at, most of the promised saving had quietly disappeared by the time you accounted for the rest.
The exception queue nobody is watching
There is a second effect on top of that. As long as one person handled everything, the backlog was visible. When work piled up, you could see the pile on the desk. After automation, most of it runs invisibly in the background, and only the exceptions surface somewhere. Usually in a list that nobody really owns.
That list becomes an afterthought. The main process is running, the dashboard is green, the numbers look fine. The stuck 20 percent go unnoticed because they are no longer in the same bucket as everything else. I have seen exception lists where cases sat for weeks while everyone involved was convinced the process was fully automated. The customer whose case was stuck in that list had a different opinion.
What I suggest instead
The first question in an automation project should not be how many percent you can cover. It should be what happens to the rest. A few things have held up well.
Design the handoff as deliberately as you design the automated part. When the automation cannot finish a case, it should not leave it half done. It should hand it to a person cleanly, with everything it already knows. A clear note about what is missing. A definite state. A named owner. The handoff is not an afterthought. It is the actual hard part.
Then ask whether you should tackle the hard 20 percent first. That sounds upside down, but it is often the smarter spend. A person clears the easy cases quickly, so there is little to win there. It is the exceptions that slow them down and wear them out. An automation aimed straight at the painful part tends to return more than one that just makes the easy stuff faster.
And measure your exception rate. Not just how many cases the automation closes, but how many it sends back to a human and how long they sit there. That one number tells you whether you automated the work or merely relocated it.
Sometimes the honest answer is: don't
Some processes have exceptions so frequent and so varied that any partial automation creates more handoff work than it saves. In those cases the most honest thing I can tell a client is that automating is not worth it. Nobody likes hearing that, and it is still true often enough that I keep saying it.
Half an automation is not half of the whole. It is its own thing with its own costs, and the biggest one never shows up on the quote: the person who ends up handling the cases nobody wanted to look at, with less grip on the process than they had the day before you switched the automation on.