Over the years I have signed off on process redesigns I was pleased with. The team had done the work properly: we mapped the current state, cut the handoffs, agreed the new flow, and trained everyone on it. For about a quarter it held. Then it came back, not as the old process but as the new one with small local variations bolted onto it that nobody had designed and nobody could quite explain.
For a long time I treated that as the cost of doing business. Processes are never perfect, organizations are messy, and people work around things. What has changed is how much that mess now matters. As automation gets better at handling the ordinary work, more of the economic value sits in everything outside the ordinary path, and that is usually the part nobody has counted.
Here is one I can explain, because we did it to ourselves. Some of our customers pay in bulk. A partner settles ten or more invoices with a single transfer, and for a short window our collections system cannot tell which invoices that payment covers. So the automation did what it was designed to do. It chased. Automated reminders went out on invoices that had already been paid, one of them marked as a final notice, until a partner’s commercial lead escalated it to us.
Nothing was broken. The process ran exactly as designed, against cases it had not been designed for. We fixed it by taking that entire customer class out of the standard flow and building them a second one that runs alongside it.
We did not remove the exception. We gave it its own process.
That pattern is more common than I used to admit. The instinct is to blame the rollout, the training, or the team that never really adopted the new process, and sometimes that is fair. More often the design was sound and the problem was that we had built for the part of the business we could describe. Work outside that description does not disappear. It gets handled another way: by a person, a spreadsheet, an inbox, or eventually a second process built specifically for it.
Automation Has a Ceiling and Your Exceptions Set It
Efficiency programs assume that the cases moving through a process are broadly similar. One approval path. One customer type. One asset behaving one way. One set of systems a workflow can be written against.
Automation only reaches what somebody has described. That is true of a script, and as I will come to, it remains true of an agent. So the share of your work sitting in cases nobody has identified is not a quality problem or a tidiness problem. It is the part of the process that no automation program can be aimed at, because nobody knows to aim it there. That is the ceiling, and you set it long before you choose a tool.
There is a second effect underneath it. Automation takes the mechanical part of a process and leaves the verification intact, and verification is usually where the human cost was sitting. If a third of the cases still need a human eye, and you cannot tell in advance which third, someone is still looking at all of them. That is how the percentage automated ends up looking impressive while the economic value disappoints, and we have all sat through the readout where those two numbers do not reconcile.
Every automation business case I have seen assumes the process is what the design document says it is. I have never seen one price the difference between that and the operation it is actually running against. We do not treat it as a risk, or a range, or an assumption worth testing. We leave it out.
Agentic AI raised the automation ceiling. It did not change what sets it. Your unmanaged exceptions still do.
Agents Handle the Variance They Can Find
The strongest objection to everything above is that agents have changed this. They have. An agent can interpret messier inputs and take on variance that would previously have stopped a rule-based workflow, and that genuinely expands what is reachable.
The pitch is that the agent will handle the messy work. What it actually handles is the messy work you can point it at. Every agent demo I have sat through runs against a described process, and the gap between that description and the operation is not the vendor’s problem.
We had an example in invoicing. Most of the process ran automatically. Behind it sat an exception queue that one person worked through as part of their job, and nobody thought much about it because for years it simply worked. Then that person moved to another role, the backfill was not clean, and it took us some time to notice that a number of invoices had stopped being created.
Everyone assumed they were automated. They were. Most of them.
That queue is exactly the kind of work an agent could take over now, and probably should. But somebody has to know it exists first, and understand what arrives there and why, and none of that had been written down because it had never needed to be.
Agents can absorb the long tail. They cannot find it for you.
The Easy Version
Both of my examples come from the same function, which may be telling me something. But this is not only our problem, and it shows up in the easiest possible place.
In first conversations with prospective customers over the last twelve months, at least 75 separate organizations described a spreadsheet as the way they track their IT assets. Not as a confession. As a description of normal. One had been running that way for eleven years, and when the person responsible stopped trusting the file they rebuilt it from scratch: a day and a half, three times a year.
IT assets are the easy version of this. They have serial numbers, they sit in systems, and mature tooling exists to count them. These were organizations that had not yet solved the easy one. If that is where we are on the things specifically designed to be counted, I would not bet much on our understanding of the operating processes built around them.
Finding them is partly a tooling problem, and tooling does more here than people assume. Dependency mapping shows what talks to what, and usage data shows who still touches a system and who stopped years ago, which narrows the question considerably. It does not close it. Nothing in a scan decides whether a workaround is legitimate, or who should own it. Data can be discovered. Context has to be decided.
The Question I Ask Now
Until recently I could not have told you what share of our own work runs on cases nobody designed for. I used to think of exceptions as noise around the process. Now I think they are information about it. They tell you where your design stops matching the organization, and increasingly they tell you where the next automation opportunity actually is.
Looking back, in many of the improvement programs I ran we were fixing the consequences of not having a complete picture of what had to arrive at the process: customer types, sites, legal entities, systems feeding it, exceptions inherited through an acquisition, workarounds that had become normal because the person doing them had been there long enough that nobody noticed. We automated the hand-work, closed the project and booked the savings. The missing cases were still missing, so the work came back somewhere else. I ran those programs. I signed the business cases.
So I have changed the question I ask. Before asking what else we can automate, I want to know what is still falling out of the process today. What did someone handle by hand last week, what kind of case was it, and why did it fall out?
That is much less glamorous than talking about agents. It is also where the work is.
You will not eliminate these cases and you should stop planning as though you might. Some are legitimate, some will always need judgment. What you can stop doing is being surprised by them. Once you know they exist you can decide: standardize them, automate them, leave them deliberately manual, or redesign the operating model around them. Until then they are simply work your automation business case never saw.
If you want to know whether this applies to you, the test takes a week. Ask your team to log every case they handled by hand, and what kind of case it was. I doubt most organizations could produce that list, and being unable to produce it is the answer.
We automate the company we can describe. The next step is making sure the company we describe is the one we actually run.
