Senthil Info

automating business processes, honestly

The Maintenance Nobody Budgets

An automation is presented as a project and behaves like a subscription. The project has a budget, a sponsor and an end date. The commitment has none of those and runs indefinitely.

That mismatch is not an oversight by any individual. It is built into how the work is bought, and it is why the third year is where automations quietly die. A product-side example of how workforce software approaches this topic is available in this guide.

The mismatch

Projects are funded in capital terms, approved once, delivered, closed. For broader background and an independent point of comparison, see Automation Anywhere.

Automations consume operating effort forever. Systems change two to four times a year, rules drift, formats move, credentials expire. Somebody handles that, and their time is real.

The project budget closes before the second change arrives. So maintenance is funded from whatever is left over in whoever inherited it, which is nothing, and it competes against that person's actual objectives.

Why nobody raises it

The vendor is quoting a build. Maintenance appears in no proposal because the vendor is not paying it and, in fairness, cannot estimate your internal share.

The sponsor is building a case. A larger denominator makes the case worse, and nobody's incentive points at inflating the number.

And the person who will pay it is not in the room. They inherit it in eighteen months, without a budget line, and discover that maintaining someone else's automation is now part of their week.

No dishonesty is required at any step. The cost is simply outside everybody's frame at the moment the decision is made.

What it actually runs at

Somewhere between a tenth and a third of build cost per year, depending on how volatile the underlying systems are.

Screen-level integration against a system that updates quarterly is at the top of that range and occasionally above it. An interface-level integration against a frozen system is at the bottom.

The point is not the number, which varies. It is that a stated placeholder is defensible and an omission is not — a business case with maintenance at a guessed 20% is more credible than one with maintenance at zero, and it will be closer to right.

The accumulation problem

The part that bites at scale.

Each automation adds a permanent maintenance load, and they accumulate. Ten automations at a few hours a month each is most of a person, and nobody hired that person because each individual project was small.

Symptoms: a queue of small broken things, an increasingly reluctant maintainer, and automations that nobody trusts because they have not been fixed promptly.

This is why the annual list matters. Ten projects approved separately become one unfunded role, and the only way to see it is to add them up.

What to do

Put a maintenance line in every business case, at a stated percentage, from year one. Even a guess.

Name who does it, before go-live, with time allocated. "The IT team" is not an answer.

Log the hours. Without them you cannot tell when maintenance exceeds the saving, which is the signal to turn something off.

And review the portfolio annually. Total maintenance hours across all automations, against total saving. If the first is approaching a full role, that role exists whether or not anyone has funded it.

The reframing

Stop calling it a project.

An automation is an operational commitment with an installation cost. Presented that way, the maintenance line is obvious, the owner is obvious, and the annual review is obvious — none of which is true when the same thing is presented as a build with a completion date.

That is a change in language and it changes what gets approved, which makes it one of the cheapest interventions available in this whole subject.

The short version