When to automate a process — and when to delete it

Automation has an obvious appeal: the same work, done faster, without a person. But there is a cost that rarely gets counted at the point of decision. Once a process is automated it becomes infrastructure. It gets documented, monitored, depended upon and maintained. You have not just made it faster — you have made it permanent.

That is fine when the process genuinely needs to exist. It is expensive when it does not, and a surprising amount of what businesses ask me to automate falls into the second category.

The question to ask first

Before asking how to automate something, I ask what would break if it simply stopped. Not "what would we lose" — what would break. A specific consequence, named by a specific person.

If nobody can answer, that is a finding on its own. Plenty of recurring work exists because it once mattered and nobody has revisited it. Automating it converts a habit into a permanent system, and it will still be running in five years, consuming maintenance and attention, long after anyone remembers why.

When automation is clearly right

Automate when three things are true. The process is genuinely necessary — something identifiable breaks without it. The process is stable — the rules have not changed materially in a year, because automating a moving target means rebuilding it repeatedly. And the volume justifies it — the work happens often enough that the build cost is recovered in a reasonable period.

Where all three hold, automation is usually the highest-return work available. The nightly reconciliation that runs itself is worth far more than its build cost, every year, forever.

When deletion is right

Delete when the process exists to satisfy a control that no longer has a live risk behind it, or produces an output nobody acts on, or duplicates something another system already does correctly. Deletion is faster than automation, costs nothing to maintain and never breaks. It is the most underused option in operational improvement, largely because it is uncomfortable to propose.

The middle case: simplify first

Most processes sit between the two. They should exist, but not in their current form. They have accumulated steps — a second approval, an extra reconciliation, a status field somebody wanted once — and automating them wholesale bakes all that accumulation into code.

Strip the process back to what it needs to do, then automate what is left. The build is smaller, cheaper and easier to maintain, and you avoid the common outcome where a company pays to make a bad process fast.

Why this matters for the numbers

An automation business case usually compares the build cost against the hours saved, and stops there. It should also carry the ongoing cost of maintaining a system that now must keep working. Once you include that, the ranking of candidate projects changes — and a few of them turn into deletion decisions instead, which is a better outcome for everyone except the person selling the build.