Automation maintenance cost is the number that decides whether an automation programme compounds or quietly collapses, and it is almost never the number that appears in the business case. Build costs are visible, quoted and argued over. The cost of keeping those automations alive for the next five years is spread across a dozen budget lines, several teams and nobody’s name.
That gap is why so many organisations reach year three with forty automations, no clear owner, an unexplained rise in platform spend and a nagging sense that the savings stopped arriving. Nothing failed dramatically. The estate simply accumulated small, permanent obligations faster than anyone tracked them, and the business process automation programme that looked self-funding on paper turned out to have a standing run rate.
This guide puts a real figure on that run rate. It covers what maintenance actually includes, why estimates come in low, how governance costs behave differently from engineering costs, what changes by platform type, a working model you can apply to your own estate, and a 90-day plan to bring an unmanaged estate back under control. Four comparison tables and three charts give you the benchmarks to argue with.
Table of contents
- What Automation Maintenance Cost Actually Covers
- Why Business Cases Systematically Understate Automation Maintenance Cost
- The Five Layers of Automation Maintenance Cost
- Where Governance Sits Inside Automation Maintenance Cost
- Automation Maintenance Cost by Platform Type
- How Fragile Automations Multiply Automation Maintenance Cost
- A Working Model to Estimate Automation Maintenance Cost
- What Pushes Automation Maintenance Cost Up and Down
- Staffing the Run Function Without Inflating Automation Maintenance Cost
- Automation Maintenance Cost Across a Five-Year Horizon
- Warning Signs Your Automation Maintenance Cost Is Out of Control
- A 90-Day Plan to Bring Automation Maintenance Cost Under Control
- Frequently Asked Questions
- References and Further Reading
What Automation Maintenance Cost Actually Covers
Most teams define maintenance as “fixing things when they break”. That definition is roughly a third of the truth, and the missing two thirds are what wreck the budget. A useful automation maintenance cost figure has to include everything the estate consumes after go-live, not only the visible repairs.
Run cost and support cost are different things
Run cost is what the automation consumes simply by existing: licences, seats, compute, storage, API calls, monitoring. It arrives whether or not anything goes wrong. Support cost is what people spend reacting to it: triage, reruns, fixes, escalations, the message in the operations channel that says “the invoice bot has stopped again”.
Automation maintenance cost is the sum of both, plus a third category that most organisations never itemise at all — the assurance work needed to prove the automation still does what it is supposed to do.
The five things that are always forgotten
Licence uplift as usage grows. Change work driven by upstream systems you do not control. Exception handling by the very people the automation was meant to free up. Documentation and evidence for audit. And the cost of eventually retiring the thing. Leave any one of them out and your automation maintenance cost is understated by a fifth before you start.
Where the money actually goes
The distribution below is the pattern we see most often in a mature estate of ten to forty automations. Engineering is the largest single slice, but it is rarely the slice that surprises people — governance and exception handling are.
| Cost component | What triggers it | Typical annual share |
|---|---|---|
| Platform licences and seats | Renewals, user growth, tier changes, bot runtimes | 20-30% |
| Consumption and hosting | Run volume, API calls, compute, storage, egress | 10-20% |
| Engineering fixes and changes | Upstream changes, defects, new business rules | 25-35% |
| Exception handling and rework | Failed runs a person has to finish by hand | 10-20% |
| Governance and assurance | Reviews, access checks, audit evidence, sign-off | 10-15% |
The share that matters most is the one you cannot see. If your finance system shows only the licence line, you are looking at a quarter of your true automation maintenance cost and treating it as the whole.
Why Business Cases Systematically Understate Automation Maintenance Cost
This is not carelessness. Four structural forces push the estimate down, and they operate on almost every programme.
The pilot is not representative
Pilots are chosen because they are stable, well understood and owned by an enthusiast. The second wave is not. By automation number twelve you are working on processes with more exceptions, worse data and less willing owners, and the automation maintenance cost per process rises accordingly.
Nobody owns year two
The build team is funded by a project. The project closes. The run obligation transfers to a team that was not in the room when the estimate was made and has no budget line for it. Work still happens, but it happens invisibly, absorbed into existing roles, which is exactly how an organisation ends up unable to say what its automation actually costs.
The savings are booked, the run cost is not
Benefits are tracked because someone promised them. Run costs are not tracked because nobody promised them. The asymmetry is administrative, not analytical, and it makes every subsequent business case slightly more optimistic than the last.
The “20% of build cost” rule breaks under load
The old software heuristic — budget annual maintenance at around 20% of the original build — is a reasonable starting point and a poor finishing point. It holds for stable, well-engineered integrations. It badly understates automation maintenance cost for anything driven by screen interaction, third-party portals, or a model whose behaviour changes when the vendor updates it.
Treat 20% as the floor for a well-built integration and 40-50% as the realistic figure for fragile RPA against systems you do not control.
The Five Layers of Automation Maintenance Cost
Breaking the total into layers is what makes it manageable, because each layer has a different owner, a different cadence and a different lever for reducing it.
Layer 1: platform and licensing
Seats, bot runtimes, premium connectors, environment tiers. Predictable, contractual, and the easiest to over-buy. This layer grows quietly as teams add users who touch a flow twice a year, and it is usually the only part of the automation maintenance cost anyone can quote from memory.
Layer 2: consumption and infrastructure
Runs, actions, API calls, compute minutes, storage, log retention. Variable and volume-linked, which means a successful automation makes this layer grow. Log and telemetry retention in particular is a line that rarely gets reviewed after go-live, and it is the fastest-moving part of any automation maintenance cost baseline.
Layer 3: engineering time
Defect fixes, upstream change response, dependency upgrades, refactoring, small enhancements. This is the layer people mean when they say maintenance, and it is where seniority matters — a cheap fix by someone who does not understand the process is a future incident.
Layer 4: operations and exception handling
Monitoring, alert triage, reruns, manual completion of failed cases, and the communication overhead around all of it. If a person still checks the output every morning, that hour is part of your automation maintenance cost even though no one is calling it that.
Layer 5: governance and assurance
Register maintenance, change approval, access and service-account reviews, decision-logic reviews, control evidence and audit response. Small per event, relentless in aggregate, and the layer most likely to be discovered late by an auditor rather than a budget holder.
Where Governance Sits Inside Automation Maintenance Cost
Governance gets treated as bureaucracy until the first time an automation approves something it should not have. Then it gets treated as urgent. Neither framing helps you budget, so treat it as what it is: a recurring, schedulable operating cost with a measurable size.
The four governance activities that actually recur
An automation register that reflects reality. Change control proportionate to blast radius. Access and credential hygiene for the service accounts your automations run under. And periodic review of the decision logic itself, because a rule written eighteen months ago may now be wrong rather than merely old. Four activities, four dates in the calendar, and a predictable share of the automation maintenance cost.
Change control that does not strangle delivery
The failure mode at both extremes is expensive. No change control means undocumented edits and an estate nobody can explain. Heavy change control means a two-week approval queue for a field rename, which pushes people to make the edit anyway and not record it. Tier your control by impact: low-risk cosmetic changes go through peer review, anything touching money, personal data or customer communication goes through a named approver.
Access, secrets and service accounts
Automations run as identities, and those identities usually have broader permissions than any individual. A quarterly review of what each automation can reach is one of the cheapest controls available and one of the most commonly skipped. This is where cybersecurity and automation governance genuinely overlap rather than merely sounding similar.
Evidence, audit and the regulated cases
If an automation touches personal data, a regulated decision or a financial control, someone will eventually ask you to prove how it works and who approved it. Producing that evidence retrospectively costs several times more than capturing it as you go, which is the strongest single argument for treating IT governance as a run cost rather than a project artefact.
| Governance activity | Cadence | Typical effort | Indicative annual cost |
|---|---|---|---|
| Automation register review | Quarterly | Half a day per review | £600-£1,200 |
| Change approval and release notes | Per change | 1-2 hours per change | £1,500-£4,000 |
| Access and service-account review | Quarterly | One day per review | £1,200-£2,400 |
| Failure and exception review | Monthly | 2 hours per month | £900-£1,800 |
| Decision-logic and data review | Annual | 2-4 days | £1,200-£3,000 |
| Control evidence and audit pack | Annual | 3-5 days | £1,800-£3,500 |
Add those bands together and governance lands somewhere between £7,200 and £15,900 a year for a mid-sized estate. That is a real number, it is defensible, and it is far cheaper than the incident it prevents.
Automation Maintenance Cost by Platform Type
The single biggest predictor of your run rate is not how many automations you have. It is what they are built on and what they touch.
Screen-scraping RPA
Automations that drive a user interface inherit every change to that interface. A vendor moves a button, a browser updates, a session times out differently, and the automation fails in a way that looks like a data problem. This is the most expensive category to maintain and the easiest to build, which is precisely the trap: the cheapest thing to deliver carries the highest automation maintenance cost per year.
Cloud workflow and integration platforms
API-based flows are markedly more stable because the contract is explicit and versioned. The recurring work is connector deprecation, authentication changes and the occasional breaking API version. Costs here are moderate and reasonably predictable. Our comparison of Power Automate and custom development goes deeper into where that line sits.
Low-code application platforms
Low-code shifts effort from building to governing. The platform handles upgrades, but sprawl is the cost driver: dozens of apps, unclear ownership, and a long tail nobody dares delete. Maintenance is less about code and more about curation.
Custom code and orchestration engines
Well-engineered custom automation has the lowest ongoing failure rate and the highest requirement for engineering availability. Dependency upgrades, infrastructure drift and test maintenance are the recurring items. The automation maintenance cost is lower but less elastic — you need someone who can read the code.
AI agents and model-driven steps
Anything with a model in the loop adds evaluation as a permanent cost. Model versions change, prompt behaviour drifts, edge cases appear that no rule anticipated, and output quality has to be sampled rather than asserted. This category carries the highest governance load of any, and the difference between the categories is set out in our guide to RPA, workflow automation and AI agents.
| Platform type | Annual maintenance vs build | What breaks it | Governance load |
|---|---|---|---|
| Screen-driven robotic automation | 30-50% | Interface changes, timing, credentials | High |
| Cloud workflow and integration | 15-25% | Connector and API version changes | Medium |
| Low-code application platform | 20-30% | Platform releases, sprawl, ownership gaps | Medium-high |
| Custom code and orchestration | 12-20% | Dependency upgrades, infrastructure drift | Medium |
| Agent or model-driven step | 25-45% | Model changes, prompt drift, evaluation | Very high |
How Fragile Automations Multiply Automation Maintenance Cost
Fragility is not a quality judgement. It is a measurable property with a price, and it compounds.
Brittleness has a compound rate
A fragile automation does not simply cost more to fix. It consumes attention, erodes trust, and pushes users back to the manual path “just to be safe” — which means you now pay for the automation and the manual process simultaneously. Two or three of these in an estate can absorb the entire benefit of the other twenty.
The three most expensive failure patterns
Automations that depend on a third-party portal you have no contract with. Automations that parse a document format someone else controls. Automations whose logic encodes a policy that changes annually but is hard-coded in three places. Each of these guarantees recurring work regardless of engineering quality.
Silent failures cost more than loud ones
A crash is cheap: you know immediately. A partial success that writes wrong data for six weeks is expensive, because remediation includes finding every affected record. Instrumenting for correctness, not just completion, is the highest-return investment you can make against future automation maintenance cost, and it belongs in the design rather than the incident review.
Fragility has a retirement answer
Some automations should be switched off rather than repaired. If a process is due to be replaced by a system upgrade within eighteen months, patching its automation is a sunk-cost decision dressed as diligence. Retirement is a legitimate outcome and should be on the register as a status.
A Working Model to Estimate Automation Maintenance Cost
You do not need a modelling exercise. You need four numbers per automation and a spreadsheet that anyone can audit.
Step 1: count the integration surfaces
An integration surface is any system boundary the automation crosses: an application, a file drop, a mailbox, a portal, a database. Count them. Two surfaces is routine; five is a maintenance liability. This single number predicts more of the eventual automation maintenance cost than the flow’s internal complexity does.
Step 2: score volatility
Rate each surface as low, medium or high volatility based on how often it changed in the last two years. A vendor SaaS product on a monthly release cadence is high. An internal database schema that has not moved since 2022 is low. Volatility multiplies surface count.
Step 3: apply a run-rate band
Convert surfaces and volatility into a percentage of build cost using the platform table above, adjusted up one band for every high-volatility surface beyond the first. That gives you an engineering figure. Add licences and consumption from actual invoices, not estimates.
Step 4: add the governance overlay
Apply the governance table as a flat estate-level cost rather than per automation, because most of it scales with the register rather than the individual flow. Add a 10% contingency. Anything tighter is false precision.
Worked example: a fourteen-automation estate
A mid-sized services business with fourteen live automations across three platforms, roughly 1.9 million runs a year, one regulated process and no dedicated automation team.
| Line item | Basis | Annual cost |
|---|---|---|
| Platform licences and seats | Three products, 22 seats, two runtimes | £14,400 |
| Consumption and hosting | 1.9m runs, premium connectors, log retention | £6,800 |
| Engineering time | 0.5 FTE blended at £68,000 | £34,000 |
| Exception handling | Six hours a week across the operations team | £8,900 |
| Governance and assurance | Register, access reviews, audit pack | £9,600 |
| Contingency | 10% of the above | £7,370 |
| Total automation maintenance cost | Fourteen live automations | £81,070 |
| Cost per automation | Total divided by fourteen | £5,791 |
Set that £5,791 against the annual benefit each automation was supposed to deliver. Anything returning less than roughly £12,000 a year is marginal once you price the run obligation honestly — which is exactly the arithmetic our automation ROI calculator walks through.
What Pushes Automation Maintenance Cost Up and Down
Once you have a baseline, the useful question is which levers actually move it. These are the ones that move it most, in both directions.
The five multipliers
Screen interaction instead of an API. Dependence on systems owned by third parties. Hard-coded business rules that change on a policy cycle. A single person who understands the whole estate. And no monitoring, which converts every small failure into a discovery exercise. Each of these roughly doubles the automation maintenance cost of the flows it touches.
The five reducers
An API-first rule for anything new. Configuration held outside the automation so a rule change is a data edit. Shared components for authentication, logging and error handling. A real register with named owners. And a monitoring standard that alerts on business outcomes rather than technical completion, following the same reasoning as alerting on service objectives.
The lever most people miss
Deliberate retirement. An estate that never removes anything only grows its automation maintenance cost. Setting an explicit review-or-retire date at build time costs nothing and prevents the long tail of automations that run monthly, save four minutes and consume an afternoon a quarter.
Consolidation beats optimisation
Three automations doing variations of the same job cost three times as much to maintain as one parameterised automation. Consolidation is unglamorous and it is usually the largest available saving, ahead of any platform-level cost optimisation exercise.
Staffing the Run Function Without Inflating Automation Maintenance Cost
The staffing decision drives more of the total than the platform decision does, and it is usually made by default rather than design.
The three staffing models
Embedded, where each business team maintains its own automations. Centralised, where a small platform team owns everything. Federated, where a central team owns standards, tooling and the register while business teams own their flows. Federated is the model most mid-sized organisations converge on, because it keeps context close to the process without duplicating governance — and it is usually the lowest automation maintenance cost of the three at fifteen to forty flows.
When fractional or managed support makes sense
Below roughly twenty automations, a full-time engineer is hard to justify and impossible to keep busy — but zero engineers means every change waits for a project. A fractional arrangement, whether internal or through managed IT services, covers the availability requirement without carrying a full salary against the automation maintenance cost line.
The handover that never happened
The most expensive staffing failure is not understaffing. It is a build team that leaves without transferring understanding: no runbook, no architecture note, no explanation of why a step exists. The next person’s first change takes four days instead of four hours, and it does so permanently.
Make the run team visible in the plan
Name the owner at design time, not at go-live. An automation with no named owner is an automation whose true cost lands on whoever notices the failure first, which is both unfair and unmeasurable. This is the same discipline our automation discovery workshop applies before a single flow is built.
Automation Maintenance Cost Across a Five-Year Horizon
One-year figures flatter cheap builds. Five-year figures tell the truth, and five years is the right horizon because it covers at least one major platform change.
Build cheap, pay later
A minimal build gets to production fastest and carries the highest run rate: brittle integration, no monitoring, no tests, no documentation. Year one looks excellent. By year three the accumulated automation maintenance cost has overtaken the difference in build price, and by year five it is not close. The saving was never a saving; it was a deferral with interest.
Build well, pay steadily
A properly engineered automation costs perhaps 40% more to build and roughly half as much to run. It also survives the platform upgrade that kills its cheaper sibling, which is the event that usually settles the comparison.
The retirement line nobody plans
Every automation ends. Decommissioning means unwinding permissions, archiving evidence, confirming the manual fallback still works and telling the people who relied on it. Budget a day or two per automation and it is a non-event; budget nothing and it becomes the reason a service account with wide permissions sits active for three years after the flow stopped.
Warning Signs Your Automation Maintenance Cost Is Out of Control
You rarely get a single alarming number. You get a pattern of small symptoms that are individually easy to explain away.
The eight signals worth acting on
Nobody can produce a current list of live automations. Platform spend has risen more than run volume has. The same automation appears in the operations channel most weeks. Changes to a flow require finding one specific person. Users have quietly built a manual workaround alongside the automation. No automation has been retired in the last two years. Exception handling is done by people who were meant to be freed up. And the last access review of your service accounts predates the last two joiners.
What the pattern usually means
Four or more of those signals almost always indicate an estate that grew by opportunity rather than by design, where automation maintenance cost is real but unallocated. The remedy is inventory before engineering — you cannot reduce a cost you cannot see, and the inventory is cheaper than any of the fixes it will suggest.
The measurement that settles arguments
Cost per successful business outcome, not cost per automation. An automation that runs 40,000 times a year at £5,800 is excellent value. One that runs 200 times at the same cost is not, however elegant it is, and the register should show both numbers side by side.
A 90-Day Plan to Bring Automation Maintenance Cost Under Control
This is deliberately unambitious. The goal is a defensible number and a working cadence, not a transformation programme.
Days 1-30: inventory and instrument
Build the register: every automation, its owner, its platform, the systems it touches, its run frequency, and its last change date. Pull twelve months of platform invoices. Turn on failure alerting wherever it is missing. You will find automations nobody remembered, and at least one that has been failing silently.
Days 31-60: triage and retire
Score each automation on value delivered against effort consumed. Retire the bottom of that list — expect ten to twenty per cent of an unmanaged estate to be genuinely redundant. Consolidate near-duplicates. Fix the two or three flows generating most of your exception volume, because they are also generating most of your automation maintenance cost.
Days 61-90: set the cadence and the budget
Stand up the governance rhythm from the table above: quarterly register and access reviews, monthly failure review, tiered change control. Publish an annual run-rate figure and put it in the budget as its own line. Then apply it to every new business case, so the next automation is approved against its true lifetime cost.
What good looks like at day 91
A named owner for every automation, a published run rate, a monthly failure review with falling numbers, and a retirement decision made without drama. None of that is exotic, and organisations that reach it typically find their automation maintenance cost drops 20-30% in the first year purely through retirement and consolidation.
Frequently Asked Questions
How much should we budget for automation maintenance cost in year one?
Budget 20-30% of build cost for API-based flows and 35-50% for screen-driven automation, then add the estate-level governance figure. Year one is often lower than year two because warranty periods and initial goodwill absorb some work — do not treat it as the steady state.
Is automation maintenance cost lower on low-code platforms?
Engineering effort is lower; governance effort is higher. Low-code moves cost from fixing to curating, and organisations that skip the curation end up with sprawl that is more expensive than the code would have been. The total is comparable, distributed differently.
Who should own the budget line?
Whoever owns the process benefit. If the finance team banked the saving, the finance team should see the run cost. Placing the whole figure in a central technology budget disconnects it from the benefit and guarantees it will be treated as an overhead to be cut.
Do AI agents change the maths?
Yes, in one specific way: they add continuous evaluation as a permanent cost, because output quality cannot be asserted from a passing run. Expect a higher governance share and plan for periodic review of both prompts and outcomes rather than a one-off acceptance test.
How do we charge maintenance back to business units?
Per automation is simple and unfair; per run is fair and volatile. A blended approach — a flat register fee per automation plus a variable consumption charge — is the model that survives contact with budget holders, and it makes retirement financially attractive to the owner.
What is the single cheapest improvement?
An accurate register with named owners. It costs a few days, it makes every other decision possible, and it is the item most often missing when an estate’s automation maintenance cost has drifted out of control.
References and Further Reading
OMG Business Process Model and Notation 2.0 Specification
Get Started with Power Automate
Understanding Temporal Durable Execution
HM Treasury Green Book: Appraisal and Evaluation in Central Government
GOV.UK Service Manual: Measuring Success
The Technology Code of Practice
Moving Away from Legacy Systems
Google SRE Book: Monitoring Distributed Systems
NIST SP 800-30: Guide for Conducting Risk Assessments
NIST SP 800-92: Guide to Computer Security Log Management
NIST AI Risk Management Framework
ICO: Rights Related to Automated Decision-Making Including Profiling
ICO: Data Protection Impact Assessments
NCSC Cyber Security Board Toolkit
