Robotic process automation (RPA) is an easily accessible and low-cost-for-entry solution to automate lower-level tasks. Used smartly, RPA technology can bring about significant cost reductions by eliminating the need for expensive, manual labor on highly repetitive, high-volume activities. Implementing a successful RPA solution lies in creating a generous backlog of eligible processes. Not all activities, however, are ideal for RPA technology. The key to selecting the right automation candidates requires heavy emphasis on a thorough assessment of each step.

Because RPA technology isn’t suited for all processes, candidates must be evaluated against attributes that showcase RPA’s key strengths. A quick and simple way to create a valid process pipeline is to utilize a scoring mechanism that objectively rates how well each process candidate fits the attribute. A list of various criteria that define good RPA process candidates is shown below. Processes that aren’t good candidates can still benefit from other forms of improvements as a result of the evaluation.

Attribute: Rule Based

Tasks that have clear instructions for how they are processed and that use clearly identified and predictive business rules are great candidates for automation. Those that do not conform to this attribute likely require more human judgment and greater use of exception scenarios, making them not ideal for RPA technology. For processes that are mixed or heavily judgment-based, consider applying other improvement methods first (LEAN, Six Sigma) before applying RPA.


  • Judgment Based = 1
  • Both Rule and Judgment = 3
  • Rule Based = 5

Attribute: Structured, Readable Input

Processes that pull standardized and structured electronic data sets are easier to automate than those that don’t. Bots have a much easier time reading from Excel spreadsheets, Word documents, emails, presentations, and PDF files than from scanned documents or even manually inputted documents. Not only are electronic inputs preferred, but they also should be standard in nature. Processes that are triggered by inputs that vary are not ideal candidates.


  • Unstructured Input = 1
  • Mixed Input = 3
  • Structured Input = 5

Attribute: Standardized, Low Exception Rates

Standardized processes with clear business rules (and little to no human judgment) have low or no exception rates compared with those that are less standard and defined.

Processes that experience high exception rates should be analyzed to determine why frequent exceptions are occurring and how they may be more streamlined to reduce them before applying RPA technology.


  • Not Standard/High Exceptions = 1
  • Partly Standard = 3
  • Standardized/Low Exceptions = 5

Attribute: High Volumes

Processes that have a high frequency of occurrence, as well as high-transaction volumes, are ideal candidates for RPA as the technology will greatly reduce (or, in most cases, eliminate) human error involved with manually processing the sheer volume. Reducing error also reduces risk.

Medium- to low-volume processes may also be good candidates for RPA, but may yield fewer returns than those with higher volumes.


  • Low Volume = 1
  • Medium Volume = 3
  • High Volume = 5

A less subjective scoring mechanism for volume is ROI. Larger-volume processes likely will have higher ROIs than those with lower frequencies/ volumes. Those with higher ROIs should have higher priority.

Attribute: High Error Rates

High-volume, manual processes are prone to high error rates, usually resulting in rework that could be reduced or eliminated with RPA technology.


  • Low Error Rates = 1
  • Medium Error Rates = 3
  • High Error Rates = 5

Attribute: Manual-Rekey Frequency

Processes that require the rekeying of data across multiple systems are ideal candidates for RPA technology.


  • No Rekey = 1
  • Some Rekey = 3
  • Frequent Rekey = 5

Attribute: Unchanging Processing Methods

Processes whose methods will change in the short term (or frequently) are not good candidates for RPA technology. Instead, look for processes that remain stable and consistent in their methodology, architecture, and inputs.


  • Changing Process = 1
  • Stable Process = 5

Attribute: Low Process Adherence

While processes may be standard on paper, resources may not always adhere to them as closely as intended. Processes that are not followed, especially those involving internal or external controls, make great RPA candidates.


  • Total Adherence = 1
  • Mixed Adherence = 3
  • Low Adherence = 5

Attribute: System Changes

Due to the cost involved, if automating a process would result in significant system changes, it may not be as a good a candidate as one that requires fewer system changes or integrations.


  • Significant System Changes = 1
  • Low/No System Changes = 5

A cost/benefit assessment may be a less subjective measurement for this metric.

Attribute: Customer Satisfaction

Processes that more greatly affect customer satisfaction are better candidates than those that have little or no impact.


  • No CSAT Impact = 1
  • Some CSAT Impact = 3
  • Significant CSAT Impact = 5

Once processes have been assessed, they can be ranked by total score, with those scoring the highest put at the top of the list for automation, resulting in a backlog of process candidates for the RPA-development team. While the above is an extensive list of attributes to consider, each organization may add its own based on the nature of its business and strategic imperatives. Once a process has been selected, a business case should be built that more accurately reflects the potential benefits of its automation.

It’s important to note that automating a process generally requires it to be optimized for automation. This means that a business analyst needs to re-engineer the process to take advantage of the technology’s capabilities, as doing so may uncover other potential RPA pitfalls that must first be addressed before the process can be fully automated. For example, when re-engineering a process for one of our clients, MorganFranklin discovered that some data was captured differently depending on users’ preferences. Before the process could be fully automated, it was therefore necessary to first standardize the data input so that the bot could access it consistently every time. That’s why it is good to always have a backlog of processes in waiting so that the RPA team doesn’t lose momentum.

Using the suggested criteria as evaluation tools to determine RPA suitability can enable any organization to feel secure in knowing that the processes it has chosen are very suitable for automation using RPA technology. Utilizing a business-case approach will then allow suitable processes to be ranked in order of their return on investment. When creating a business case, be sure to consider all the applicable costs incurred by the current state process against all costs and benefits of an automated process. With such data, a simple ROI calculation can easily determine a prioritized ranking of process candidates. A solid backlog also will allow the RPA team to work on automating other processes while those needing additional improvements prior to automation are stabilized.

By Markus LaFleur

Talk to one of our experts today.