What automation costs to run, not just to build
Most automation business cases are right about the build and silent about the next three years.
Updated September 2026
- Screen-based automation breaks when the target application changes. That is a scheduled cost, not an incident.
- Exception handling is work that remains. Counting it as a saving is how cases overstate the benefit.
- Unmonitored automation fails silently, and the cost of a silent failure is paid later at a premium.
- Price three years. The first year always looks better than the steady state.
An automation business case usually compares a build cost against the hours it removes. Both numbers are often right. What is missing is everything between go-live and the end of the third year.
1. Platform and licences
Automation platforms are licensed by robot, by capacity, by consumption, or by some combination — and the model has been moving toward consumption. That changes the profile: cost grows as you automate more, which is the direction you intend to go.
Model this against your expected volume rather than against a list price, and check what happens at the next tier. The step between tiers is often where a business case quietly stops working.
2. Maintenance
Every automation is coupled to something that changes. An API version, a screen layout, a file format, a permission model.
Screen-based automation is the most exposed: a cosmetic change in the target application can stop it. This is predictable rather than exceptional, so it belongs in the plan as scheduled maintenance capacity rather than being treated as a series of incidents.
Automation engineered as software — reusable components, configuration separated from logic — costs meaningfully less here than automation that was recorded. The difference compounds across a portfolio.
3. Exception handling
The cases the automation cannot complete. Someone has to work them, and they are by definition the harder ones, because the straightforward cases went through.
This is real ongoing work and it belongs in the operating cost. Business cases that count the whole volume as saved, with exceptions unmentioned, overstate the benefit by however large the exception rate turns out to be.
4. Monitoring and support
Automation fails silently by default. A process that stopped running at the weekend and was noticed on Wednesday has done more damage than one that failed loudly on Saturday.
That means monitoring, alerting to a person, and someone who knows what to do when an alert arrives. Small cost, and the thing that prevents the expensive failures.
5. Change, including the change you are planning
When the underlying process is redesigned, the automation is redesigned with it. When a source system is replaced, everything touching it is rebuilt.
Worth checking against the roadmap before building: automating a process on a platform scheduled for replacement is a short-lived asset.
How to present it honestly
Three years, with build in year one and the five run costs in each year. Against the current cost of doing the work, including the error rate and the delay.
Cases built this way are less dramatic and they survive review. They also rank the candidate list properly, because the high-volume processes absorb the run cost easily and the marginal ones stop looking attractive — which is the answer you wanted from the analysis anyway.
The practice behind it.
Building the case?
We will price the run as well as the build, so year two is not where the argument happens.