Three Types of Nodes That Should Be Automated with RPA, and Four Types That Absolutely Should Not —— Selection Table Based on Rule Density and Exception Rate

A shared service center of a fast-moving consumer goods company implemented 34 RPA robots in its first year, but stopped 19 of them in the second year. The reason for stopping them was not due to technical issues, but because the initial node selection focused solely on "how annoying the task is" rather than "how structured the task is." The 15 robots that remained in operation handled 87% of the total automated workload per month—put differently, 19 out of the 34 robots never reached full capacity but consumed nearly half of the annual maintenance budget.

The conclusion is straightforward: Whether RPA can be used is not a technical issue, but a matter of node attributes. Whether a node should be handed over to a robot can be determined by two numbers: whether the rules can be fully written (rule density) and the proportion of exceptions (exception rate). Only nodes with fully writable rules and a low exception rate should be considered for automation; the rest, no matter how annoying, should not be automated. Below are the three types that should be automated and the four types that absolutely should not.

One, Understanding the Cost Structure of RPA

RPA is not about connecting pipes between systems (that's called interface integration); it's about having a software robot perform tasks such as clicking on the interface, copying data, and filling out forms. Therefore, the major cost is not in development but in maintenance: a change in the interface, a CAPTCHA prompt, or a system upgrade can cause the robot to fail.

A common industry ratio is: The annual maintenance cost of a robot is approximately 30% to 50% of the initial development cost. If the system is updated more than twice a year, the maintenance cost will double. This ratio determines the first principle of selection—not "whether the task can be automated," but "whether it is worth maintaining a robot long-term."

The criterion is simple: Annual labor hours saved per node ÷ Annual maintenance labor hours ≥ 3 is the minimum acceptable ratio; anything below 2 is not worth automating. Many projects only calculate the left side during the proposal stage, leaving the right side blank.

Two, Three Types of Nodes That Should Be Automated

Type A: High-frequency, data transfer nodes that take 1～10 minutes per transaction.

The criteria are three numbers: average daily execution ≥ 30 times, single transaction manual time ≥ 2 minutes, and a fixed sequence of actions (same system, same fields, same order).

Threshold: At least 40 hours saved per month, equivalent to half a person's output.

A common counterexample is found in the most overlooked areas—report aggregation that runs only three times a day. Development takes 8 person-days, and maintenance requires 2 person-days per month, but the saved labor hours do not cover the maintenance costs. Such tasks should be handled using the system's built-in scheduled tasks or a simple script, rather than using RPA, which is a heavy-duty tool with an interface.

Type B: Judgment nodes with rules that can be exhaustively listed and no more than 8 branches.

"Judgment nodes" does not mean they cannot be automated; the key is whether the branches can be fully written. More than 8 branches usually indicate that human experience is mixed into the rules rather than the complexity of the business itself.

The threshold is a simple but effective test: write the judgment rules into a table and have a new employee who has never done this job follow the table to correctly process 20 transactions within 30 minutes. If they cannot, it means the rules are not yet defined, and standardization should be done first (see Process Standardization Before System Implementation) rather than leaving it to the developers to guess.

Type C: Nodes in systems that will not be modified in the short term and have no interfaces.

This is the native scenario for RPA: old ERP, old OA, supplier portals, government reporting websites. The criteria are that there are no plans to replace the system within the next 12 months, and the interface has not changed more than once in the past 12 months.

Expected Range: After automation, the processing time per transaction for these nodes is typically reduced to 15%30% of the manual time; however, the success rate will stabilize at 95%98%, with 2%~5% of transactions still requiring manual intervention, which is normal and not a defect.

Three, Four Types of Nodes That Should Never Be Automated

First Type: Attribution and Responsibility Determination Requiring Professional Judgment.

Why there are discrepancies in reconciliation, who is responsible for this batch of nonconforming products, and whether this customer should be given a credit period—these actions do not output "task completed," but rather "what is the conclusion." Robots can fetch data and present evidence, but they cannot make conclusions. Handing over the conclusion to a script with fixed rules will eventually lead to "if the system says it's right, it's right," and no one will be able to explain the basis when issues arise.

Second Type: Nodes with an Exception Rate Exceeding 20%.

Rules covering 80% of cases sound good, but the 20% that the robot cannot handle will all be returned to manual processing, which is often slower than doing it manually from the start—manual processing must first understand where the robot left off and what half-finished work remains.

Criterion: Sample 100 historical cases, and if more than 20 are exceptions, abandon the node. First, reduce the exceptions, then consider automation; the methods for reducing exceptions are the same as those for reducing steps, as detailed in Why Do Approval Flows Keep Getting Longer?.

Third Type: Systems Scheduled for Replacement or Processes Still Under Revision.

Placing a robot on a bridge that is about to be dismantled is the most common and regrettable waste. The signal is very clear: if the system is mentioned in the IT annual plan with terms like "upgrade," "replacement," or "migration," do not proceed. Wait for the new system to be implemented, and it is likely that a single interface will solve the problem, making the robot unnecessary.

Fourth Type: Final Confirmation and Signing Actions.

Final confirmation in payment approval, submission of compliance reports, and issuance of external commitments. The value of these actions lies not in efficiency but in responsibility attribution. Robot execution equals a responsibility vacuum—when issues arise, no one can say, "I confirmed it." The correct boundary is: automation can go as far as "preparing materials, filling out forms, and calculating amounts," but it must not automate the "click to submit" action.

Four, Calculating a Justifiable ROI

The most common mistake in RPA project proposals is to directly multiply the saved labor hours into money. The correct calculation must subtract three items: maintenance labor hours, exception handling labor hours, and idling due to decreased business volume.

For a medium-sized shared service center: a node with an average of 50 executions per day and 3 minutes per transaction consumes about 55 hours of manual labor per month. After implementation, manual labor drops to 8 hours (only for handling exceptions), saving a net 47 hours per month. Development takes 8 person-days, and annual maintenance requires 3 person-days, which translates to a payback period of 7～9 months, a healthy range.

A success rate of 100% is not always better. To write the last 1% of exceptions into the rules, maintenance costs will rise exponentially, and a single system update could cause a complete breakdown. Stabilizing at 96%~98% and leaving a manual intervention channel is more cost-effective than striving for zero exceptions.

Five, Three Issues Only Visible After Implementation

Robot Queuing. Nodes concentrated at the end of the month, where a dozen robots compete for the same machine's login session, result in the overall process being slower than manual. Before implementation, review the workload distribution: peak nodes should either be staggered or have concurrent licenses, don't wait until the end of the month to discover the issue.

Shadow Robots. Business departments use low-code tools to build their own systems, bypassing IT, and when problems arise, no one takes responsibility. This is usually not a governance issue but a signal that needs are not being met—incorporating them into a unified management list is more effective than issuing a ban.

Using RPA as Integration. Two systems synchronizing tens of thousands of data entries daily still rely on simulated clicks. Any high-volume, real-time data synchronization should use interfaces; RPA is only suitable for "low-frequency, small volume, interface as the only entry point" scenarios. Blurring this boundary makes larger projects harder to manage, and the root cause is similar to why Excel is still used despite three different planning systems—explained in more detail in Why Do We Still Rely on Excel Despite Three Different Planning Systems?.

In a Nutshell

The RPA selection question is not "which task is the most annoying," but "which task has fully writable rules, few exceptions, and a stable system." High-frequency data transfer, rules exhaustively listable, and old systems with no interfaces are safe to automate; judgment and attribution, exception rates exceeding 20%, systems to be replaced, and final confirmation and signing actions should never be automated. After implementation, verify using the three lines of payback period 9 months, success rate 98%, and intervention rate 5%. If it doesn't pass, stop it; don't drag it into a sunk cost with "a bit more optimization."

This article belongs to the "Digitalization and AI Zone · Process Digitalization" direction, aimed at operations and process managers, and does not involve quality management system clauses.

Knowledge code: 16.1.4 Version: v20261030 Author: QTank