How to decide which process to automate first

Pick the process that costs the most hours per year and is stable enough to still exist in six months. That is the short answer, and most of the work is in checking the second half, because the process with the highest hour count is often the one about to be replaced by something else.

Here is the method I use in an assessment, in the order I use it.

1. Count the hours, do not estimate them

Ask how long the task takes and you get a remembered number, which is almost always wrong in the same direction: people report the time the task takes when it goes well. Ask someone to note the start and end for two weeks and the number usually grows.

Multiply by frequency and use conservative working weeks. At 48 weeks, a task that takes five hours a week is about 240 hours a year. That is the figure worth arguing about, not the five.

The ROI calculator on this site does this arithmetic with the assumptions listed on the page, so you can check them rather than trust them.

2. Price the errors separately

Hours are only half the cost. The other half is what happens when the process goes wrong: the invoice that went out with the wrong figure, the lead that sat unrouted for a week, the report that was quietly incomplete for a month before anyone noticed.

Silent failures are the expensive category. A process that breaks loudly gets fixed. A process that produces a plausible but slightly wrong number keeps being trusted, and the cost compounds. If a process can fail silently, weight it up.

3. Rule out the unstable ones

This is the filter most lists skip. Before ranking anything, ask what is changing.

• Is the process about to be replaced by a system migration already scheduled?
• Does it depend on a supplier, format or regulation that is in flux?
• Was it redesigned in the last six months?

Automating a process that changes shape twice a year means paying to build it twice. It is better to leave it manual and revisit.

4. Check somebody can explain it end to end

If nobody can walk you through the whole process, you have found something other than an automation candidate. Usually it is two processes that were merged, or a set of undocumented manual corrections that are actually the requirements.

That is worth knowing before a build rather than during one. The corrections nobody wrote down are where automation projects go wrong, because the automated version does what the documentation said and everyone notices in week three.

5. Rank, then deliberately cut the top item

Once each candidate has hours, error cost and a stability judgement, ranking is easy. Then do one more pass and ask whether the top item is the right first project, which is a different question from whether it is the biggest.

The first automation in an organization has a second job: it decides whether people trust the next one. A slightly smaller process that is well understood, easy to run in parallel, and owned by someone enthusiastic is often the better opening move than the biggest number on the list.

What this looks like in practice

A weekly lead report at a legal services firm took five hours and served more than twelve executives. It scored high on hours, high on error cost because the whole follow-up chain depended on it, and high on stability because the report had looked the same for years. It was a clear first candidate, and it came down to under two minutes.

The stability check is what made it obvious. Plenty of processes at that firm consumed more hours in total. They were also the ones mid-redesign.

The uncomfortable finding

Sometimes the ranking says do nothing. A shortlist where every candidate is under fifty hours a year, or where the top three are all being replaced next quarter, is a real result. It is cheaper to reach that conclusion in an assessment than in month two of a build.

If you want to run this yourself, start with the hours and be honest about the second step. Most of the value is in the ruling out. If you would rather have someone else do it, that is what an AI strategy assessment is.