TL;DR
- Many manual processes appear reliable because one or more people absorb exceptions informally, and that work never appears in the process documentation or the metrics.
- Automation encodes the documented path. It does not encode the absorber's judgment, so exceptions that were once invisible become visible failures, delivered faster and in volume.
- The apparent failure of an automation project is often a measurement of the process's true exception rate for the first time, not a defect in the tool.
- The analytical question that matters before automating is not "how long does the happy path take?" but "who currently handles what falls off it, and how often?"
The Reliability That Belongs to a Person
Ask an operations team how an order, a claim, a work request or an approval moves through the organization, and the answer describes a path: step one, step two, step three, done. Ask the same team what happens when the path breaks, and the answer changes character. It becomes a name. "Check with the person who has been here the longest." "That one goes to the second desk." "Someone usually catches it."
That change in the answer is the pattern this article examines. A process documented as a sequence of steps frequently has a second, undocumented component: a person, or a small set of people, who absorb the cases the sequence cannot handle. They reconcile the mismatched record, recognize the duplicate, decide whether the odd request is legitimate, and quietly fix the thing before it travels downstream. Call this role the absorber.
The absorber is rarely a job title. It is a behavior that accumulates on whoever is most trusted, most experienced or least able to leave a problem alone. Because the work is done in passing, it is not logged as an exception. It is logged, if at all, as normal throughput.
Why the Absorber Stays Invisible
Three features keep this role out of view, and each one is structural rather than careless.
The fix is faster than the report. Correcting a bad entry takes thirty seconds. Filing an exception record for it takes longer, and the record produces no benefit to the person filing it. Informal repair wins every time.
Success erases the evidence. When the absorber catches a problem, nothing bad happens. The metrics record a clean outcome. The process looks like it has a low exception rate when it actually has a low escaped exception rate, which is a different quantity.
Praise attaches to the person, not the design. Teams describe the absorber as reliable or careful. That language treats the capability as a personal trait, so no one asks whether the process depends on it.
The result is a process whose measured performance overstates the performance of its documented design. The gap between the two is covered by unrecorded human attention. This is an instance of what WBA elsewhere describes as epistemic debt: "The gap between what an organization believes to be true and what is actually true, compounded over time by the cost of acting on that gap." Here the belief is that the process works as written. The reality is that it works as written plus one person's judgment.
What Automation Actually Removes
When a team automates a process, it automates the process it can see: the documented path, plus whatever rules were discovered during requirements gathering. The absorber's behavior is usually not discovered, because it was never written down and the absorber often cannot articulate it. It is tacit knowledge in the plain sense: pattern recognition applied dozens of times a day without a stated rule.
Three things then happen in a recognizable order.
- The happy path accelerates. Early results look excellent. Cycle time drops and the headline metric improves.
- The exceptions stop being caught. The cases the absorber used to repair now flow through the automated step unchanged. Some are rejected by validation and pile up in a queue. Others pass through and corrupt downstream records.
- The problem is attributed to the wrong cause. Teams describe the situation as the automation producing errors. Analytically, the automation is producing the errors the process always generated, minus the correction that used to follow them.
This is why automation is better understood as an amplifier than as a fixer. It scales whatever the underlying process does, including the part that was only working because of a person. A point WBA has made in discussing why technology does not fix broken processes applies with extra force here: the process was not broken in a way anyone could see, which is precisely why it was automated unchanged.
The Exception Rate Is a Different Number
A useful distinction separates two measurements that organizations routinely treat as one.
| Measure | What it counts | Who can see it |
|---|---|---|
| Escaped exception rate | Problems that reach a customer, a ledger or a downstream team | Anyone reading the reports |
| True exception rate | Every case that departs from the documented path, including those fixed in passing | Mostly the absorber |
Before automation, the first number is low and the second is unknown. After automation, the first number rises toward the second. An organization that never measured the true rate experiences this as a sudden deterioration. In effect, the deterioration is a delayed measurement.
This reframes a common conclusion. When an automated process underperforms, leadership often decides the tool was the wrong choice. Sometimes it was. But a more frequent explanation is that the tool was accurate about the process it was given, and the process was never as reliable as its metrics claimed.
The pattern also explains why the failures cluster. They do not spread evenly across the workflow. They concentrate at the points where a person used to look at something and decide. That connects directly to the seam effect: the handoff is often where the absorber sat, so removing the person from the seam removes the only component that was checking it.
Reading the Warning Signs Before Automating
Analysis of this pattern suggests several observable indicators that a process depends on an absorber. None of them require a new tool, only attention to behavior that already exists.
- Answers that become names. If the explanation of how exceptions are handled is a person rather than a rule, the rule has not been written because it has not been understood.
- Workarounds with local vocabulary. Informal terms for recurring problems, such as a nickname for a certain kind of bad record, indicate a high-frequency exception that the system has no category for.
- Unexplained dependence on tenure. If performance drops sharply during one person's absence, the process includes capability that the documentation omits.
- Rework that is never counted. Corrections made in place, with no ticket and no log, mean the true exception rate cannot be calculated from existing records.
A framework-level response follows from these indicators. Rather than asking how much time automation saves, an organization can ask what fraction of cases currently receive a human decision, what that decision is based on, and whether the basis can be stated as a rule. Cases whose handling can be written down are candidates for automation. Cases whose handling cannot be written down are candidates for deliberate routing to a person, with the routing designed rather than left to chance.
The Design Question That Remains
The central finding is modest but uncomfortable: reliability in many organizations is a property of people that has been mistaken for a property of process. Automation is a reliable way to discover which is which, though an expensive way to learn it after the fact.
Organizations that handle this well tend to treat the absorber's work as data. Counting the exceptions, even for a few weeks, converts tacit repair into an explicit distribution of case types. Some of those types turn out to be frequent enough to automate properly. Others turn out to be rare but costly, and are better kept with a human who has been given the role explicitly, the authority to use it and a way to record what was caught.
Without that step, the sequence is predictable. The documented path is automated, the absorber is reassigned or leaves, the exceptions flow unchecked, and the organization concludes that automation is unreliable. The more accurate conclusion is that the process was never reliable by itself.
Research questions on this pattern are welcome through Inquiries.