Should I automate this? Four tests it has to pass first

Should I automate this? Four tests it has to pass first

Most advice about AI at work answers "what could I automate?" That question has a useless answer, because almost anything can be automated badly. A task is worth automating when it repeats often, arrives in the same shape, fails visibly, and costs little when one run goes wrong. Four tests. A task failing any one should stay manual, and this is what to do instead in each case.

The reason this matters is that a bad automation is not neutral. It does not sit there doing nothing. It runs, produces something plausible, and moves work downstream that somebody now has to undo.

Test one: does it repeat?#

Count how many times the task happened in the last month. Not how many times it felt like it happened. If the answer is under four, building the automation costs more than doing the work.

The trap is that setup is fun and the work is boring. An afternoon wiring a workflow feels like progress in a way that forty minutes of the actual task does not. Automations built on that feeling get used twice and then quietly abandoned, still running, still costing a subscription.

Fails this test? Do it by hand and write down how you did it. A saved prompt with your steps in it is not an automation, and it captures most of the value at none of the cost. If the task starts happening weekly, those notes become the spec.

Test two: does it arrive in the same shape?#

Automation handles variance badly. Look at the last five inputs. If they arrived as five different formats from four different people, the workflow will spend its life handling exceptions.

This is the test most marketing and operations tasks fail. The weekly report is stable. The inbound request that arrives sometimes as a Slack message, sometimes as a forwarded email and sometimes as a comment in a document is not, and a workflow built across all three will break on the fourth variant nobody thought of.

Fails this test? Fix the input before touching the output. A form instead of a message. A template instead of freeform. Standardising the shape is usually the entire project, and it often removes the need for the automation altogether.

Test three: will you know when it goes wrong?#

This is the test almost nobody runs, and it is the one that produces the expensive failures.

Ask a specific question: if this workflow produced a confidently wrong result on Tuesday, when would somebody notice? If the honest answer is "when a client tells us", the task is not ready to run unattended.

A note-taker that invents an action item in an executive meeting is the clearest example. It works for weeks. The output looks like every other set of notes it produced. Nothing signals a problem, because the failure has exactly the same shape as the success. By the time it surfaces, it surfaces in front of the people you least wanted it to.

Fails this test? Add the check before you add the automation. A rule that flags anything outside an expected range. A step that asks the model to state what it was unsure about. A weekly spot check of three random outputs. Any of these is worth more than the time the workflow saves, and none requires the workflow to exist first.

Test four: what does one bad run cost, and who pays it?#

Blast radius. A wrong line in a draft you read before sending costs a minute. A wrong number in a board deck costs something else. A wrong figure in a month-end close costs a restatement and a conversation with the auditor.

The person answering this question is usually not the person who pays. That is worth checking directly, because a workflow that saves you an hour and creates twenty minutes of cleanup for somebody in another team is not a saving.

Fails this test? Keep a person in the loop at the exact point where the cost lands, not at the end. Approval on the input to the risky step beats approval on the finished output, because by the finished output the reviewer is checking work that already looks complete, and complete work gets skimmed.

The four tests, and what to do instead#

Run it against something you are currently considering.

I am considering automating a task. Put me through four tests, one at a time, and do not soften the results.
1. Repeat: how many times did this happen in the last month? Under four is a fail.
2. Shape: how many different formats did the last five inputs arrive in? Three or more is a fail.
3. Check: if this produced a confidently wrong result on a Tuesday, when would somebody notice? "When someone complains" is a fail.
4. Cost: what does one bad run cost, and who absorbs that cost? A cost landing on somebody other than me is a fail.
Ask me each question, push back if my answer is vague, and at the end tell me which tests failed and what I should do instead of automating.

Passing all four is not the same as building it#

A task passing all four is a candidate. The version to build first is still the smallest one: a single step, run on a schedule you watch, with a log you can read when something looks off. The failure mode of a good candidate is scope. The workflow that was going to triage the queue grows three branches, and by month two nobody can say what it does.

Two more things worth setting on the day it goes live, not later. A limit on how much it can do in one run, so a bad input cannot produce two hundred outputs. And a date in the calendar to check whether it still works, because the model underneath it will change and nothing will tell you when it does.

The automation that worked in March and drifted by May did not break in May. It was built in March to break in May.

The question search cannot answer#

There is a version of this decision that no amount of reading resolves. It is not "how do I automate this", it is "is this the right approach at all". That depends on your setup, your team, and what the work is actually for, which is why people end up asking the one colleague who happens to know instead of reading another guide.

Ahead pairs you with an expert operator who has built this kind of workflow before, on your own work, in your own tools. If you are holding a task and cannot tell whether it belongs on this list, that is a good first hour.