What should you automate first?
Six questions per task. Run your candidates through it and the highest score is where to start.
Score the task
Six questions about one specific task. Answer for how it runs today, not how it is supposed to run.
1. How often does it happen?
Count . Short frequent tasks beat long rare ones every time.
2. Could you write the rules down completely?
If a competent new starter could follow the written rules without asking, it is rule based.
3. How stable is the process?
Automation built on a moving target needs rebuilding.
4. If it failed silently, what would happen?
Silent failure is the expensive kind. Loud failure is fine.
5. How many people touch it?
More hands means more handoffs, which is usually where the time goes.
6. Is it written down anywhere?
Undocumented is not a blocker. It is the first task.
Verdict
Answer the six questions
The score weighs frequency and how rule-based the task is against how stable it is and what a silent failure would cost.
What each answer says
Do this next
A second opinion
Want that checked by someone who has built these?
We reply within one business day.
What this usually leads to
Saved in this browser, nowhere else. See all your answers together · All twenty-five tools
Annoyance is a poor guide to what pays back. Six questions on one task return a verdict: automate it, document it first, or leave it alone. The tasks worth automating are high volume, rule shaped, stable, and already understood by the people who run them.
What you get
Frequency
Short and frequent beats long and rare.
Rules over judgment
If it cannot be fully described in rules, a rule engine will get it confidently wrong.
Stability
Anything built on a process that keeps changing gets rebuilt within months.
Cost of silent failure
Loud failure is fine.
Picking the first one when you have several
Most teams arrive with four or five tasks that all feel worth automating. Score each one separately and the list sorts itself, because the six questions are the same six questions every time and the numbers are comparable. The highest score is the first build.
Score every candidate before you build any of them
Running one task through the scorecard tells you whether it is worth doing. Running five tells you which order to do them in, which is the more useful answer. It takes about a minute each and the whole exercise is shorter than the meeting you would otherwise have about it.
The loudest task is usually not the first one
The task people complain about is normally the one that is complicated, judgment heavy and changes often, which is the shape that scores badly. The first automation that pays is normally quiet: high volume, rule shaped, stable, and boring enough that nobody mentions it.
A low score is an answer too
A task that scores badly is telling you the process is not settled yet. Fix it by hand, write down what you did, and score it again in a month. Automating an unsettled process is how you end up maintaining two of them.
Bank the first one before starting the second
Finish one, measure the hours it gave back, and put those hours somewhere visible. That number is what pays for the next build, and it is also the thing that decides whether the next build gets approved.
Why the choice of task decides the outcome
When an automation project disappoints, the post mortem usually blames the tool. It is almost never the tool. The task was chosen because somebody complained about it loudly, or because it looked impressive in a demonstration, and neither of those correlates with what pays back.
If the answer is yes, Zapier or a custom integration covers how to build it. If the answer is not yet, hire an assistant or automate the task covers the other route. If the task has judgment in it, an agent is the shape that fits rather than a fixed automation.
Questions we get
What if I get a verdict I disagree with?
Look at which factor pulled it down, because that is the real information. A "not worth automating" on a task you know is painful usually means the pain is coming from somewhere the tool does not measure, like waiting time or a handoff.
Why is judgment such a hard blocker?
Because a rule engine will produce an answer either way, and a confidently wrong answer is worse than no answer. The failure is silent and it scales at exactly the speed you automated it to.
Does AI change the judgment answer?
Some of it. A model handles variation in input far better than a rule can, which moves a few tasks from impossible into possible. It does not move tasks where the judgment is the point.
We have twenty tasks. How do we pick?
Score them all, then take the highest scorer with the lowest silent failure risk. Not the biggest cost, because the biggest cost is often the least suitable.
For the money as well as the fit, the automation ROI calculator scores the same six factors and prices what they return.
More in the guides and every answer in one place.
Read next
The number behind the decision, and what to do with the answer.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built