The real cost of an automation

When an automation gets evaluated, the conversation almost always revolves around a single figure: what it costs to build. That's the most visible part of the cost and, frequently, the smallest. The decision this article deals with is how to approve — or reject — an automation by looking at what it will cost over its lifetime, not just the initial quote. You won't find numbers here, because every case has its own; you'll find the structure of the cost, which is what lets you ask the right questions before signing.

The quote measures construction; the cost arrives later

An automation is not a one-off expense, it's a commitment: from the day it goes live, it's part of your operation, and everything that's part of the operation has to be sustained. The quote you approve measures the weeks of building it; the real cost is spread over the years of keeping it running. That asymmetry isn't a vendor defect or fine print — it's the nature of any component that gets woven into a living business. The problem isn't that it exists; it's deciding as if it didn't.

What follows are the four cost lines that almost never appear in the proposal.

The dependencies it creates

Every automation connects pieces: email to a spreadsheet, the ERP to the bank, a web form to the CRM. Each connection is a quiet bet: it assumes the piece next door will keep behaving the same way. And the pieces don't sit still. The ERP vendor updates their system, someone renames a column in the shared spreadsheet, a file arriving from outside changes format, a credential expires. None of those changes is the automation's fault, and any of them can break it.

The practical effect is subtle and expensive: from now on, every change in the neighbouring systems carries an added cost that didn't exist before — checking that the automation still works, and adapting it if it doesn't. An automation turns other people's changes into your work. The more pieces it touches, and the more of them belong to third parties, the more fronts stay open. That's why two automations that do "the same thing" can have radically different lifetime costs: one touches two stable in-house systems; the other, five third-party systems that change whenever they please.

The knowledge: who understands it in-house

Whoever built it — vendor or employee — carries the map in their head: what it does, in what order, why it was designed that way, which shortcuts were taken. If that map never gets transferred to anyone else, the day something breaks you'll be in a worse position than with the manual process you replaced: a process nobody can run by hand and nobody can fix. It's the operational version of key-person dependency, with one aggravating factor: at least somebody understood the manual process.

This cost gets paid either way; the only choice is when and at what price. You can pay it cheaply up front — minimal documentation, a handover session, one internal person who understands the what even if they don't master the how — or expensively later, in the form of emergencies, total vendor dependency, or rebuilding the whole thing because that was cheaper than deciphering it. When evaluating a proposal, "what gets documented, and who on my team will understand it?" is worth more than most technical questions.

The operation: the work doesn't disappear, it changes shape

"It runs itself" is a description of the happy path. Around the happy path there are exceptions: the order in a strange format, the customer that doesn't exist in the system yet, the alert somebody has to look at. Automating doesn't eliminate human work; it transforms it — from executing the task to watching the process and resolving what doesn't fit. That transformed work is smaller than the original if the process was stable and the rules clear; it can be larger if what got automated was riddled with exceptions. Worth asking beforehand: how many cases will fall outside the rule, and who will handle them?

The exit: what happens if you have to switch it off

This is the line nobody budgets. What gets automated gets forgotten: after a while, nobody quite remembers how it was done by hand, the person who used to do it has moved on, and the operational knowledge has evaporated. If one day the automation has to be switched off — the vendor disappears, a system it depends on gets replaced, the process changes top to bottom — going back to manual isn't going back: it's rebuilding. You don't need a formal contingency plan; you need to have asked the question and for the answer not to be "no idea": if it weren't there tomorrow, what would we do that week?

How to use this structure to decide

None of this is an argument against automating. It's an argument against budgeting only the construction. A good automation survives the full accounting without breaking a sweat: stable process, few and well-chosen dependencies, knowledge kept in-house, exceptions contained. A bad one only looks profitable while four questions go unasked:

1. Which systems does it touch, who owns them, and what happens when they change?
2. Who in-house will understand it, and what gets documented?
3. How many exceptions will it generate, and who will handle them?
4. If we had to switch it off tomorrow, what would we do?

If the promised savings only add up while these four answers are ignored, they don't add up. And there is a way to make this whole cost structure work for you instead of against you: automate processes that are already understood and in order, because almost everything above gets more expensive when what you automate is disorder.