Artificial intelligence agents work well in the smooth running and break down in the exceptions, which is precisely where the difficult part of any business lies. The standard order is processed automatically; it's the order with a partial delivery, a customer with an open issue, and a commercial agreement negotiated over the phone where it becomes clear whether automation contributes or hinders.
In the processes we've mapped, this set of "rare" cases typically represents between 15% and 30% of the volume. It's not a residual: it's a quarter of the operation, and it usually concentrates a much larger proportion of the value and risk.
Because they can't be taught in twenty minutes. A demo has to be understandable, and exceptions are, by definition, what isn't understandable without knowing the business.
This creates a systematic bias in purchasing decisions. The tool is evaluated based on the easy 70%, it's signed, and the difficult 30% appears in production, when it's no longer a purchasing decision but a project problem. It's the same dynamic we described when talking about the pilot's purgatoryThe pilot, by design, avoids anything that makes production difficult.
There is also a technical reason. A language model doesn't distinguish between "I don't know" and "it doesn't fit with what I've seen." Faced with an atypical case, it doesn't stop: it fills in the gaps. It produces a plausible response built from the patterns it knows, and that response has the same tone of certainty as the correct ones. In an automated process, this indistinguishable confidence is the problem, not the occasional hallucination.
|
Guy |
Example |
How to treat it |
|
Missing or contradictory data |
The client appears with two different tax identification numbers. |
Stop and climb: never choose one |
|
Unwritten business rule |
Condition agreed verbally with a client |
Document the rule or exclude the customer from the flow |
|
Threshold exceeded |
Amount, volume, or discount out of range |
Mandatory human validation |
|
Incompatible state |
Order to a customer with outstanding payment |
Blocking with explicit reason |
|
legally sensitive case |
Health data, minors, decisions about people |
Out of the agent's reach |
The usefulness of this table is not theoretical: it's the script for a two-hour working session with the people who are currently implementing the process. The question to ask them is not "how does the process work"—they'll explain that in their ideal version—but «"Tell me about the last case that gave you trouble."». Three or four people answering that question produce the complete map of exceptions in an afternoon.
The most important aspect of designing an automated system is what happens when it's uncertain. And for something to happen, there has to be a possibility that the system will declare uncertainty.
This requires three design decisions:
Define what a stopping condition is. Not an abstract confidence score, but concrete business conditions: this data is missing, this amount exceeds the threshold, this client is in this situation. Conditions that are understandable to a person are those that can be audited and discussed in a committee.
Define where to scale. A specific queue, with a responsible party and a deadline. An exception that escalates to a generic mailbox has not been resolved: it has been postponed.
Define what information accompanies the scaling. The agent should submit a prepared case: what they found, what's missing, and what options they see. That's where most of the time savings lie, and it's preserved even if the final decision is made by a person.
A system designed this way does not automate the 100% of the process. It automates the entire 70% and prepare the remaining 30%. In almost all cases we've measured, this produces more net savings than trying to automate the 100% and having to review everything due to mistrust.
There is a cultural consequence worth anticipating. When the indicator presented to the committee is the "percentage of automation," the team has an incentive to reduce escalations, and the quickest way to do so is to expand the agent's scope to cases they shouldn't be handling.
Therefore, the correct indicator is not the automated percentage, but the total cost per case resolved correctly. A system that automates the 70% and scales well the 30% is usually cheaper than one that automates the 95% and generates rework, complaints and distrust in the 25% that it shouldn't have touched.
A healthy scaling rate is not a low rate. It is a stable and explainable rate.
There's no need to rewrite it. The usual path has three steps and can be executed without stopping the operation:
The mistake to avoid is trying to implement everything at once. A system with two well-registered layers is infinitely more manageable than one with five partially registered layers.
Exception mapping isn't a preliminary step in the AI project; it is the project. When done well, it produces four deliverables that stand on their own, regardless of whether they are later automated or not:
This is exactly the work we do before proposing any automation, and the reason we insist that First the process is defined, and then it is automated. . It's not a methodological preference: it's the only way to know which part of the process can be automated without discovering it in production.
When a vendor presents an agent-based solution, ask for one specific thing: that the demo includes the rare case of your choice.
Not a generic, rare case. One of yours, with your incomplete data and your unwritten business rule. The response to that request separates someone who has built a system from someone who has created a presentation.
If the answer is that this case will be dealt with at a later stage, you already know where the project's cost overrun will be.
Because a language model doesn't distinguish between "I don't know" and "this doesn't fit with what I've seen": faced with an atypical case, it doesn't stop, it completes the process. It produces a plausible response with the same tone of certainty as the correct ones, making the error difficult to detect within an automated process.
In the processes we've mapped, these typically occur between 15% and 30% of the volume, although they concentrate a larger proportion of the value and risk. This isn't a statistical residual: it's a substantial part of the actual operation.
Ask those who implement it about the last case that gave them trouble, instead of asking them to describe the process. With three or four people, you can obtain the complete map in one session. The usual types are: missing or contradictory data, unwritten rule, threshold exceeded, incompatible status, and legally sensitive case.
Stop and climb, with three elements defined beforehand: stopping conditions expressed in business terms, a specific queue with responsible party and deadline, and an information package that includes what was found, what is missing, and what options are seen.
Normally not. Automating the entire 70% and preparing the remaining 30% usually results in greater net savings than automating the 95% and generating rework, complaints, and mistrust in cases that shouldn't be automated. The correct indicator is the cost per case resolved successfully, not the percentage automated.
Include a rare case study chosen by the client, with its incomplete data and unwritten business rules. If the vendor postpones that case to a later phase, that's where the project cost overrun will appear.
|
Before automating, we map. We identify the actual process, the unwritten rules, and the exceptions that would break any automation, and we tell you which parts deserve to be automated. Two hours of analysis with no obligation. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
