The Automation Not Worth Building
Practice · July 30, 2026 · 9 min read
Automation proposals are almost always argued the same way. Someone does a task, it takes a while, it happens often, multiply the two, and the annual figure is large enough to justify building something. The arithmetic is correct and it is answering the wrong question, because it compares the cost of doing the task with zero rather than with the cost of owning a machine that does the task.
Those are different numbers, and the gap between them is where automation projects that looked obviously worthwhile end up net negative.
What the case usually leaves out
Four costs are routinely missing from the estimate.
The residual. Automation rarely takes the task to zero. Somebody still reviews the output, handles the cases the automation declines, restarts it when it fails, and answers questions about what it did. If the manual task took twelve minutes and the supervised automated version takes three, the saving is nine minutes, not twelve — and the estimate almost always uses twelve.
Maintenance. Every integration point is a promise that something outside your control will not change. Vendors change APIs. Forms get new fields. Regulations change what has to be recorded. Someone reorganises the shared drive the script reads from. This is not a bug rate; it is a rent, payable indefinitely, and it scales with the number of systems touched rather than with usage.
Failure handling. The automated version has failure modes the manual one did not: partial completion, duplicate effects, silent stalling. Handling those costs build time upfront and attention forever, and it is the part of the work most underestimated by whoever wrote the estimate, because it is the part that only becomes visible in production.
Attention transfer. A person doing a task notices things. They see that the input looks unusual this week, that a customer’s details are inconsistent, that the count is oddly low. Automation does not notice, and does not report what it did not notice. Some of that observation had real value, and losing it is a cost even when it is hard to quantify.
The properties that predict a bad candidate
Certain tasks resist automation for structural reasons, and they are recognisable in advance.
The process is still changing. If the steps were different three months ago and will be different again, automation freezes a moving target. Worse, it makes the target harder to move, because now changing the process means changing software. Automating an unstable process is usually a way of prematurely committing to the current version of it.
The exception rate is high. Automation handles the modal case. If a third of items are unusual in ways requiring judgement, then a third of the volume still arrives at a person, and that person now has to switch context between the automated flow and the manual one — which frequently takes longer per item than doing all of them manually would have.
The inputs are inconsistent. Structured input is the precondition for reliable processing. Where the input is free text, scanned documents, or whatever a partner felt like sending this month, the automation is really two projects: one to normalise the input, and one to act on it. The first is usually much larger than the estimate assumed.
Volume is low and stakes are high. A task performed rarely offers little aggregate saving, and rare execution means the automation is under-exercised — so when it does run, it runs code that has not been validated against the current state of anything. Rare and consequential is the combination most likely to fail in the worst way.
The rules are political rather than logical. Some decisions look like a decision table and are actually a negotiation. Encoding them produces a system that is confidently wrong whenever the underlying agreement shifts, and the shifts are not announced.
Partial automation is usually the better trade
The binary framing — automate or do not — hides the option that most often wins. Automate the mechanical parts and leave the judgement where it is.
Gather and present the information rather than making the decision. Pre-fill the form rather than submitting it. Flag the items needing attention rather than acting on them. Draft the message rather than sending it. Each of these removes most of the elapsed time while keeping the human check that makes exceptions survivable, and each is dramatically cheaper to build and maintain than the full version, because the failure modes are all recoverable by the person already in the loop.
It also fails gracefully. When a partial automation breaks, the task reverts to being done manually, slowly. When a full automation breaks, work stops and nobody has done it by hand for long enough that the knowledge has gone.
Checking the case honestly
If you want the number to mean something, insist on a few things.
Measure the task rather than estimating it. Self-reported durations for repetitive work are unreliable in both directions, and the frequency is often wildly off — tasks that “happen constantly” sometimes turn out to happen a few times a week.
Estimate the residual explicitly, as minutes per run after automation, and refuse to let it be zero unless someone can explain who checks the output.
Put a maintenance figure in hours per month rather than a percentage, because percentages of a build estimate are a way of not thinking about it.
And apply the rate that reflects who actually does each part. The person doing the task and the person maintaining the automation are usually not the same person and rarely cost the same.
Even done well this is an estimate, and the honest version of the output is a break-even point with a range around it rather than a single confident month. The value of running the calculation is less in the answer than in the questions it forces — particularly the residual, which is the input people most want to leave blank.
The best reason to automate is not saving time
Some of the strongest cases are not primarily about hours. Consistency, when variation between operators causes real problems. Auditability, when you need to demonstrate what happened and when. Latency, when a task done twice a day should happen within a minute of the trigger. Availability, when the work needs to happen at three in the morning and nobody should be awake for it. Resilience, when the process currently depends on one person who knows how.
Those benefits do not show up in a time-saved calculation at all, and they justify plenty of automation that fails the arithmetic. Which is worth saying clearly: the calculation is a filter for the projects sold purely on hours saved. It is not the only argument, and it should not be used to kill work that was never about hours in the first place.