Deciding whether to automate it at all
The question is not whether a task could be automated. Almost anything could. The question is whether the automation will still be right in six months.
Automating a repetitive job feels obviously correct, which is why so many automations exist that cost more than they save. The decision deserves two minutes of arithmetic before an afternoon of building.
The sum most people do wrong
The usual calculation is time saved times frequency, against the time to build. That sum almost always says yes, and it is missing the largest term: maintenance.
An automation is not finished when it works. It has to be understood by whoever inherits it, updated when the thing it touches changes, and debugged the day it stops silently. Add a realistic maintenance estimate — for anything touching an external service, assume you will look at it two or three times a year — and a surprising number of candidates stop qualifying.
Stability matters more than frequency
A task you do daily but that changes shape every month is a poor candidate. A task you do monthly that has been identical for two years is a good one, even though the time saved looks smaller.
The reason is that changing an automation costs far more than changing a habit. When a manual process needs adjusting, someone adjusts it that morning. When an automated one does, someone has to find it, understand it, edit it, and test it — and in the meantime it is quietly producing slightly wrong output.
Do it by hand three times first
The first version of any process is wrong in ways you cannot see yet. Automating it early freezes those mistakes into something harder to change than the mistakes were.
Three manual runs is usually enough to find the edge cases: the client whose name breaks the format, the month where the file arrives late, the step that turns out to need a human decision. Then automate what remains, which is smaller and better understood than what you would have automated on day one.
Automations fail quietly, so build the noise in
A person who forgets a step usually notices. An automation that stops running produces nothing at all, and nothing looks exactly like everything being fine — sometimes for weeks, until someone asks where a report went.
Whatever you automate, arrange for it to tell you when it did not run, not only when it did. A weekly "this ran, here is the count" is enough, and the count matters more than the confirmation: an automation that runs and processes zero rows is the most common failure and the hardest to spot.
Questions people actually ask
How do I know if something is worth automating?
Include maintenance in the sum, not just time saved times frequency. Anything touching an external service will need attention two or three times a year, and that term is what most calculations leave out.
Should I automate my most frequent task?
Only if it is also stable. A daily task that changes shape monthly is a poor candidate; a monthly task unchanged for two years is a good one, because changing an automation costs far more than changing a habit.
How do I stop an automation failing silently?
Make it report when it did not run, not only when it did — and include a count. An automation that runs and processes zero rows is the most common failure and the hardest to notice.
