There is a version of automation that quietly makes an organisation worse. It arrives as a demonstration, it works on the example everyone agreed to look at, and it is deployed into a process nobody had mapped properly. Six months later the team has a tool it does not trust, a manual workaround for the cases the tool cannot handle, and no clear way to tell which is which.
The failure is rarely technical. It is almost always that the automated step was not the constraint.
Start with where the work actually waits
Before choosing a technology, find out where work sits idle. In most operational processes the delay is not in the doing, it is in the waiting — for an approval, for a missing piece of information, for someone to notice a queue has grown. Automating the doing, when the waiting is the problem, produces a faster step inside a process that finishes at exactly the same time.
The diagnostic is unglamorous: take twenty real cases, timestamp each transition, and look at where the gaps are. The answer is usually not where the enthusiasm is.
Ask what happens when it is wrong
Every automated decision has an error mode, and the useful question is what that error costs. Classifying a support ticket incorrectly costs a redirect. Approving a payment incorrectly costs money and trust. The same accuracy figure means entirely different things in those two contexts.
This is what should determine how much human oversight a system needs — not how impressive the model is. High-consequence decisions keep a person in the loop, and the interface should make the machine's reasoning inspectable rather than presenting a verdict.
Measure before, or you cannot claim after
If there is no baseline, there is no improvement — only a feeling that things seem better. Capture the current cycle time, error rate, and volume before anything changes. It is a few days of work and it is the difference between a result and an anecdote.
It also protects you. When automation genuinely helps, the numbers make the case far better than a demonstration can.
The honest filter
Three questions, in order. Is this step actually the constraint? What does a wrong answer cost, and who catches it? Do we know what 'better' would look like numerically? A proposal that cannot answer all three is not ready, regardless of how good the technology is.
Automation that passes this filter tends to be less exciting than the pitch and considerably more useful than the average deployment.
