Every automation program has a launch slide. It shows hours saved, a payback period measured in months, and a growing count of bots or workflows in production. What it almost never shows is the line for what it costs to keep all of them running — because at launch, that number is close to zero.
It doesn't stay there. Systems the automations depend on get upgraded. Business rules change. Credentials expire. The people who built the first wave move to other projects or leave. A program that went live with twenty automations and a proud dashboard can find itself, two years later, with eighty — a third of them fragile, a handful quietly broken, and nobody able to say with confidence which is which.
This isn't a failure of the technology. It's a failure of the operating model: automations were treated as projects that end, when they are really products that have to be run.
How automation estates decay
The decay follows a familiar pattern, and it's worth recognizing early.
Ownership dissolves. During the build, the automation has a clear owner — the delivery team. After launch it sits in an awkward gap: the business team that benefits from it doesn't consider it theirs to maintain, and the technical team that built it has moved on to the next backlog item. When something breaks, the first hour of the incident is spent working out who should be fixing it.
Upstream change goes unannounced. The team upgrading the finance system or redesigning a supplier portal has no idea that four automations depend on the exact layout of a particular screen. They didn't know to tell anyone, because there's no inventory that would have told them.
Failures become silent. A well-built automation fails loudly. A typical one fails quietly — skipping records it can't parse, completing with partial data, or simply not running when a schedule is missed. The team downstream notices weeks later, when a reconciliation doesn't balance, and by then the cleanup is a project of its own.
And the workarounds return. When an automation becomes unreliable, people stop trusting it and start checking its output by hand. The hours saved on the launch slide are quietly spent again, except now the organization is paying for both the automation and the manual work it was meant to replace.
An automation without an owner isn't an asset. It's a liability with a delayed start date.
Budget for the run, not just the build
The first fix is financial honesty. A reasonable planning assumption is that maintaining an automation costs 15–25% of its original build effort every year — more for UI-driven bots against frequently changing applications, less for API-based integrations against stable systems. Put that number in the business case from day one.
This changes decisions in useful ways. A workflow that saves two hours a week but runs against a screen that changes quarterly may not clear the bar once its maintenance cost is counted. A slightly more expensive build that uses a stable API instead of screen scraping often turns out to be the cheaper option over three years. Neither of those trade-offs is visible if the business case stops at go-live.
Give every automation a named owner
Each automation in production needs two owners, written down where everyone can find them.
- A business owner who is accountable for the outcome: that the process still needs automating, that the rules encoded in it are current, and that its output is correct. When a policy changes, this is the person who knows the automation needs to change too.
- A technical owner — a person or a team with a rota — who is accountable for keeping it running: monitoring, fixing breakages, applying upgrades, and rotating credentials before they expire rather than after.
If nobody will accept the business ownership, that is useful information. It usually means the automation isn't valuable enough to keep, and the right decision is to retire it rather than leave it running unsupervised.
The operating basics that prevent most incidents
None of this requires a large platform team. Most of the incidents we see would have been prevented by five unglamorous practices.
- A living inventory. Every automation, what it does, who owns it, which systems and credentials it touches, how often it runs, and what volume it handles. A spreadsheet is fine to begin with. What matters is that it's current and that it's the first place anyone looks.
- Dependency notice for upstream changes. Add a step to the change process for every system that automations touch: before a release, check the inventory and notify the technical owners of anything affected. This one step eliminates a large share of breakages.
- Monitoring that checks outcomes, not just runs. "The job completed" is not enough. Track records processed against records expected, and alert when the ratio drifts. A bot that runs successfully and processes nothing is the most expensive kind of failure, because it looks like success.
- Exceptions with a destination. Every case an automation can't handle should land in a named queue with someone responsible for working it, not in a log file nobody reads.
- A scheduled review. Once or twice a year, walk the inventory with the business owners: is each automation still needed, still correct, and still worth what it costs to run? Retire the ones that aren't. A smaller estate that works beats a large one nobody trusts.
A short worked example
A logistics company had built 64 automations over three years, mostly UI-driven bots across finance and customer operations. Leadership's view was that the program was mature. The finance team's view was that they no longer trusted any of it, and were re-checking most outputs by hand.
A four-week review built the first complete inventory. Eleven automations had no identifiable business owner. Nine were running against processes that had since changed, producing output that was technically complete and substantively wrong. Six had stopped running entirely months earlier, and nobody had noticed because their failure alerts went to the mailbox of a contractor whose engagement had ended.
The company retired 17 automations outright, rebuilt 8 against APIs instead of screens, and assigned named owners and outcome monitoring to the rest. The estate shrank by more than a quarter. Maintenance incidents fell by roughly 60% over the following two quarters, and — the number that mattered most — finance stopped re-checking the outputs, which recovered more hours than the retired automations had ever saved.
The honest takeaway
The launch of an automation is the start of its cost, not the end of it. Programs that last fund the run alongside the build, give every automation a person who answers for it, and are willing to switch things off.
Count your automations by how many you'd trust, not by how many you've built.