Almost every automation project I see that goes badly went badly at the choosing, not at the building. The workflow was fine. It was built well. It just should not have existed.
The test: boring, frequent, already decided
Three conditions, and it has to be all three.
Boring — the task has one correct output for a given input, and you would do it the same way on a Monday morning and a Friday night. Copying an invoice number into a spreadsheet is boring. Deciding whether a client’s complaint needs a refund or a phone call is not.
Frequent — you do it often enough that the time adds up faster than the maintenance does. An automation is not free after you build it: it breaks when an API changes, it needs a rerun when something times out, and it needs someone to notice when it silently stops. A task you do twice a year does not repay that.
Already decided — this is the one people skip. If you cannot write down the rule you are following, you do not have a rule, you have a judgement. Automating it means picking one branch of that judgement and freezing it, permanently, without telling anyone you did.
Miss any one of the three and you are usually better off leaving the work alone.
The judgement hiding in the manual step
The most expensive failures I have seen all share a shape: a step looked mechanical from the outside, so it got automated, and something quietly stopped happening.
Someone was scanning the list before they sent it. They were not checking anything in particular — they would have told you the step was mindless — but roughly once a month they caught a name that should not have been there, and they fixed it without mentioning it, because it did not feel like work.
That step was not data entry. It was review, wearing data entry’s clothes. The automation replaced the part that was visible and deleted the part that was not.
Before you remove a manual step, ask the person doing it what they do when something looks wrong. If they have an answer, the step is not mechanical.
Write it out by hand first
Before building anything, write the process as prose. Every input, every branch, every “and then I check that…”. Not a diagram — sentences, because sentences make you finish your thoughts and boxes let you leave them vague.
Two useful things happen.
Most of the time the document ends up short and obvious, and building it is straightforward because you already made every real decision on paper.
Sometimes it does not. You get three paragraphs in and find you cannot write the rule down, because there is no rule — there is a person applying taste. That is not a failed exercise. That is the project telling you, before you have spent anything, that this work is not ready to be automated. Stopping there is a win, and it is the cheapest one available.
The uncomfortable version
The best automation candidates are rarely the tasks that annoy you most. Annoying work is usually annoying because it is ambiguous, and ambiguity is exactly what does not automate.
The best candidates are the tasks so dull nobody complains about them. They are boring because they are decided. That is the same reason they work.
Written by Marvin
I build AI systems for SEO and automation, and share every one of them in the AI SEO Society.
Join the community