The problem in plain language
As automation programmes mature, the rate of human exception handling can outstrip automated throughput. The automated path processes more invoices, orders, claims or requests than before, but each item that the automation cannot handle lands in a queue for a person. Those queues grow, cycle times stretch and service levels are missed. The expected gains from automation erode, even though the automation itself is working as designed.
Teams often notice the symptom before they understand it: the automation dashboard looks healthy while the exception inbox keeps getting longer.
What the buyer is actually trying to solve
The buyer wants to rebalance the workload, reduce queue growth and extend automation coverage to more of the end-to-end process, without sacrificing governance or risk controls. Search language includes “automation exceptions backlog”, “too many manual exceptions after RPA”, “human in the loop queue management”, “exception handling automation” and “why automation did not reduce headcount effort”.
The underlying question is whether the organisation is automating the work or simply moving the difficult part of the work into a different queue.
Evidence and system mechanism
Initial automation often targets a subset of process paths. As volume grows and edge cases accumulate, human intervention increases. The arithmetic is straightforward: if a stable share of items fall out of the automated path, exception arrivals rise in step with volume. If the people handling exceptions do not scale, or the exceptions are harder per item than the work they replaced, the queue grows.
Google's Site Reliability Engineering guidance gives a useful lens. It defines toil as work that is manual, repetitive, automatable, tactical and without enduring value, and notes that if the work involved in a task scales up linearly with service size, traffic volume or user count, that task is probably toil. Exception handling that grows with every additional transaction fits that description. The same guidance describes Google's practice of keeping operational work below half of an engineer's time, so that the remainder can go into engineering that reduces future toil. The specific target is Google's own; the principle that recurring manual work must be deliberately engineered down applies more widely.
Human review can be designed rather than left to accumulate. Amazon's documentation for Augmented AI describes human review workflows that are triggered when a model cannot make a high-confidence prediction, or for random samples used to audit results, with reviews handled by defined work teams. AWS notes that the service is no longer open to new customers, so it is cited here for the mechanism rather than as a recommendation: routing to people follows explicit conditions, the review work is structured, and results can be fed back to improve the automated path.
The mechanism behind growing queues therefore includes narrow coverage, insufficient routing and a lack of end-to-end orchestration between automated and human tasks.
Problem owner and why now
The owners are typically operations managers, who live with the queue, and automation leads, who own the automated path. Process owners, finance and customer-service leaders feel the impact, and the budget often sits with the COO or the head of shared services.
Queue growth signals fracture points in the automation chain and threatens customer experience and throughput targets. Urgency usually rises when:
- volumes increase after a launch, acquisition or seasonal peak;
- service levels are missed for work that was supposed to be automated;
- exception handlers are recruited or reassigned to keep up;
- a new automation phase is proposed while the previous one still depends on manual clean-up.
Economic consequence
The economic impact is slower cycle times and higher labour cost per unit of output. Specific effects include:
- Labour that scales with volume: exception handling grows with each additional transaction, offsetting automation savings.
- Delay costs: items waiting in queues hold up payments, fulfilment or customer responses.
- Quality risk: rushed manual handling of a growing queue increases error and rework.
- Misleading business cases: automation benefits are reported on throughput while the exception cost is absorbed elsewhere.
Measure exception rate by type, queue age, handling time per exception and the trend in exception volume relative to total volume.
Root cause
The queue is the symptom. Plausible root causes include:
- Limited process discovery: automation was designed from the main path without understanding the full set of variants.
- Inadequate exception handling: exceptions are dumped into one undifferentiated queue rather than classified and routed.
- Insufficient orchestration: automated and human tasks are not managed as one process, so items stall at the handover.
- No feedback loop: the reasons for exceptions are not analysed, so the same causes recur.
- Upstream data quality: many exceptions originate in missing or inconsistent source data rather than in the automation.
Practical intervention
The intervention broadens automation scope to capture more process variants, introduces intelligent routing for exceptions and sets guardrails so that high-value exceptions are either automated or handled efficiently with human-in-the-loop processes.
- Classify every exception by reason, value and handling effort for a representative period.
- Fix upstream causes, such as data quality or missing reference data, before adding more automation.
- Automate the highest-volume, rules-based exception types as new process variants.
- Route the remaining exceptions by type, skill and priority, with clear service levels.
- Orchestrate automated and human steps as one workflow with visible state at each handover.
- Feed exception outcomes back into the automation backlog and review the trend monthly.
This is closely related to automation that covers only the happy path and to deciding which processes are safe to automate.
Diagnostic questions
- What is the current ratio of automated to human-handled exceptions?
- Are exception paths codified and monitored?
- Can we increase automation coverage without compromising risk controls?
- Is exception volume growing faster than total volume?
- Do you know the top five exception reasons, and who owns fixing each?
What good looks like
Exceptions are classified, routed and measured. The exception rate falls over time because recurring causes are removed or automated. People handle the cases that genuinely need judgement, with the context to do so quickly. Automation benefits are reported net of exception effort, so leadership sees the real position.
Where Mellorca fits
Mellorca can help design governance for exception handling, create end-to-end orchestration and accelerate the expansion of automation coverage to reduce queues. That work sits within Business Automation & AI Workflows and Digital Operations Improvement.
Commercial path
A sensible path is: Discovery article → exception analysis → routing and orchestration design → targeted automation of exception variants → ongoing exception monitoring.
Method note
This article describes a common pattern in automation programmes. The cited sources describe toil and human review mechanisms; they do not measure exception rates in any particular organisation. Use your own process and queue data to confirm whether this pattern applies.
Sources and further reading
- Google SRE - What is Toil in SRE: Understanding Its Impact (last verified 10 October 2026)
- Using Amazon Augmented AI for Human Review - Amazon SageMaker AI (last verified 10 October 2026)
Related Mellorca reading
- Agent conversations are not connected to durable business records
- Automation incident response is improvised
- Automation candidates are chosen by novelty instead of business value