The bottom line
RPA delivers 200–400% ROI when applied to the right processes and near-zero ROI when applied to the wrong ones. The difference is not the tool - it is the process selection. High-value RPA targets are rule-based, high-volume, stable, and currently handled by humans doing data re-entry between systems. Low-value targets are exception-heavy, judgment-dependent, or masking an underlying data quality problem that automation will amplify. Getting the process selection right before you build is the entire game.
Where RPA Actually Works
RPA delivers its highest ROI in processes that share four characteristics: high volume, rules-based logic, structured data inputs, and stable process design. In manufacturing and logistics, the clearest examples are goods receipt confirmation (matching delivery notes to purchase orders in the ERP), supplier invoice matching (three-way match across purchase order, goods receipt, and invoice), and regulatory compliance documentation (generating and submitting standard reports on a defined schedule).
In logistics specifically, OTIF (On-Time In-Full) reporting - compiling carrier data, WMS data, and customer order data into a weekly performance report - is a high-volume manual task that RPA handles well. The data sources are structured, the logic is consistent, and the output is a defined format. A bot running this task reliably eliminates 8–12 hours of analyst time per week and removes the risk of manual error in a compliance-sensitive report.
The economic case is direct: bots run on well-selected, stable processes typically deliver full payback within 6–12 months. After that, the cost savings are ongoing with minimal maintenance overhead - provided the underlying process does not change significantly.
The best RPA candidates are the processes that your most experienced team members describe as "mindless but important." High volume, consistent rules, structured data, stable design.
Where RPA Fails
RPA fails consistently in processes that involve unstructured data, frequent exceptions, or workflow steps that require human judgement. A supplier invoice that does not match the purchase order perfectly is a frequent exception in most procurement processes - and it requires a human to decide whether to approve, query, or reject it. An RPA bot on that process handles the straight-through cases and floods the exception queue with everything else, often creating more work than it saves.
The second failure mode is automating a bad process. RPA on a broken process makes the broken process run faster. If the goods receipt process involves incorrect data being entered into the ERP because the master data is not maintained, the bot will process incorrect data at bot speed. The automation does not fix the underlying problem - it amplifies it.
The third failure mode is under-scoping maintenance. RPA bots break when the systems they interact with change - a new field added to a form, a different login flow, a changed report format. Without an ongoing maintenance budget and ownership, RPA programmes degrade over time as the bots fail silently and the exception queues grow.
Building an RPA Programme That Compounds
The RPA programmes that compound - where each wave of automation funds the next - start with a systematic process inventory rather than with a specific technology. The first step is identifying every manual, repetitive process across procurement, operations, logistics, and finance, estimating the volume and the effort per execution, and calculating the automation potential for each.
Prioritise the three to five processes with the highest volume, the clearest rules, and the most stable design. Build those first, prove the ROI, and use the time savings to fund the next wave. This is the land-and-expand model applied to process automation - and it is the only model that consistently delivers a self-funding RPA programme.
The ownership model matters as much as the process selection. An RPA programme owned entirely by IT will build bots that the business does not trust and will not maintain. An RPA programme owned entirely by the business will build bots that work initially and break at the first system change. The right model is joint ownership: business analysts own the process requirements and acceptance testing, IT owns the infrastructure and maintenance protocols.
RPA delivers when it's applied to processes that are genuinely repetitive, rule-based, and digitally accessible. It fails when it's applied to processes that need redesigning - you end up with a faster version of a broken process. The discipline is choosing the right targets. The ROI on the right ones is fast and measurable.