Which Process Should You Automate First?

The loudest process in the building is almost never the one worth automating first.

Every business considering automation has a shortlist, and the shortlist is nearly always wrong. It gets assembled from whatever people complain about, and complaint volume measures how unpleasant a task feels, not how much it costs. Those two things come apart badly.

The genuinely expensive process is usually short, frequent, and unremarkable. Nobody complains about it because each instance is over in two minutes. It just happens forty times a week, forever.

Score five things

Score each candidate from 1 to 5 on each factor. Multiply the first two. Add the rest.

Frequency (1–5). How often does it run? Weekly is a 2, several times a day is a 5. This is the most predictive single factor and the most consistently underweighted.

Duration (1–5). How long does one instance take? Under five minutes is a 1, over an hour is a 5.

Rule stability (1–5). Could you write down the rules and have them still be correct in six months? A process governed by legislation that changes annually scores low. One governed by a fixed internal policy scores high. This factor is what separates an automation that runs for years from one that becomes a maintenance liability.

Error cost (1–5). When it goes wrong, what does it cost? A cosmetic typo is a 1. A wrong tax figure or a mis-billed client is a 5. Note that a high error cost raises the value of automating, because deterministic processes make fewer mistakes than tired people at 4pm.

Data cleanliness (1–5). Does the input arrive in a consistent, machine-readable form? A web form is a 5. Handwritten notes photographed on a phone are a 1.

Score as (Frequency × Duration) + Stability + Error cost + Data cleanliness. The multiplication matters: it is what stops a rare-but-long task outranking a frequent-and-short one, which is the single most common ranking error.

Three disqualifiers that override the score

A high score is necessary and not sufficient. Any one of these means stop, regardless of the arithmetic.

No stable rules. If the people doing the work cannot agree on what the rules are, you do not have a process, you have a set of individual habits that resemble each other. Automating it will encode one person's habits as policy, and everyone else will work around it. The fix is not a better tool, it is deciding what the process is.

No clean data source. If the input has to be interpreted rather than read, you are not building an automation, you are building a document-understanding project with a much larger budget and a much longer timeline. That can be worth doing. It should not be your first one.

No owner. If nobody is accountable for the outcome, nobody will notice when the automation starts failing, and everything eventually fails. An unowned automation degrades silently until somebody discovers six weeks of bad output. This one disqualifies more candidate projects than the other two combined, and it is the one people argue about most.

Then apply the credibility test

The highest-scoring candidate that clears all three disqualifiers is your best project on paper. It may still not be your best first project.

The first automation in a business does two jobs. It delivers its own payback, and it settles the argument about whether this whole idea works. If it lands late, or works but nobody trusts it, the second project is much harder to get approved no matter how good the business case is.

So for the first one, bias hard towards visible and safe. Something where the improvement is obvious to people who did not build it, and where failure is recoverable in an afternoon. Speed to Lead is a common first project for exactly this reason: the before-and-after is visible to everyone in the business within a day, and the failure mode is that an enquiry gets answered by a human the way it always was.

Spend the credibility from that on the process with the bigger number and the scarier failure mode.

Watch the work, do not ask about it

One practical warning about gathering the inputs. How people describe a process and how a process actually runs are reliably different, and not because anyone is being dishonest. People describe the intended path. They forget the workarounds, because workarounds stop feeling like workarounds after a few months.

Sit with someone and watch them do the task three times. You will see the spreadsheet they keep on the side, the message they send to check something, and the case they handle differently without mentioning it. Those are not noise. They are the actual requirements, and they are why automations built from a described process fail their first week in production.

If you take one thing from this: the gap between the described process and the observed process is where your project's risk lives. Close it before you write anything, not after.

Key takeaways

Frequency beats durationA two-minute task done forty times a week outranks a two-hour task done monthly, and it is far easier to automate.
Score stability, not just costAutomating a process that changes every quarter buys you a maintenance liability.
Three things disqualify outrightNo stable rules, no clean data source, and no owner. Any one of them means stop.

Frequently asked

Should we not just automate whatever people complain about most?

Complaint volume measures irritation, which correlates with how unpleasant a task is rather than how much it costs. The most-hated job in an office is often a thirty-minute monthly task, while the genuinely expensive one is a two-minute task nobody thinks about because it is over quickly.

How long does a scoring exercise take?

For a small business with a dozen candidate processes, about a week, most of it spent watching how work actually happens rather than how people describe it. Those two are never the same and the gap is where the findings are.

What if the highest-scoring process is also the riskiest?

Then it is the wrong first project regardless of score. The first automation has a second job beyond its own payback: it has to demonstrate that this works. Pick something that will visibly succeed, then spend that credibility on the harder one.

Can we score a process we have never measured?

You can estimate, but be honest that you are estimating. Ask three people who do the task how many times a week they do it and how long it takes. If their answers differ by more than a factor of two, you do not know the process well enough to automate it yet, and that is a finding in itself.

What if a process scores well but the team resists?

Take it seriously rather than overriding it. Resistance is usually specific knowledge: the person doing the task knows about an exception nobody documented. Find out what it is before you build, because you will find out afterwards either way.