How to choose the first process to automate

Why the first choice matters

The first automation sets expectations for every one that follows. If it works, you have a live example, people who trust the approach and a team that knows how to deliver. If it stalls, automation gets a reputation inside the company that takes a long time to shift. So choose the first process for its odds of success and its visibility first, and for the size of the saving second.

A good first process is dull: frequent, rule-based, owned by someone who wants it fixed, and small enough to finish.

Score each candidate on seven factors

List five to ten candidate processes. Score each from 1 to 5 on the factors below, where 5 is the most favourable for automation. Do the scoring with the people who do the work. Managers tend to describe the process as designed, and staff describe it as it runs.

Volume is how many cases pass through. Frequency is how often it runs: daily work repays automation sooner than a quarterly task. Rule stability is whether the rules can be written down and how often they change. Exception rate is the share of cases that need judgement or a workaround, and a low rate scores high. Systems touched counts the applications involved: fewer systems, with stable screens or interfaces, score high. Cost of errors asks what a mistake does, and for a first project a process where mistakes are easy to catch and correct scores high. Ownership asks whether one named person has the authority to change the process.

Volume and frequency
Rule stability
Exception rate
Systems touched
Cost of errors and ownership

Read the scores sensibly

Add the scores, then look past the total. Treat three factors as gates. If rule stability is low, the automation will need constant rework. If the exception rate is high, you will automate the easy cases and leave people the hard ones with less context. If nobody owns the process, nobody will settle the questions that come up during the build, and they always come up. A candidate that scores 1 or 2 on any of these should wait, however high its total.

Among those that pass, prefer the process with high volume and frequency and a modest cost of error. Keep the high-stakes processes for your second or third project, when testing and monitoring habits are in place.

What to measure before you start

Take a baseline before any build begins. Without it you cannot show what changed, and you cannot size the work properly. Measure over a period long enough to include a month-end or other peak.

Record how many cases arrive and when. Record how long one case takes in hands-on time, and how long it takes from start to finish including waiting. Record the error rate and what a typical error takes to fix. Count the exceptions and sort them by type, since a few types usually account for most of them. Note how many people touch the process and how much of their time it takes. Write down every system, file and inbox involved.

The baseline also tests your scores. Processes often turn out less stable and more exception-heavy than anyone believed.

Case volume and peaks
Hands-on time per case
Elapsed time from start to finish
Error rate and rework
Exceptions by type

Tidy the process before you automate it

Automation makes a process faster, and a poor process stays poor at higher speed. Before building, walk through the steps and remove those that exist only from habit: the duplicate approval, the report nobody reads, the re-keying between two spreadsheets. Standardise the inputs where you can, for instance by replacing free-text emails with a form.

Check whether the work is rule-based from end to end. If it is, plain RPA or a direct integration will do and no AI is required. If some steps involve reading documents or handwriting, those steps call for AI, and the project is larger.

Common wrong first choices

The most painful process is a tempting pick. It is usually painful because it is complex, political or full of exceptions, and those are the same reasons it is hard to automate. The executive's favourite is another. A process chosen for its sponsor instead of its scores tends to have unclear rules and no working-level owner. The rare, large task is a third: a year-end activity may consume weeks, and you get one chance a year to test the automation.

Avoid a process that is about to change. If a system replacement or reorganisation is planned, the automation may be out of date at launch. Avoid a process that spans many departments, where each handover adds an owner, a set of rules and a negotiation. And avoid choosing a process in order to try a technology. Starting from a tool and looking for a use tends to produce demonstrations.

The most painful process
The executive's favourite
The rare, large task
A process about to change
A process with many owners

What a well-suited process looks like

For one of the largest used-car dealers in the United States, we automated bidding on UiPath and C#. The work was high in volume and frequency, which is the profile this scoring favours. Bidding now runs in near real time, and almost 150 people who used to bid daily moved to quality assurance and other work. That result belongs to one engagement and is no forecast for yours. It does show why volume and frequency carry so much weight.

Plan the people side from the start. Tell the team what will change in their work and involve them in testing. They know the exceptions better than any document does.

What to do next

List five to ten candidate processes and score them with the people who do the work. Drop any that fail on rule stability, exceptions or ownership. Take a baseline for the top two. Then pick the one you can finish soonest and treat it as the model for the rest.