Exception Handling: the Hidden Cost AI Can Reach First

Case and exception handling is the largest capability in the MetroMinds Library. Why AI can reach exception work early, and what the business case really covers.

MetroMinds · 18 October 2026 · 7 min read

After a long weekend sale, the COO of an online retailer opens the operations dashboard and sees 900 open exceptions: returns outside the normal window, refunds that do not match the order, parcels the carrier scanned twice. Each one needs someone to read the history, check the policy and make a call. Nobody planned for this queue, yet it comes back every week. That is why AI exception handling is often the most practical place for a COO to start with AI.

Exceptions rarely appear in strategy documents, but they consume a large share of operational capacity. They also tend to land on the same experienced people, who are then unavailable for anything else.

The biggest single capability in the Library

The MetroMinds Library links each of its 4,980 use cases to a . The L3 capability with the most use cases is case and exception handling, with 346. No other capability comes close: the next one, service delivery management, has 220.

The spread is just as telling. Those 346 use cases come from 13 industries and 57 subindustries, from healthcare (41 use cases) and education (34) to retail (29), manufacturing and telecoms. They also use every one of the 12 in the Library, from conversational AI to document understanding and agents. Exception work is not a niche of one sector. It is a common layer in almost every operation.

It is also where much of the value logic is the same. For more than half of these use cases (181 of 346), the headline benefit is a reduction in handling time. And 221 of them, almost two in three, also include a benchmark for less error and rework, because an exception handled badly tends to come back.

Exceptions are not only in the exception queue

You might expect exception handling to be the most ambiguous work of all. The Library suggests otherwise. Every use case is scored on how many exceptions and how much ambiguity the work involves. For case and exception handling, 86 percent of use cases score 4 or 5 out of 5. For all other use cases it is 88 percent.

Grouped bar chart of the Exceptions and Ambiguity score: for case and exception handling 2 percent score 2, 12 percent score 3, 48 percent score 4 and 39 percent score 5; for all other use cases the shares are 2, 9, 41 and 47 percent. — Source: MetroMinds Library, 4,980 use cases (August 2026). Distribution of the Exceptions / Ambiguity score.

In other words, almost all AI use cases deal with exceptions, wherever they sit. The difference is that in case and exception handling the exceptions arrive in a queue, with a known shape, a named owner and a policy to check against. Fewer of them reach the extreme end of the scale: 39 percent score 5, against 47 percent for the rest.

Why AI can reach exception handling first

That bounded shape shows up in the delivery scores. Case and exception handling use cases score 3.50 on feasibility, against 3.29 for the rest of the Library. Their risk score is lower as well, 3.66 against 3.83. Business value is roughly the same, 3.73 against 3.83.

For a COO, that combination is attractive. The work is frequent, the data usually sits in one or two systems, and the decision can stay with a person while the AI does the preparation. You can start in one queue, measure the effect and then extend it to similar queues elsewhere.

Analysts expect a lot from this area. Gartner predicts that "by 2029, agentic AI will autonomously resolve 80% of common customer service issues without human intervention", leading to a 30 percent reduction in operational costs [1]. Whether or not that timeline holds, the direction is clear. The common cases will be automated first, and the real exceptions will remain for people, better prepared than today.

Scenario

Working through a Monday exception queue

Back to the online retailer with 900 open exceptions. Today each one takes a specialist about 12 minutes: open the order, read the conversation, find the right version of the returns policy and decide. That is 180 hours of work, more than the team can clear before the next wave of orders.

With AI preparation, each exception arrives with a short case summary, the policy clause that applies on the purchase date and flags for anything unusual. The specialist reads, checks and decides. Exceptions above the desk limit, or with signs of fraud, go straight to the store or operations manager.

180 hoursThe Monday queue today: 900 exceptions at 12 minutes each
36 hoursSaved at the Library midpoint of 20 percent less preparation time
4.8 daysOf specialist time returned to the team, at 7.5 hours a day

The figures are illustrative. The 20 percent is the midpoint of the for the use case below; the queue size and minutes per exception will differ per organisation.

From the MetroMinds Library

Deciding a returns exception while the customer waits at the desk

Industry Retail & Consumer Goods, General Merchandise
AI domain Augmentation, productivity support
Role Customer Care Specialist, with the Store Manager on thresholds
Capability Operations and Delivery > Service Fulfillment > Case and Exception Handling

A returns policy exception reaches the care desk with the customer waiting. The AI pulls the conversation, order and refund history and loyalty record, checks them against the policy in force on the purchase date and returns a summary with the clause reference. It flags a receipt that does not match the item or a product under a safety notice.

12 to 28% less preparation time per case
15 to 35% less time searching for context
5 to 16% less rework from missed context

Library note: search time is already part of the preparation time, so the two are not added up. Workforce impact: less looking up, more checking and deciding, and refusals recorded with reasons that show where the policy needs rewriting.

Book a demo

What the business case covers, and what it leaves out

Exception handling is a good place to be honest about money. The saving per exception is real but modest, and the bigger effect is often on waiting time and on how many exceptions the team can close before they age. The box below works out a full year for the same retailer.

Worked example

A year of returns exceptions, in hours and euros

The retailer handles 75,000 returns exceptions a year at 12 minutes each, which is 15,000 hours. A specialist costs 34 euros an hour fully loaded. We use the benchmark range of the use case above (12 to 28 percent less preparation time) and apply a of 80%, an of 65% and a of 75%, which together come to 39%. All inputs are illustrative.

1,170 hoursHours that count in the business case at the midpoint (15,000 x 20% x 39%)
39,780 eurosAnnual value at the midpoint, within a range of 23,868 to 55,692 euros
9.6 minutesHandling time per exception at the midpoint, down from 12, while the customer waits

Those hours only become money when the team uses them: clearing the backlog faster, absorbing peak weeks without temporary staff or avoiding a new hire. If the time simply disappears into a quieter desk, the benefit is a better customer experience rather than a saving.

Two things are deliberately left out of this figure. Search time is not added on top, because it is already part of the 12 minutes. And the reduction in rework only counts once the retailer knows how often an exception is decided wrongly today and what that costs. Both rules come straight from the Library record for this use case.

Keep a person within reach

Customers notice how exceptions are handled. In a Gartner survey of 5,728 customers, 64 percent said they would prefer companies not to use AI for customer service, and the top concern was that it becomes more difficult to reach a person [2]. Exceptions are exactly the moments when a customer wants someone to listen.

That is a strong argument for the design used in most exception use cases in the Library: the AI prepares, the specialist decides, and a clear threshold sends the case to a manager. The customer gets a faster answer from a person who is better informed, rather than a slower answer from a machine.

Where to start in your own operation

Which exception queues come back every week, and how many hours do they take?
Is there one policy or rule set the AI can check against, with a clear version history?
Which exceptions must always go to a manager, and is that threshold written down?
How will you know whether the specialist accepts or overrides the AI's preparation?
What will the team do with the hours it gets back in peak weeks?

Most COOs can answer the first question quickly. The others decide whether the first exception use case becomes a template for the next five queues, or a one-off pilot.

How MetroMinds helps you find the right queue

Start in the MetroMinds Library with the process you know is under pressure, such as returns, claims or service requests, and narrow it down by risk level and data readiness. Each use case comes with benchmark ranges, the factors behind the business case and a clear note on which benefits cannot be combined.

Once the candidates are in a portfolio, the matrix sorts them into , Quick improvements, Strategic bets and Park / rethink, so you can pick the queue to start with and agree its status with the process owner. If you are building the wider case for operations, read why half of all AI ideas end up on the COO's desk. For the risk of counting the same minutes twice when several queues get AI support, see your AI business cases are counting the same savings twice.

How ready is your organisation to let AI take on the first exceptions? Take the AI Readiness Snapshot

Sources

Gartner, "Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029", press release, 5 March 2025.
Gartner, "Gartner Survey Finds 64% of Customers Would Prefer That Companies Didn't Use AI for Customer Service", press release, 9 July 2024.
MetroMinds Library, 4,980 AI use cases with benchmark ranges based on real-world implementations, August 2026.

Next in the COO route · article 3 of 5