“We’ve Automated Everything… Except the Parts That Require Human Judgment”
CIOs say this almost as a footnote. “The process has been largely automated over the past year. Straight-through where possible, rules-based where necessary. Of course, there are still a few steps that require human judgment.”
No one objects. No one asks how often those steps occur. The phrase sounds reasonable, responsible even. Automation has limits, after all. Judgment is human.
But that single phrase captures why so many enterprise automation programs stall after their initial success. Because in complex organizations, those parts are not rare. They are frequent, messy, and disproportionately expensive. And over time, they quietly become the way the process actually runs.
When Automation Meets Reality
On a slide, automated processes look clean. Inputs arrive, logic is applied, systems update, outcomes are produced. The “happy path” flows neatly from left to right. In demos, everything works exactly as designed.
In production, reality intrudes almost immediately. Data arrives incomplete. Documents are delayed. A rule conflicts with a regional policy. An approval depends on context that isn’t stored anywhere. The automation does what it was built to do: it stops.
At that point, the process doesn’t fail loudly. It simply exits the system.
A task lands in an inbox. An analyst opens three applications. Someone downloads a spreadsheet to “figure it out.” A decision is made based on experience, instinct, or whoever happens to be available. Once resolved, the process continues but the system learns nothing from what just happened.
This is the manual exception. And in most enterprises, it is no longer the edge case. It is the dominant mode of operation.
Why Exceptions Rarely Appear in ROI Calculations
From a CIO’s perspective, this creates a distorted picture. Automation metrics show progress. Bots are running. Volumes are up. Cost-per-transaction appears lower. On paper, the business case holds.
What those numbers rarely capture is the gravity of exception handling. Manual exceptions are distributed across teams and tools. They live in email threads, chat messages, personal files, and informal handoffs. No single system owns them. No dashboard fully reflects them. They are operational dark matter.
Yet they consume enormous energy. They absorb senior attention. They generate escalations that inevitably land in IT. Over time, they become the reason automation feels fragile instead of transformative.
The organization believes it has simplified work. The people doing the work know better.
The Myth of “Human Judgment” as a Catch-All
When exceptions are discussed, they’re often justified as unavoidable. Some decisions, the argument goes, are simply too nuanced to automate. They require experience, discretion, judgment.
Sometimes that’s true. More often, “human judgment” is a euphemism for something else: missing data, unclear ownership, poorly defined rules, or systems that don’t talk to each other. The human isn’t applying wisdom; they’re compensating for gaps in the architecture.
This distinction matters. Because when judgment is treated as something outside the system, it becomes unstructured by default. Decisions are made without consistent context. Similar cases are handled differently. Knowledge accumulates in individuals rather than processes. And when those individuals move on, the organization relearns the same lessons the hard way.
How Exceptions Fragment the Automation Stack
Over time, manual exceptions reshape the automation landscape in subtle but damaging ways. Workarounds harden into unofficial processes. Side tools emerge to “support” the exceptions. Email becomes the approval layer. Spreadsheets become the source of truth.
None of this was designed. It simply evolved.
For CIOs responsible for architecture coherence, this is where the real cost shows up. The automation stack grows wider but less integrated. Governance becomes harder. Risk increases. IT is pulled into operational firefighting rather than strategic enablement.
The organization hasn’t reduced complexity. Instead, complexity is displaced into places that are harder to see and harder to control, making it even harder to track.
Why Exceptions Hit IT Harder Than the Business Expects
Most automation initiatives originate in the business. Finance wants faster close. HR wants smoother onboarding. Supply chain wants resilience. Operations wants fewer delays. IT is asked to enable all of it, often across a growing ecosystem of tools.
Exceptions, however, don’t respect organizational boundaries. A single invoice exception might involve procurement data, contract terms, vendor master records, tax logic, and finance policy. When something goes wrong, it doesn’t escalate neatly back to the process owner. It escalates to IT.
From the CIO’s chair, this feels like being accountable for processes you don’t fully own and decisions you didn’t design. The more exceptions proliferate, the more IT becomes the default integrator of last resort.
Where Intelligent Automation Changes the Equation
This is where the conversation about AI and orchestration often goes wrong. Not because the technology lacks potential, but because it’s positioned as a replacement for judgment rather than an infrastructure for it.
The real opportunity is not to eliminate human involvement, but to stop treating exceptions as bespoke events. When systems can retain context, recognize patterns across past deviations, and guide decision-making with relevant information, judgment becomes faster, more consistent, and less exhausting.
In mature environments, exceptions stay inside the process instead of ejecting from it. They are classified, contextualized, and resolved in ways the system can learn from. Over time, the volume of manual intervention decreases, but simply because the organization gets better at handling it.
The Difference Between “Automated” and “Operable”
A process isn’t truly automated when it runs end-to-end once. It’s automated when it can survive variability without collapsing into manual chaos. When it degrades gracefully. When it explains itself. When it doesn’t rely on institutional memory to function.
This is the difference between automation that looks good in a demo and automation that holds up under pressure. CIOs recognize this instinctively, even when it’s difficult to quantify. They see it in cycle times that remain unpredictable, in teams that still rely on key individuals, in systems that work beautifully right up until they don’t.
A Better Question for Automation Leaders
Instead of asking how much of a process is automated, a more revealing question is what happens when it breaks. Who owns the decision? Where does the context come from? Is the outcome captured, or does it vanish into someone’s inbox?
Why Exceptions Are the Real Lever for ROI
The irony is that exceptions often involve the highest-value work. They tend to touch larger amounts, higher risk, or more sensitive decisions. Improving how they are handled delivers outsized returns in control, resilience, and trust.
For CIOs tasked with turning automation into a durable enterprise capability, this is where focus pays off. Not by automating more happy paths, but by bringing structure, visibility, and learning into the moments where automation traditionally gives up.
Final Thought
When someone says a process is automated “except for the parts that require human judgment,” it’s worth slowing the conversation down. Because those parts are not the remainder. They are the core.
Automation isn’t proven when everything goes right. It’s proven when things go wrong and the system still knows what to do.