Common RPA Pitfalls
Learning from other organisations' RPA failures is faster and cheaper than discovering them yourself. Most RPA pitfalls are predictable and preventable. This topic maps the most common failure patterns so you can identify and avoid them before they cost your programme time, money, and credibility.
Pitfall 1: Automating a Broken Process
A broken, inconsistent process does not become a good process just because a bot does it. The bot inherits every flaw, workaround, and inefficiency of the manual process and executes them at high speed.
EXAMPLE:
Manual process: AP clerk copies invoice data incorrectly 15% of the time,
then manually corrects errors after SAP rejects them.
After RPA: Bot copies data incorrectly 15% of the time at 6× the speed.
Now you have 6× more errors to fix manually.
FIX: Standardise and clean the process BEFORE automating.
Use process discovery to find and fix the root causes first.
Pitfall 2: Poor Process Selection
Choosing the wrong processes to automate — ones with high exception rates, frequent UI changes, or poor documentation — leads to fragile bots that need constant maintenance.
- Sign: Exception rate above 20%, or process changes every month
- Prevention: Use the RPA suitability checklist (Topic RPA11) to score every candidate before committing to development
Pitfall 3: No PDD or Incomplete Documentation
Building a bot without a complete, signed-off PDD is like building a house without blueprints. Developers guess at missing steps and build the wrong thing. UAT then reveals gaps that require expensive rework.
- Sign: Developer constantly goes back to the business with questions during development
- Prevention: Make a signed PDD a hard gate before development starts — no PDD, no development
Pitfall 4: Fragile Selectors
Position-based or overly specific selectors break every time the application updates. Teams that do not invest time in building stable selectors spend more time maintaining broken bots than the automation saves.
- Sign: Bot breaks every few weeks after application updates
- Prevention: Use ID-based selectors, apply wildcards, review all selectors in code review before deployment
Pitfall 5: Insufficient Error Handling
A bot with no error handling stops at the first unexpected situation and leaves data in an inconsistent state. Business users discover the failure hours later when they notice nothing has been processed.
- Sign: Bot fails silently; no alerts sent; nobody knows until the next morning
- Prevention: Make error handling a first-class requirement, not an afterthought; require Try-Catch and alerting in the SDD
Pitfall 6: Hardcoded Values
Hardcoded email addresses, file paths, thresholds, and URLs mean every business rule change requires a developer, a code change, testing, and a redeployment — multiplying the cost of routine configuration updates.
- Sign: "We need to update the bot because the approval threshold changed"
- Prevention: Store all configurable values in Orchestrator Assets from day one; enforce in code review
Pitfall 7: No Monitoring or Alerting
A bot running without monitoring is invisible. Failures go undetected. Queue backlogs grow unnoticed. The business assumes the bot is working until a missed deadline reveals otherwise.
- Sign: "We didn't know the bot had been failing for two days"
- Prevention: Set up Orchestrator alerts from day one; define SLA response times; assign an operations owner for every production bot
Pitfall 8: Skipping UAT
Skipping UAT — or rushing through it to meet a go-live date — sends bots to production that the business has not validated. The resulting failures in production are more expensive to fix and damage stakeholder confidence far more than a delayed go-live would have.
- Sign: "We'll catch issues in production" or "The business will raise tickets if anything is wrong"
- Prevention: Make UAT sign-off a non-negotiable gate; schedule it early in the project timeline, not as the last thing before go-live
Pitfall 9: No CoE or Governance
Without governance, every team builds bots in their own way. There is no shared library. No standards. No visibility across the programme. The same process gets automated three times by three different teams. Security controls are inconsistent. ROI is impossible to measure.
- Sign: Multiple teams asking the CoE for the same bot independently
- Prevention: Establish a CoE and intake process before scaling beyond the first five bots
Pitfall 10: Ignoring Change Management
Deploying a bot without preparing the people it affects creates resistance, misinformation, and sometimes active sabotage. Employees who feel threatened by automation become obstacles to adoption.
- Sign: Business team refuses to use bot outputs, or constantly reports "errors" that are actually correct bot behaviour
- Prevention: Involve frontline employees in discovery and UAT; communicate honestly about job impact; celebrate automation wins with the teams involved
The Pitfall Risk Matrix
| Pitfall | Likelihood | Impact | Prevention Cost |
|---|---|---|---|
| Automating broken process | High | High | Low (process review) |
| Fragile selectors | High | Medium | Low (code review) |
| No error handling | High | High | Low (build it in) |
| Hardcoded values | High | Medium | Low (use Assets) |
| No monitoring | Medium | High | Low (configure alerts) |
| Incomplete PDD | Medium | High | Medium (BA time) |
| Skipping UAT | Medium | High | Medium (schedule early) |
| No governance | Medium | Very High | Medium (CoE setup) |
| Change management gap | Medium | High | Medium (comms plan) |
| Poor process selection | Low | High | Low (use suitability checklist) |
Summary
The most common RPA pitfalls fall into three categories: process pitfalls (wrong process, broken process, poor documentation), technical pitfalls (fragile selectors, no error handling, hardcoded values, no monitoring), and organisational pitfalls (no governance, skipped UAT, neglected change management). Every single one on this list is preventable with low-cost, high-discipline practices applied consistently from the start of the programme. Recognising these patterns early — especially in your first projects — protects the credibility of the entire automation programme and the people responsible for it.