The cost of owning an automation after it is built

Automation is usually priced as a build. Somebody scopes the work, quotes it, delivers it, and the conversation about cost ends there. But a system that runs is a system that has to be kept running, and that has a cost which does not appear in the quote and does not stop.

Naming that cost in advance is not a caveat. It is the difference between a system that is still working in two years and one that quietly stopped six months in, because nobody had been made responsible for the fact that it needed anything.

What running cost actually consists of

It is not one thing, and the components have very different shapes. Four of them account for almost all of it.

Upstream change. Every system an automation touches is maintained by somebody else on a schedule nobody consulted. APIs get versioned, fields get renamed, a vendor changes an export format, a portal is redesigned. None of this is anyone's fault and none of it can be prevented. It can only be accommodated, and the accommodation is work. This is the single largest component and it scales with the number of integration points, not with volume.

Credential and access maintenance. Tokens expire, keys rotate, permissions get tightened during a security review, an account belonging to a departed employee is disabled and takes an integration with it. These are small individually, unpredictable in timing, and each one stops the system until somebody attends to it.

Exception handling. The cases the automation does not cover still have to be processed by someone. This is a genuine ongoing cost of the system and it is routinely left out of savings calculations, which is how a project reports a saving that the people doing the work do not recognise.

Alert triage. A properly instrumented system tells somebody when it fails. That is the point of instrumenting it, and it means somebody has to read and act on those alerts. An alert nobody is responsible for is not monitoring, it is noise, and a system whose alerts are ignored is functionally unmonitored while appearing otherwise.

Estimating it before anything is built

A workable estimate needs three inputs, all available at scoping time.

• How many external systems it touches, and how stable each one is. A mature, versioned, documented API is a different proposition from a vendor portal with no API at all and a habit of redesigning without notice.
• What the expected exception rate is, and therefore how many cases a month still need a person. This should be an explicit number in the scope, not something discovered in month two.
• What the failure consequence is. A system whose failure is noticed immediately needs less monitoring than one whose output is not checked until a month-end close, where a silent failure means weeks of accumulated wrong data.

Those three produce a defensible estimate of hours per month. It should be stated as a range, it should be part of the scoping conversation rather than a surprise, and it should be subtracted from the projected saving before the saving is described as a saving. A net figure that accounts for it is worth more than a gross figure that will be corrected by reality later.

Three ways to reduce it

Fewer integration points. If two of five systems contribute a small share of the value, connecting three and handling the rest manually may cost less to own for years. The architecture that minimises running cost is often not the one that automates the most.

Fail loudly and specifically. The dominant cost in maintenance is not repair, it is diagnosis. A system that reports which step failed, on which record, with what response, turns an afternoon of investigation into a ten minute fix. This is a build-time decision with a permanent effect on running cost, which is why instrumentation belongs in the original scope rather than being added after the first incident.

Write down how it works. Not API documentation, which describes the code, but an operational note: what it does, what it depends on, what its alerts mean, and what to check first when it stops. This is what makes the difference between a system somebody can maintain and one that only its author can touch.

Why this belongs in the first conversation

The reason to raise running cost before a build rather than after is that it changes decisions while decisions can still be changed. It can move a project from five integrations to three. It can make the case for instrumentation that would otherwise be cut for time. Occasionally it shows that the ongoing cost approaches the saving, which means the honest conclusion is not to build, and that conclusion is much cheaper to reach in a scoping conversation than in month eight.

It also sets an expectation that survives contact with the first upstream change. A client who was told at the outset that connected systems change, and that accommodating them is part of owning the automation, treats the first breakage as anticipated maintenance. A client who was told the system was finished treats it as a defect. The work is identical. The difference is entirely in what was said before it happened.