Automation is usually sold as an obvious good, which is how businesses end up paying to automate tasks that should have been deleted.
A repeating task has to pass three tests before automating it is worth money. They are easy to apply yourself, and they take about ten minutes per task.
Test one: frequency
Not how long the task takes. How often it repeats, and how predictably.
Ten minutes every working day is a strong candidate, because the cost accumulates quietly and forever. Two hours once a quarter usually is not, however much those two hours are resented. Annoyance and cost are different quantities, and automation is priced against cost.
Frequency also determines whether anyone will notice when the automation breaks. Something that runs daily gets attention within a day. Something that runs quarterly can fail silently for most of a year, which means it needs more monitoring than it saves.
There is a version of this test that matters more than the arithmetic: is this task on somebody's mind between the times they do it? Work that occupies attention while it is not happening costs more than the clock suggests.
Test two: stability
Has this task changed in the last few months?
If the steps are still being argued about, if a new exception appeared recently, if two people do it differently and neither is wrong, the process is a moving target. Automating it does not just risk building the wrong thing — it freezes whichever version happened to be current the week the work was done, and makes the next change a change request rather than a conversation.
Stability is also what makes automation cheap. A settled process is described once and built once. An unsettled one is described repeatedly, and you pay for each description.
The right move for an unstable task is not a cheaper tool. It is to leave it manual, let it settle, and revisit in a couple of months. Nothing is lost by waiting, and a process that stops changing is usually one someone finally made a decision about.
Test three: the cost of being wrong
This is the test that gets skipped, and it is the one that determines what automation should cost you.
The question is not whether errors are possible. It is what happens when one occurs and nobody notices.
Some tasks fail loudly. A file does not arrive, a message does not send, somebody asks where it is. The error surfaces on its own, and the automation needs very little oversight built around it.
Others fail quietly. A wrong figure copied into a system sits there. A customer is categorised incorrectly and receives the wrong follow-up for a month. A rate is applied to jobs nobody rechecks. These need approval gates, records of what happened and a way to reverse a mistake — which is real engineering, and the honest reason two automation quotes for a similar-sounding task can differ substantially.
Work out which kind you have before asking for a price, because it is the difference between a simple piece of automation and a supervised one.
The fourth question, which is not a test
Should this task exist at all?
Automating a bad process makes it fast, permanent and much harder to question. Once something runs by itself, nobody revisits whether it should — it has stopped costing anyone time, so it stops appearing in conversations about what is wasteful.
A surprising amount of recurring administrative work exists because of a decision nobody remembers making. A report that goes to someone who no longer reads it. A form that duplicates information already captured elsewhere. A weekly summary that exists because a client asked for it two years ago and never mentioned it again.
Deleting a step is cheaper than automating it, and it never breaks.
So before automating, ask what would happen if this simply stopped. If the answer is that somebody would complain within a week, it is real work. If nobody is sure, find out before you build anything around it.
Putting the tests together
A task that repeats often, has stopped changing, and fails quietly is the strongest case for automation, and it is worth building properly with oversight around it.
A task that repeats often, has stopped changing, and fails loudly is the cheapest kind of win.
A task that is still changing should be left alone for now, whatever it costs today.
And a task nobody can justify should be removed rather than improved.
Our own Automation Sprint is scoped around a single repeating workflow for exactly this reason: one task, tested properly, is a real improvement, while a list of eight is usually a sign that nobody has applied these questions yet. If you want a second opinion on which of your recurring tasks passes, we offer a twenty-minute conversation about one of them, and a genuine answer if the answer is that automation is not appropriate.
