Most automation projects that fail were doomed at selection, not at build. Somebody picked the task that was most annoying rather than the task that was most suitable, spent six weeks on it, and ended up maintaining a fragile system that saves twenty minutes a week.
Picking well is a skill, and it is mostly a matter of asking five questions before writing anything.
The five questions
- Does it happen on a trigger you can name? “Every Monday” and “when an invoice is paid” are triggers. “When things get busy” is not. If you cannot name the trigger, you are not ready to automate — you are still designing the process.
- Are the inputs already digital and in a consistent place? A task fed by a PDF that arrives by email in a different layout each month is a data problem first. Automating on top of it just moves the mess.
- Are the decisions inside it rule-shaped? If a human is applying judgement you cannot write down as rules, automation will produce confidently wrong output at speed.
- Is it the same every time? Not roughly the same. The exceptions are where the cost lives — a task that is standard 70% of the time and bespoke the rest is usually a worse candidate than it looks.
- What does being wrong cost? This one decides how much rigour the build needs, and it is the question people skip. Automating a low-stakes task badly is survivable. Automating a payment run badly is not.
A task that answers well on all five is a good candidate almost regardless of how much time it takes. A task that fails two or more is a bad candidate no matter how irritating it is.
The one people get backwards
Time saved is the worst selection criterion, and it is the one everyone starts with. Hours are visible, so they get counted. But the strongest automation cases we see are often tasks that take very little time and go wrong occasionally with real consequences — a notice that has to go out inside a window, a reconciliation that quietly drifts.
You are not always buying hours back. Sometimes you are buying down variance, and that does not show up in a time audit at all.
Where it depends on your situation
The five questions tell you whether a task is suitable. They do not tell you whether it is worth it — that depends on your volume, what the build costs at your complexity, and what it costs to run and maintain afterwards, which is the line most people forget entirely.
Sometimes the honest answer is that a suitable task is still not worth automating this year, and a better use of the same effort is deleting a step or changing who does it. We would rather tell you that than build something.
How we would walk you through it
Bring us three candidate tasks — not one, because the comparison is the useful part. We run each through the five questions with the person who actually does it, then estimate the build and the ongoing maintenance for the ones that pass.
Frequently the task the owner nominated first is the third-best of the three. That is a good outcome for a first conversation: it is a lot cheaper to find out before the build than after.
The build side lives in workflow automation; when the answer involves judgement that cannot be reduced to rules, it moves next door to AI consulting, which is a different question with a different cost profile.
Send us your three candidates with a sentence each on what triggers them. We will tell you which one to do first, and if the answer is none of them, we will tell you that too.
A question worth answering
Take the task that annoys you most. Can you state its trigger in five words? If not, the problem is not that it has not been automated yet.
