Choose processes that are repetitive, high in volume, rule-based, digital from start to finish and stable over time. Score each candidate on hours consumed, error cost, rule clarity and input quality, then start with the highest-scoring one that has a willing owner. Avoid processes that depend on judgement, change often or are about to be replaced.
- Good RPA candidates are frequent, rule-based, digital and stable.
- Score candidates on hours, error cost, rule clarity and input quality before choosing.
- A willing process owner matters as much as technical suitability.
- Fix or simplify a broken process before automating it.
What makes a process a good RPA candidate?
The strongest candidates share five traits: they repeat often, follow explicit rules, use digital inputs, touch more than one system and rarely change. A task like downloading a daily statement, matching it against the ledger and updating a tracker ticks every box. Two people given the same instructions would produce the same result.
Weak candidates fail one or more of those tests. A task that depends on reading tone in an email, or on a manager who decides case by case, is not a rule-based task. It might suit AI assistance or a simple checklist, but a plain bot will struggle.
- Repeats daily, weekly or monthly with similar volume
- Follows rules you can write on one page
- Uses digital data rather than paper or phone calls
- Spans several applications where people re-type data
- Is unlikely to be redesigned in the next year
How do you score and rank candidates?
List every candidate process and give each a score from one to five on four questions: how many hours does it consume, how costly are mistakes, how clear are the rules, and how clean is the input data? Add the scores and sort. You are not after precision; you want a defensible order that the team agrees with.
For example, if a weekly report takes six hours and a monthly reconciliation takes twenty, the reconciliation has a head start on hours. But if its rules are fuzzy, the report may still win. These are made-up numbers meant only to show the weighing.
Why does process stability matter so much?
A bot encodes today's steps. If the process, the form or the portal changes every month, the bot needs constant rework and the saving evaporates into maintenance. Ask whether a system upgrade, policy change or reorganisation is planned before you commit.
Stability also covers inputs. A report that arrives in the same format every time is easy; one that arrives in twelve layouts needs a document reading step first. Neither is impossible, but the second costs more and should be priced into the decision.
Should you fix a process before automating it?
Often, yes. Many processes carry approval steps nobody needs, duplicate checks or manual workarounds for problems fixed years ago. Automating that clutter locks it in. Walk through the process with the people who run it and ask which steps exist only out of habit.
Sometimes a small change removes the need for automation altogether, such as asking a supplier to send data in a template or turning a spreadsheet into a shared form. Treat that as a win, not a failure; the goal is a better process, not a bot for its own sake.
How do people and politics affect the choice?
A technically perfect process with a sceptical owner is a risky first project. Pick one where the owner feels the pain and will help document exceptions and test results. Their support in the first weeks decides whether the bot is adopted or quietly bypassed.
Also consider visibility. A modest win that colleagues can see, such as a report that appears on time every morning, builds goodwill for the next project. Early credibility is worth more than the size of the first saving.
What does a simple selection workshop look like?
Gather the owners of five to ten candidate processes for a short session. Have each describe the steps, volume, systems involved and typical exceptions, while someone records them in a common template. Score together, discuss disagreements and agree on one or two pilots.
If you would rather not run this alone, A Plus Solution offers an automation audit that does this assessment in a structured way and produces a ranked list of what to automate first.
- Invite five to ten process owners
- Describe steps, volume, systems and exceptions in one template
- Score together and discuss disagreements
- Agree one or two pilots with named owners
Step by step
- List candidates. Write down every repetitive task the team performs, with the person who owns it.
- Gather facts. Record frequency, hours per month, systems used and common exceptions for each task.
- Score them. Rate hours, error cost, rule clarity and input quality from one to five, then total the scores.
- Check stability. Remove anything likely to change soon or to be replaced by a new system.
- Confirm the owner. Select the top candidate whose owner will help document and test it.
Frequently asked questions
How many processes should we automate first?
One or two. A small first project teaches you how your systems behave, how exceptions look and how to monitor bots, which makes later projects smoother.
Can a process with exceptions still be automated?
Yes, if the common path is clear and exceptions go to a person. If exceptions are the majority, the process probably needs redesign first.
Is paper-based work suitable for RPA?
Not directly. Paper must first be digitised and read, usually with document processing, before a bot can use the data.
Who should decide the final choice?
A small group including the process owner, someone from IT and a sponsor who controls priorities. Shared agreement prevents later disputes.
What if no process scores highly?
That is useful information. It may mean your processes need simplifying first, or that other tools such as integrations or dashboards suit you better.
Need help with this? See our RPA & Process Automation service or talk to Yash Parikh.