When a messy process is automated, the messiness doesn't disappear; it just changes scale and speed. An ambiguous criterion applied by a person produces inconsistent decisions that someone eventually notices; the same ambiguous criterion applied by a system produces thousands of consistently wrong decisions before anyone notices.
That change of scale is what makes automating a bad process worse than leaving it as it was, and not just the same.
The error ceases to be detectable by contrast. In a manual process, inter-person variability acts as an alarm system: when someone solves a case differently, the difference is discussed and the approach is corrected. Automation eliminates this variability and, with it, the warning signal.
The correction ceases to be punctual. Discovering an error three weeks later doesn't mean fixing a case; it means reviewing and redoing everything processed during those three weeks. The cost of reverting the error increases linearly with the detection time.
Exceptions are multiplying instead of decreasing. A poorly defined process generates cases that don't fit. Even when automated, these cases keep coming in and now require manual handling outside the workflow, which often results in more work than before.
Responsibility becomes blurred. When a case is handled incorrectly, the response becomes "the system did it." And that's not a helpful response to a customer or an auditor, as was clear in the Air Canada chatbot case resolved in 2024: the company is responsible for what its software does.
Moment | What is observed | What's really going on? |
|---|---|---|
Weeks 1-2 | Everything is working, there's enthusiasm | Easy cases are processed |
Weeks 3-6 | "Rare" cases appear« | Undesigned exceptions emerge |
Months 2-4 | Parallel manual labor is growing | The process has forked |
Months 4-6 | A systematic error is detected | The historical data needs to be reviewed. |
The sequence is so repetitive that it serves as a diagnostic tool. If an automation project goes well for the first few weeks and then starts generating parallel work in the second month, the problem isn't the implementation: it's that the process wasn't defined when it was automated.
There is a preliminary check that takes an afternoon and prevents most of these cases: Give the same set of twenty real-life cases to three different people on the team and compare their decisions.
If all three criteria agree on eighteen or more, the process is well-defined enough to be automated. If they agree on twelve, there is no process: there are three criteria coexisting, and automation means choosing one of the three without telling anyone.
This exercise also has a political virtue: it turns an abstract discussion about the maturity of processes into a fact that no one disputes.
Discovering that a process isn't ready doesn't mean you have to postpone everything for six months. There are three interventions that produce rapid value:
Define the criteria in frequent cases. Not all: the 80% section of the volume usually focuses on four or five situations. Writing down the criteria for those five resolves most of the ambiguity in a working session.
Automate only the preparation. Gather the information, compare it, and present it so that a person can make a decision. This captures a significant amount of savings and avoids spreading misinformation.
Instrument before automating. Measuring the manual process over a few weeks produces the baseline and reveals the actual variability, which is exactly the missing piece of information needed to make a decision.
All three are compatible with moving forward. None of them requires a complete redesign project before making any changes.
It is important to put a number on the reversal, because it is the item that turns a profitable project into a ruinous one.
If a system processes two hundred cases daily and a systematic error is detected after six weeks, there are approximately six thousand cases to review. Even if only the 10% case is affected, that's six hundred cases to correct, along with the associated communication with the client, accounting adjustments, and reputational impact.
That calculation almost never appears in the business case, and that's why time to failure should be a committee metric, as we argued in Automation without observability is irresponsible
Before automating any process, there is one question that guides the decision: If this is systematically wrong, when would we find out and how much would it cost to undo it?
If the answer is "in hours and with one click," the risk of automating an imperfect process is acceptable, and it's worth moving forward. If the answer is "in weeks, and we'd have to review the historical data," the process needs to be defined before it can be automated.
It's not a matter of prudence. It's arithmetic.
The disorder changes scale: an ambiguous criterion applied by a person produces inconsistent decisions that someone eventually notices, while applied by a system it produces thousands of consistently wrong decisions before anyone detects it.
Because individual variability acts as an alarm system: when someone resolves a case differently, the difference is discussed and the approach is corrected. Automation eliminates this variability and with it the signal that allowed the problem to be detected.
By giving the same set of twenty real-world cases to three people on the team and comparing their decisions. If they agree on eighteen or more, the process is defined; if they agree on twelve, several different criteria coexist, and automation means choosing one without explicitly deciding.
Three things compatible with moving forward: define the criteria for the four or five cases that concentrate the 80% volume, automate only the preparation of the information leaving the decision to a person, and implement the manual process for a few weeks to obtain the baseline.
It grows with the detection time. A system that processes two hundred cases daily with a fault detected after six weeks implies reviewing about six thousand cases; even if only 10% is affected, that's six hundred corrections with their communication to the client and their accounting adjustment.
If the system makes systematic errors, when would they be detected and how much would it cost to correct them? If the answer is within hours and with a single click, the risk is acceptable; if it takes weeks and requires reviewing historical data, the process needs to be defined before it can be automated.
Is your process ready to be automated? We test it with real-world cases before writing a single line of code, and we tell you which part should be automated and which part should be defined first. Let's talk →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
