Automation debt

What is automation debt?

Automation debt is the maintenance and risk burden that builds up when automations are made quickly, left undocumented, or never properly looked after. It shows up as brittle flows, manual workarounds, and changes that take longer every time you touch them.

It borrows the idea of technical debt and applies it to bots and flows. Fragile selectors, hardcoded settings, personal login details, missing tests, and undocumented dependencies all add to the balance.

It is not a formal accounting figure or a standard metric. The term earns its place by making overdue work visible so a team can prioritise it.

Deliberate and accidental debt

A team might knowingly build a temporary screen-based flow to bridge a system migration. That is a reasonable choice when the risk, the owner, and the end date are all written down.

Accidental debt is the quiet kind. A proof of concept slips into production, the person who built it leaves, or a dependency changes and nobody follows up.

Not every simple solution is debt. Debt exists when the shortcut creates future cost or risk that has not been dealt with yet.

Common sources

Screen scraping and UI automation build debt through fixed coordinates, broad selectors, and a dependency on one screen resolution. One layout change and the bot reads the wrong field. This is the classic failure mode of RPA built on the user interface rather than a supported integration.

Flows that run on a personal account, store secrets in plain configuration, or share a single super-user login carry both a security and a continuity risk. When that person leaves, the automation stops.

Duplicated logic spreads the same rule across several bots. A single policy change then means editing it by hand in many places, and missing one is easy.

Outdated runtimes, connectors, and API versions add the last layer. The automation still runs, until a vendor deprecates the version it depends on.

An example

An invoice bot logs in with the personal ERP account of the person who first built it and reads fields by screen position. There are no tests and no source files.

After an ERP update, the VAT code silently comes out wrong on some runs. Finance corrects it afterwards, while operations only ever sees green run statuses.

The debt here is more than one broken selector. It is credential risk, fragile extraction, no outcome check, and all the knowledge sitting with one person. Fixing the selector alone leaves the rest in place.

Automation debt versus technical debt

Technical debt is the broader software idea: future cost created by technical shortcuts. Automation debt applies that to process automation and adds the process, identity, and operational dependencies that bots bring with them.

A flow can be technically tidy and still carry automation debt when the underlying process is unclear or nobody owns the exceptions. The reverse holds too: a small, well-monitored bot that is planned for replacement can carry acceptable short-term debt.

Inventory and scoring

Record, per automation, the owner, how critical it is, its age, the technology, its dependencies, the identities it uses, its tests, its incidents, and the date of its last review.

Score the impact and likelihood of failure, along with how often it changes and how quickly it recovers. Use a simple scale that leads to concrete priorities. Do not just count code smells: an old but stable API integration can be less urgent than a new bot that pays invoices with no duplicate check.

Paying it down

Start by removing automations nobody uses and revoking their access. Replace personal identities with managed service accounts, and move secrets into managed storage.

Consolidate duplicated rules, add contract and regression tests, and swap fragile UI steps for a supported API wherever one exists. Reserve capacity each quarter for this work, because reacting only to incidents keeps the balance where it is.

Prevention is not about perfecting everything up front. It is about making shortcuts explicit and organising how they get repaid, which is where automation governance and a clear automation lifecycle do the heavy lifting.