Most writing about automation assumes the answer is yes. This one doesn’t.
It is worth checking the economics before anything is built: an automation that costs more than the problem is not a small mistake. It is a system someone now has to maintain, in exchange for nothing.
Here are the four situations where we usually say don’t.
The task is rare
A task that runs twice a year does not accumulate enough cost to pay back the build, however annoying it is each time. Annoyance and cost are different things, and it is easy to confuse them: the twice-yearly task you hate is more memorable than the daily one you stopped noticing years ago.
The rough test: multiply the time the task takes by how often it runs in a year. If the answer is under a few days of work, automation is unlikely to pay back within a reasonable period, and the maintenance never stops.
The process changes every time
Automation needs something stable to hold on to. If the steps, the format or the rules change with every instance (because each customer is different, or because the rules are genuinely a judgement call), then you are not automating a process. You are trying to encode a decision that nobody has actually written down.
Sometimes the useful work here is the writing down, not the software. That is a real outcome, and it costs a conversation rather than a project.
Nobody owns the output
If the report nobody reads gets generated automatically, you have made the same report faster. This sounds obvious, and it still happens constantly. Before automating anything that produces an artefact, find the person who acts on it. If there isn’t one, the correct automation is to stop producing it.
The underlying problem is upstream
Re-typing the same order details into three systems is a symptom. The cause might be that two of those systems should be talking to each other, or that one of them should not exist. Automating the re-typing preserves the bad arrangement and adds a layer on top of it.
We would rather spend the first conversation working out which of these you have, because the upstream fix is usually smaller and lasts longer.
What to check before you commit
Four questions, in order:
- How often does this actually run? Count it for a week rather than estimating.
- What does one instance cost? In hours, in errors, or in things that arrive late.
- Is the process the same every time? If not, what decides the difference?
- Who uses the output, and what do they do with it? Name a person.
If you can answer all four and the numbers still hold up, the case for automating is usually straightforward. If you cannot answer them, that is the first piece of work, and it is not a software project.
Why we tell people this
We would rather lose a project than build something that quietly costs a client more than it saves. In a market this size, the second outcome is more expensive for us than the first.