Robotic process automation earned a mixed reputation honestly. It delivered quick wins, and it also produced estates of brittle bots imitating a human clicking through a system that had an API all along.
The technology was never the issue. The issue was that a bot could be delivered without anyone asking whether the process should exist.
Three questions before automating anything
- Should this step exist at all? A surprising share of copying between systems exists because a report was requested once, years ago, by someone who has since left.
- Is there a supported interface? An API, a file drop or a database view will outlive a screen. If one exists, use it, even if the bot would be quicker to build this quarter.
- How often does the interface change? Automating against a vendor SaaS screen that updates monthly is a maintenance commitment, not a project.
What “intelligent” adds
The useful addition is handling inputs that are not perfectly structured: reading an invoice whose layout varies by supplier, classifying an inbound email, extracting fields from a scanned delivery note. Combine that with a deterministic workflow and you can automate cases that pure rules could not reach.
The important design point is the confidence threshold. Documents the system is sure about proceed automatically; those below the threshold route to a person with the extracted fields pre-filled. That queue is not a failure of the system — it is the mechanism that makes the automated path safe.
Measure exceptions, not just volume
Automation programmes report cases processed. The number that predicts sustainability is the exception rate and its trend. A stable or falling exception rate means the process and the automation still agree. A rising one means something upstream changed and the bot is quietly producing rework.
Governance that keeps the estate alive
- Every automation has a named business owner, not just a technical one.
- Credentials sit in a vault, never in the automation itself, and bots have their own identities so their actions are attributable.
- Automations are reviewed annually and retired without ceremony when the underlying process changes.
When to fix rather than automate
If the process is slow because of an approval chain nobody defends, automation makes an unnecessary chain faster. If data is retyped because two systems were never integrated, integration is the cheaper permanent answer. Automation is at its best where the work is genuinely necessary, genuinely repetitive and genuinely stable — and at its worst as a way of avoiding a difficult conversation about process design.
