The maintenance bill nobody scopes: what an automation costs after launch

Automation proposals are priced like construction and behave like software. The quote covers the build; the build is the cheap part. What determines whether an automation is an asset or a liability in month twelve is the running cost nobody put in the business case.

This is not an argument against automating. It is an argument for pricing the whole thing, because a project that looks marginal at build cost and unacceptable at total cost should be found out in the scoping meeting, not in next year's budget review.

The five costs that appear after go-live

1. Integration churn

Every system your automation touches is maintained by someone else, on their schedule. APIs get versioned, fields get renamed, an authentication method gets deprecated, a vendor changes a rate limit. None of it is your automation's fault and all of it is your automation's problem. Deloitte's automation research has consistently found integration difficulty among the leading barriers to scaling automation — 62% of respondents in its 2022 survey, and integration difficulty at build time is a reliable predictor of integration churn afterwards.

Automations built against user interfaces rather than data interfaces are the worst case: a layout change that a human would not even notice takes the workflow down silently.

2. Input drift

The documents and messages feeding a workflow are produced by people and other companies, and they change. A supplier switches invoice templates. A new region starts sending dates as DD/MM. A team begins attaching a second PDF. Extraction accuracy degrades gradually rather than failing loudly, which is why drift is the cost most often discovered by an auditor.

3. The exception queue

A well-designed workflow routes low-confidence cases to a human. That queue is a real job with a real cost, and it is the cost most often left out of the savings calculation. If a workflow handles 1,000 cases a week with a 12% exception rate, someone is resolving 120 cases a week forever. The saving is real — it is just 88% of the number in the slide, minus the cost of the queue.

4. Monitoring and alerting

Automations fail in two ways: loudly, and quietly. Loud failures are easy. Quiet failures — a step that now returns zero results, a classifier that has started sending everything to one bucket — require someone to be watching throughput, confidence distributions, and exception rates against a baseline. Without that, the first person to notice is a customer.

5. Scope creep from success

When a workflow works, the requests start: handle this other document type, cover the German entity, add an approval step. This is the good problem, and it still consumes engineering time that nobody allocated. Treat it as a roadmap with a budget, not as a series of favours.

How to price the first year properly

A defensible business case has four lines, not one.

Four ways to make the bill smaller

1. 1Automate at the data layer, not the screen layer. APIs, databases, file drops, and webhooks change on release schedules with deprecation notices. User interfaces change on a designer's whim.
2. 2Fewer integrations. Each system in the chain multiplies the surface area for churn. A workflow touching three systems is dramatically cheaper to keep alive than one touching eight.
3. 3Make the failure modes loud. Assertions on throughput and confidence distributions, alerting on deviation from baseline, and a dashboard someone actually reads. Cheap to build, and it converts silent degradation into a ticket.
4. 4Keep judgement narrow. The more of the process that is deterministic data movement, the less of it drifts. Use models where the work genuinely needs interpretation and nowhere else.

When the maintenance cost should stop the project

Run the arithmetic: if build plus a year of run, maintain, and operate exceeds the annual cost of the manual process, the answer is no — or the answer is a smaller scope that touches fewer systems. Low-volume processes, workflows pinned to a system due for replacement, and automations that can only be built against a third party's UI are the three cases where a competent shop should talk you out of it.

There is a version of this trade that is worth taking anyway: when the manual process is a compliance or cycle-time risk rather than a cost, the automation can be worth building at a loss on hours. Just make that an explicit decision rather than an accounting accident.