How to Tell If a Process Can Be Automated: 8 Criteria for Evaluating It

“We should be able to automate that one. ” That phrase comes up in every meeting, and it’s rarely wrong: technically, almost anything can be automated. The real question isn’t whether it’s possible, but whether it’s worth it—and whether the automation will hold up over time. That’s where most failures occur.

An automation project rarely fails on the day it goes live. More often than not, it gradually deteriorates: the application evolves, exceptions pile up, no one maintains the scripts anymore, and six months later, the team reverts to manual processing.

In this case, the problem does not necessarily stem from the technology: the process, scope, or governance were not adequately prepared.

Why the Choice of Process Matters More Than the Tool

The market is flooded with RPA platforms, orchestrators, and no-code solutions that look very impressive in demos. They work. But none of them can make up for a poor choice of scope.
Choosing the right process to automate means:

• ROI achieved in months, not years: gains are realized based on actual volumes
• A machine that ages well: fewer reworks, less unplanned maintenance
• Convinced teams: a successful first implementation paves the way for future ones
• Managed risk: no uncontrolled robots handling sensitive data

Conversely, a poorly chosen first project costs twice as much: it drains the budget and undermines confidence in the initiative. In many organizations, a failed automation project puts the issue on hold for two years.

The 3 Factors to Consider Before Automating

In practice, the candidate process is rarely chosen based on explicit criteria. It is chosen because it is visible, because a team is complaining about it, or because a sponsor is pushing for it. These are poor indicators: the most tedious process isn’t always the one most amenable to automation, and the one most amenable to automation isn’t always the most cost-effective.
To make a decision, you need to consider three distinct dimensions, which do not offset one another:

• Feasibility: Canthe automated system be built—and, more importantly, maintained?
• Cost-effectiveness: Do the benefits justify the investment and maintenance costs?
• Governance and risk: Is the organization ready to entrust this task to a machine?

A feasible but unprofitable process results in an expensive automated system. A profitable but unfeasible process results in a never-ending project. Here are the criteria that truly make a difference in each of these three areas.

Feasibility

1. The business rules level: Is the process deterministic?

This is the number one criterion, by far. An automatable process is one in which the same input always produces the same output. As soon as a human has to make a judgment call, interpret a specific case, or “handle it on a case-by-case basis,” automation hits a wall.

Beware of the classic pitfall: a process described as simple often hides a long list of exceptions that operators handle out of habit, without even considering them exceptions. These are the ones that will cause the development workload to skyrocket.

Helpful tip: Ask the operator to walk through the process using ten randomly selected real-world cases. Count how many times they say “unless.” If the number exceeds two or three, the scope must be narrowed before automation can proceed.

2. The stability of the target application

An automated system is a loyal but inflexible client: it reproduces exactly what it has been taught. If the underlying application changes every month, each update requires a complete redevelopement. The maintenance costs eventually outweigh the benefits.

Check the roadmap before committing:

• Is the application at the end of its life cycle, undergoing a redesign, or scheduled for migration?
• How often do screens, fields, or rules change?
• Is there a channel of communication between the vendor or the application team and you?

A stable process running on a stable application is an ideal candidate. A stable process running on an application undergoing a major overhaul will have to wait.

3. The nature of interfaces: API or screen?

Not all automation solutions are technically equal. When an application exposes APIs or services, the automation tool relies on a stable, documented contract. When it’s necessary to use the graphical user interface—such as simulating clicks, screen reading, or scraping—even minor cosmetic changes can break the bot.

The difference in reliability between the two approaches is significant, and it isn’t apparent in the initial cost estimate. It becomes evident after one year, in the maintenance budget.

The number of applications involved matters just as much. A process that passes through four systems—two of which belong to third parties—creates multiple points of failure: authentication, unavailability, and unannounced version changes. Every boundary crossed represents an additional risk.

4. The quality of environments, data, and documentation

These are the criteria we discover too late, once the project is already underway. While they never single-handedly derail an automation project, they consistently cause delays.

• Environments: Do you have a stable and available testing environment, or will the bot need to be developed directly in production?
• Datasets: Are the data structured, consistent, and representative? A PLC cannot guess what a human would instinctively correct
• Documentation: Is the process formalized, or does it exist only in the mind of the person who has been executing it for eight years?

An undocumented process is not necessarily impossible to automate. However, the formalization phase must be factored into the cost estimate, as it often takes longer than the development itself.

Profitability

5. Frequency and Volume: The Real Drivers of ROI

An automated machine has a fixed construction cost and virtually no operating cost. Its profitability is therefore directly proportional to the number of times it runs. This is a simple matter of arithmetic, and yet it is the criterion most often underestimated.

There are two interrelated aspects:

• Execution frequency: daily, weekly, monthly, or one-time?
• The volume processed per run: ten lines or ten thousand?

A daily run on 10,000 records is nothing like a quarterly run on 50. The former pays for itself in a few weeks; the latter probably never will. A rarely run process remains an excellent candidate for simplification or lightweight automation—not for full automation.

6. The Actual Cost of Manual Execution

The calculation should not be limited to “time spent × hourly rate × frequency.” Indirect costs must also be factored in:

• The time required to resume work after an interruption, when the task is broken up throughout the day
• The resulting wait times for other teams or the end customer
• Opportunity cost: what employees could be doing with that time that would be more productive
• Reliance on a single person, and the risk associated with that person’s absence

A one-hour task performed by an expert each day not only takes up one hour of work but also ties up valuable expertise that could be devoted to analysis, monitoring, or continuous improvement.

7. The Current Error Rate: The Hidden Criterion

This is the strongest—and least frequently used—argument. If the manual process regularly leads to errors—such as incorrect data entry, omissions, or inconsistencies detected later in the process—automation not only saves time but also ensures reliability.

And in many situations, the cost of an error far exceeds the cost of the time spent: rework downstream, customer complaints, accounting discrepancies, production incidents.

When a process involves a high volume and a significant error rate, the case speaks for itself.

Conversely, a manual process that has been carried out without error for years on a small volume does not have any quality issues to resolve. At most, it presents a convenience issue.

Governance & Risk

8. Data Sensitivity and Organizational Maturity

The final consideration—one that is often addressed last, even though it should be addressed right from the outset—is: Is the organization ready to let a machine perform this task?

The issue is primarily regulatory: personal, financial, or health data, or data subject to a sector-specific framework. The more sensitive the data, the higher the level of control expected from the system: traceability of operations, access management, logging, and the ability to replay or justify an operation.

Next, there is the organizational aspect. Who will be responsible for the PLC once the project is complete? Who monitors it, who shuts it down, and who troubleshoots it? A PLC without an identified owner is a PLC that will drift silently out of control. Governance does not determine whether a process can be automated or not; rather, it determines the level of requirements that must be incorporated from the design phase onward.

Examples of processes to prioritize

The best candidates are often repetitive, standardized, and controllable processes. For example:

• HR (HRIS): Ensuring that key processes remain unchanged after each vendor update (hiring, transfers, terminations); verifying data flows to payroll and the directory; and monitoring security rules (who can view which data based on their access scope).

• Finance (ERP): End-to-end testing of the procurement cycle (purchase order, receipt, invoice, payment); verification of approval workflows based on amount thresholds; and review of automatically generated journal entries.

• IT / Cross-functional: testing of application interfaces, verification of access permissions and SSO, and automatic collection of execution evidence for auditing purposes.

These examples must always be evaluated in context: volume, application stability, exceptions, data sensitivity, and maintenance costs.

In summary

Not all of these criteria carry the same weight. Application stability, the level of business rules, the nature of the interfaces, frequency, and volume are key factors: a low score on any one of them is enough to disqualify a candidate, even if everything else is in the green.

Documentation and technological complexity, on the other hand, simply extend the timeline without calling the overall decision into question. A useful evaluation grid is therefore a weighted one.

Where should I start?

Don’t automate your most complex process first, even if it’s the one causing the most pain. Start with the one that meets the most criteria: a stable, repetitive process with high volume and low regulatory risk. A quick initial success builds the credibility needed to tackle the difficult cases next.

Above all, make the decision objective. A scoring grid developed jointly by the IT department, the business unit, and senior management avoids decisions based on gut feelings and facilitates discussion: when a process is rejected, everyone can see which criteria it failed to meet.

That’s exactly what we’ve sought to provide at SQORUS. Through our experience conducting these assessments for our clients, we’ve formalized our evaluation framework into an online tool: fourteen criteria across three categories—feasibility, profitability, and governance—weighted according to their actual importance, with a score for each category and a reasoned verdict. The entire report can be exported as a PDF or CSV file to provide input for your decision-making committee.

Assess your process’s automation potential in just a few minutes: access the SQORUS assessment tool.

FAQ – Assessing a Process’s Automation Potential