Is This Process Ready for RPA? A 10-Minute Scoring Method

Most RPA projects don't fail at the coding stage. They fail the moment someone picks the wrong process to automate.

It usually sounds reasonable at the time. "This task takes the team 30 hours a week, so let's automate it." But hours spent is only one piece of the picture. A process can eat up a lot of time and still be a poor candidate for a bot, because it's full of judgment calls, messy inputs, or systems that change every month.

The cost of getting this wrong is real. EY's Get Ready for Robots report found that as many as 30 to 50% of initial RPA projects fail, even though the technology itself works. Deloitte's 2020 intelligent automation survey named process fragmentation as the top barrier to scaling automation, with only 38% of organizations reporting mature process definitions.

IN THIS GUIDE

• The five questions that predict whether a process is ready for RPA
• A scorecard you can copy into any spreadsheet
• How to read the total, plus one warning sign that overrides it
• A worked example comparing two finance tasks

So how do you tell a good candidate from a bad one before you spend money on a build? Here's a simple scoring method you can run in about ten minutes per process, with a spreadsheet and someone who actually does the work.

The Five Questions That Predict RPA Success

Score each process from 1 (poor fit) to 5 (strong fit) on these five factors. Be honest. The point is to find problems now, not to justify a decision you've already made.

1How often does it happen?

Volume is what pays for automation. A task that runs 2,000 times a month justifies a bot much faster than one that runs 20 times. Score high for daily, high-volume work and low for tasks that come up a few times a month.

2Are the rules clear enough to write down?

RPA follows instructions. It doesn't interpret. If you can write the process as "if this, then that" without saying "it depends," you have a strong candidate. If the person doing the work says "you just kind of know," score it low.

3How often does it go off-script?

This is the factor teams underestimate most. Ask how often a case needs a second person, a phone call, or a workaround. Better yet, check the last few months of records. Every exception is extra build work and a future support ticket. CAI's guide to RPA exception handling is a useful primer on the kinds of exceptions a bot has to deal with.

4Do the systems stay the same?

Bots that work through screens can break when those screens change. If the apps involved get frequent updates, redesigns, or random slowdowns, score it lower. Stable, rarely changed systems score high.

5Do the inputs arrive in a consistent format?

Structured data like form fields, spreadsheets, or system exports is easy for a bot. Scanned documents, free-text emails, and PDFs in ten different layouts are much harder. Score high for consistent, structured inputs.

A Quick Scorecard You Can Copy

Here's what each score looks like in practice, so different reviewers rate processes the same way.

Factor	Scores 1 (poor fit)	Scores 5 (strong fit)
Frequency	A few times a month	Hundreds or thousands of times a month
Rule clarity	"It depends" on most cases	Every step can be written as a rule
Exception rate	Many cases need a person or a workaround	Almost every case follows the same path
System stability	Apps change often or are unreliable	Apps rarely change and run reliably
Input format	Scans, free text, many layouts	Structured fields or system exports

How to Read the Total

Add up the five scores for a total out of 25. These bands are a practical rule of thumb, not a fixed standard, but they turn a gut feeling into a decision you can explain.

20 to 25: Strong candidate. Move it to the top of your list and plan a pilot.

14 to 19: Possible, with work. Look at the lowest score. Fixing that one factor first, such as standardizing an input template, often moves the process into the strong range.

Below 14: Not ready. Don't automate it yet. Clean up the process first, or consider whether a different tool, such as AI document processing, fits better.

The warning sign that overrides the total: a score of 1 on exception rate or rule clarity is a red flag on its own, even if the total looks good. A high-volume process with unclear rules just produces errors faster.

A Quick Example

Say a team is choosing between two finance tasks. Both take real time. Here's how they score.

Invoice matching 19 / 25

Runs about 1,500 times a month (5), follows clear matching rules (4), has a moderate number of cases with missing PO numbers (3), runs on a stable ERP (4), and receives invoices as PDFs in a few vendor layouts (3). A good candidate, and standardizing the vendor templates could push it higher.

Vendor dispute resolution 9 / 25

Runs about 60 times a month (2), depends heavily on judgment (1), almost always involves back-and-forth emails (1), uses the same ERP (4), and starts from free-text complaints (1). Not an RPA job, at least not yet.

Both tasks take real time. Only one is ready for a bot.
That's the whole point of scoring before you build.

Picking the Process Is Only the First Step

A good score tells you what to automate. It doesn't tell you how to get it into production and keep it running. You still need a measurable goal for each bot, an executive sponsor who can settle cross-team questions, a standardized process before development begins, a pilot designed to produce real evidence, and a governance model before you scale.

NEXT STEP

We've laid out that full sequence, starting with process selection criteria like the ones above, in our RPA implementation checklist. It's written for leaders who want to get the order of decisions right before committing budget to a build.

The Bottom Line

The best RPA programs aren't the ones with the most bots. They're the ones that chose the right processes first.

Spend ten minutes scoring a process before you spend ten weeks building for it, and you'll avoid most of the failures that give automation a bad name.