Should you automate it? A five-question test
A short test for deciding whether a task is worth automating — covering frequency, judgment, blast radius and the maintenance cost nobody accounts for.
Automation has a failure mode that nobody warns you about: it works. You build the thing, it runs, and you never notice that it costs more to maintain than the task ever cost to do.
These five questions catch that before you spend anything.
1. How often does it actually happen?
Not how often it feels like it happens. Count it.
A task that takes twenty minutes twice a week is eighty minutes a month, or about sixteen hours a year. That is worth automating. A task that takes an hour twice a year is not, no matter how much you dislike it. Dislike is a bad proxy for cost, and the tasks I resent are rarely the ones consuming the most time.
The trap is that the annoying-but-rare tasks are the ones you think about, so they are the ones you ask to have automated first.
2. How much judgment is involved?
If the rules can be written down, it can be automated. If the answer is “it depends, you just get a feel for it,” you are looking at a task that needs a human — possibly a human with better tools, but still a human.
The middle case is the most common and the most valuable: tasks that are ninety percent mechanical with a judgment call at the end. Those should be automated up to the judgment call and then stop. A system that prepares a decision and waits is far more useful than one that guesses at it.
3. What happens when it gets it wrong?
Ask what the worst realistic outcome is.
If a mistake means a slightly wrong number in an internal report, run it unattended. If a mistake means an incorrect message reaching a customer, or a duplicate charge, or a shipment confirmed that never shipped, you want a human approval step in the path. This is not caution for its own sake — it is the difference between an error you fix on Tuesday and an error you find out about from a review.
The useful design question is never “can this be fully automated?” It is “where does the human belong?”
4. What does it cost to maintain?
This is the question that gets skipped, and it is the one that decides whether automation was a good idea two years later.
Everything you connect to will change. APIs get versioned, export formats shift, someone restructures the spreadsheet. Every integration is a small ongoing liability.
A system built to fail loudly is cheap to maintain, because it tells you exactly what broke. A system built on assumptions is expensive, because it keeps running and produces wrong output that someone eventually has to trace backwards. That difference is worth paying for up front.
5. Is the process itself any good?
The one that stings.
If your process is broken, automating it produces the wrong result faster and more consistently. Every automation project has a moment where the honest finding is that the workflow needs fixing before anything gets built.
That is genuinely good news. Fixing a process costs nothing but attention, and it often removes the need for the automation entirely.
Putting it together
The strongest candidates look the same everywhere: frequent, rule-based, low blast radius, stable inputs, and a process that already works. Fulfillment admin. Data reconciliation. Report assembly. Inbox triage.
The weak candidates also look the same: rare, judgment-heavy, high consequence, or sitting on top of a workflow nobody has ever properly examined.
If you are unsure which one you have, the cheapest next step is to write down the steps you actually take. Most people discover the answer halfway through the list.
Want a second opinion on a specific task? Book a free call — I will walk through these five questions with your actual process, and tell you if the answer is no.