RPA Feasibility Assessment

A feasibility assessment determines whether a specific process can be automated with RPA, and whether doing so makes business sense. It examines the process from technical, operational, financial, and strategic angles. The output is a clear recommendation: automate, redesign first, or do not automate.

The Four Dimensions of Feasibility

Diagram: Feasibility Assessment Model

              TECHNICAL
              FEASIBILITY
                  ▲
                  │
                  │
 FINANCIAL ◀──────┼──────▶ OPERATIONAL
 FEASIBILITY      │        FEASIBILITY
                  │
                  ▼
              STRATEGIC
              FEASIBILITY

 All four must be positive for a process to be approved for RPA.

Dimension 1: Technical Feasibility

Technical feasibility asks: "Can the RPA tool actually do this?"

Key Technical Questions

• Are the applications the bot must use accessible via the UI (desktop or web)?
• Do the applications use standard controls that the RPA tool can identify with selectors?
• Is the input data in a digital, structured format?
• If virtual environments (Citrix, VDI) are involved, does the tool support image-based automation?
• Are there APIs available that could make the automation more reliable?
• Does the process require reading physical paper or handwritten text? (This needs OCR or AI — a different capability.)

Technical Feasibility Scoring

 Factor                          Score (1-5)
 ─────────────────────────────────────────────
 UI accessibility                    4
 Selector reliability                3
 Data structure                      5
 Environment (Citrix/standard)       3
 API availability                    4
 OCR requirement                     2
 ─────────────────────────────────────────────
 Average Technical Score             3.5/5
 THRESHOLD: Score must be ≥ 3 to proceed

Dimension 2: Operational Feasibility

Operational feasibility asks: "Will this automation work reliably in real-world conditions?"

Key Operational Questions

• Is the process stable — does it follow the same steps every time?
• What is the exception rate? (Too many exceptions = high maintenance.)
• Are the applications used in the process updated frequently? (Frequent UI changes break bots.)
• Does the process depend on human judgment for any steps?
• Can the process be run unattended, or does it require human involvement?
• What is the impact if the bot fails mid-process? Can it recover and resume?

Exception Rate Impact

 Exception Rate    Automation Approach
 ────────────────────────────────────────────────────────────
 0 – 5%           Fully automate. Handle rare exceptions by
                  routing to human queue.
 6 – 20%          Automate standard path. Build robust exception
                  handling. Monitor closely.
 21 – 40%         Consider partial automation. Automate what's
                  rule-based. Human handles the rest.
 > 40%            RPA not suitable. Process needs redesign first
                  or a cognitive automation approach.

Dimension 3: Financial Feasibility

Financial feasibility asks: "Is the cost of automation justified by the return?"

Cost Components

• Development Cost: Developer time to build and test the bot (typically 4–20 weeks depending on complexity)
• Licence Cost: Annual RPA platform licence fee per bot or user
• Infrastructure Cost: Virtual machine or server to run the bot
• Maintenance Cost: Ongoing updates when systems change (typically 15–20% of development cost per year)
• Testing and UAT Cost: Business analyst and user time for testing

Benefit Components

• FTE Savings: Reduced headcount or redeployment of staff to higher-value tasks
• Error Reduction: Cost savings from fewer rework cycles
• Speed Improvement: Faster turnaround enables business agility (e.g., faster invoice payment = supplier discounts)
• Scalability: Bot handles volume spikes without overtime costs

Simple ROI Calculation Example

 COSTS (Year 1)
 ─────────────────────────────────────────────────────
 Development (20 days × $500/day)       = $10,000
 UiPath Licence (1 bot)                 = $8,000
 VM Infrastructure                      = $2,000
 Testing (5 days × $300/day)            = $1,500
 TOTAL COST                             = $21,500
 ─────────────────────────────────────────────────────

 BENEFITS (Year 1)
 ─────────────────────────────────────────────────────
 FTE Saved: 2.1 FTE × $40,000/FTE/year = $84,000
 Error Reduction (est. 5% saving)       = $4,000
 TOTAL BENEFIT                          = $88,000
 ─────────────────────────────────────────────────────

 NET BENEFIT (Year 1)   = $88,000 – $21,500 = $66,500
 PAYBACK PERIOD         = 21,500 ÷ (88,000/12) = 2.9 months
 3-YEAR ROI             = ((264,000 – 64,500) ÷ 64,500) × 100
                        = 309% ROI

Dimension 4: Strategic Feasibility

Strategic feasibility asks: "Does this automation support the organisation's goals?"

• Does the automation align with the company's digital transformation strategy?
• Does it support compliance requirements (e.g., faster reconciliation for SOX compliance)?
• Will it improve customer experience (e.g., faster response times)?
• Does leadership support this automation, or is there organisational resistance?

The Feasibility Assessment Matrix

A score above 3.5 generally indicates a strong automation candidate. Below 2.5 suggests automation should not proceed without process redesign.

Feasibility Assessment Output

The assessment produces one of three recommendations:

• Proceed with RPA: All four dimensions score positively. Build the bot as designed.
• Redesign First: Process needs standardisation before automation. Address exceptions, document missing steps, then re-assess.
• Do Not Automate: Process is too complex, too unstable, or ROI is negative. Consider other solutions (API integration, process redesign, or cognitive tools).

Summary

A feasibility assessment protects your RPA programme from costly failures. Evaluate every automation candidate across technical, operational, financial, and strategic dimensions. Use a scoring matrix to make objective decisions. Processes that pass all four dimensions are approved for development. Processes that fail on one or more dimensions go back for redesign or are dropped from the automation pipeline. This rigour at the start saves far more time than it costs.