The first workflow you automate matters far more than its size suggests, because it decides whether there is a second one. Get it right and you have a measured result, a team that has seen the thing work, and an argument for the next project. Get it wrong and you have spent a budget on something nobody missed, and every subsequent proposal starts from a deficit.

The instinct is usually to pick the most annoying task. That is not a bad signal, but annoyance tracks how unpleasant work is rather than how much of it there is, and those are different numbers. Here is a more reliable way to choose.

Score every candidate on four axes

Volume
How many times a month does this happen? A task done twice a week will not produce a saving anyone can see, however irritating it is. Frequency is what turns a small per-task saving into a number on a budget line.
Handling time
How long does one instance take, honestly, including the context-switch to start it and the checking at the end? People consistently underestimate this by leaving out both ends.
Variance
How much do two instances of this task differ from each other? Low variance is the strongest positive signal there is. High variance does not rule a task out, but it moves it later — the rules have to be established before they can be automated, and that is a separate piece of work.
Reach
How many systems does it touch, and can each of them actually be reached? A task that lives entirely in one tool is far cheaper than the same task spread across three, and a system with no usable way in can turn a small project into a large one.

Multiply volume by handling time and you have the monthly cost of the task in hours — the number the business case rests on. Read variance and reach as the effort side. The best first candidate is a high-volume, low-variance task with a short reach, even if it is not the one people complain about most.

Measure before you estimate

Every number above should be observed, not recalled. Ask a team how long something takes and you will get an average of their worst experiences of it. Watch it for a week and you get the distribution, which is what you actually need — a task that usually takes four minutes and occasionally takes an hour is a different automation problem from one that reliably takes twelve.

Four kinds of task to leave alone for now

  • Anything where the rules are genuinely contested. If two experienced people disagree about the correct handling and both are defensible, you have a policy question, not an automation candidate. Automating it just picks a side silently.
  • Anything low-volume but high-stakes. The accuracy bar is expensive to reach and the saving is small — the worst trade available.
  • Anything about to change. Automating a process two months before it is replaced is a well-known way to spend a build budget on nothing.
  • Anything whose difficulty is a symptom. If a task is painful because an upstream form collects the wrong fields, fix the form. An agent papering over a broken input is a permanent cost added to hide a one-off fix.

Saying no to these is not caution, it is what makes the yes credible. An assessment that recommends automating everything examined is not an assessment.

What good looks like

A strong first candidate usually has a recognisable shape: it happens many times a day, it follows the same steps nearly every time, it lives in one or two systems that can be reached programmatically, the failure mode is visible rather than silent, and somebody can say what it costs today.

Support triage, invoice and document processing, lead qualification and routine research and reporting all tend to fit, which is why they come up repeatedly. But the shape matters more than the category — plenty of support queues are too varied to be a good first project, and plenty of unglamorous back-office tasks are close to ideal.

Pick the boring one that happens two hundred times a week, not the interesting one that happens twice.