How to Build an Automation Opportunity Assessment Framework

An automation opportunity assessment framework is a structured method for discovering and scoring automation candidates, then sequencing each one and routing it to the best-fit technology, robotic process automation (RPA) or agentic AI, on objective criteria rather than a platform vendor’s scoring. The routing question carries weight because the spending has already started: McKinsey’s State of AI 2025 reports that only 6% of companies see meaningful earnings before interest and taxes (EBIT) impact from AI investments (McKinsey, 2025). A framework that scores work on observed volume, rule density, exception rate, and risk, and keeps that scoring independent of any execution platform, gives an operations leader a defensible answer to which processes should be bots, which should be agents, and which should stay with people.

What is an automation opportunity assessment framework?

An automation opportunity assessment framework is the operating method an automation program uses to decide which processes to automate, in what order, and with which class of technology, using process evidence instead of stakeholder lobbying. It replaces the usual intake pattern, where the loudest business unit gets the next bot, with a repeatable sequence that a chief financial officer can audit.

The framework has five standard components:

• Discovery and mapping: The team builds an inventory of candidate processes and documents how each one runs in practice, including handoffs between applications and the exception paths that never appear in a procedure manual.
• Suitability criteria: Each candidate is tested against rule-based share, exception rate, transaction volume, system access, and risk exposure.
• Weighted scoring: The criteria are weighted and converted into a comparable score so that an accounts payable (AP) invoice match and a Know Your Customer (KYC) review can sit in the same ranked list.
• ROI and feasibility: The team calculates full-time equivalent (FTE) savings, implementation cost, and payback period for each shortlisted candidate.
• Sequenced roadmap: Scored candidates are arranged into quick wins and longer programs, each tied to a technology path and a business owner.

The team uses the framework to assess RPA and agentic AI as separate suitability questions rather than one score. Gartner’s June 2025 guidance draws the line at decision-making. Use AI agents when decisions are needed and automation for routine workflows. Assistants fit simple retrieval (Gartner, 2025). A framework that collapses those paths into one “automation potential” number will steer judgment work toward bots that cannot handle it.

The five phases of the framework, end to end

The team runs the framework as five sequential phases, each closing with a named deliverable that the team uses in the next phase, so that a scored candidate can be traced back to the observation that produced it. Academic case research found that none of the companies studied used standardized selection tools; all of them started by collecting processes and then narrowing down (Wanner et al., 2019). The phases below formalize that path.

1. Discovery. The team identifies candidate processes through workshops, observation, task mining, or process mining and records volume, roles involved, and applications touched. Deliverable: a process inventory.
2. Process analysis. For each inventoried process, the team measures the execution paths (process variants), where work stalls, how often a case leaves the standard path, and how much rework occurs. Deliverable: variant analysis, bottleneck map, and exception rate data.
3. Prioritization. Analysts apply the weighted rubric to every candidate and separate deterministic work from judgment work. Deliverable: a scored opportunity register with an RPA path or an agentic path flagged per candidate.
4. Solution design. For the top-ranked candidates, the team specifies the target design at step level: inputs, decision rules, exception handling, escalation points, and the systems the automation must read from and write to. Deliverable: an automation blueprint, sometimes called a process definition document.
5. Roadmap. Leadership sequences the designed candidates into waves, attaches a business case to each, and assigns owners. Deliverable: a sequenced implementation plan with FTE and dollar impact per opportunity.

The quality of each deliverable depends on the quality of the one before it. A scored register built from an inventory that missed the spreadsheet workaround between the claims system and the payment platform will rank the wrong process first.

What makes a process a good candidate for automation?

A good automation candidate is high volume, rule-based, stable, fed by digital inputs, and low in exceptions, with every system it touches reachable through an application programming interface (API) or a screen that software can read. Those signals recur across selection research and practitioner case studies since 2015; where sources disagree, they disagree on weights and cutoffs.

Positive signals to confirm during process analysis:

• Rule-based, repeatable steps: A documented rule exists for every branch the process can take.
• High transaction volume: The process runs often enough that saved minutes compound into FTEs.
• Stable process: Neither the workflow nor the underlying applications are scheduled for redesign or replacement.
• Low exception rate: Most cases complete without a person deciding something the rules do not cover.
• Digital, structured inputs: The process starts from system data or electronic documents rather than phone calls or paper.
• System access available: Every application in the path can be reached by API, or observed and operated at the screen level, including mainframe and virtual desktop infrastructure (VDI) sessions.

Red flags that should lower a score or remove a candidate:

• Iterative or non-linear flow: A process that loops back on itself (a prior authorization that bounces between clinical reviewer and provider three times) defeats linear bot design.
• High judgment requirement: Fraud resolution, complex policy exceptions, and underwriting referrals require reasoning that RPA cannot encode.
• Active redesign: Automating a process that will change next quarter buys a maintenance burden.
• Invisible execution: Work done by phone or on paper leaves no digital footprint for either event logs or screen observation.
• Undocumented variants: Deloitte’s 2020 intelligent automation survey found only 38% of organizations had mature process definitions (Deloitte, 2020).

HFS Research’s April 2026 readiness tests are a useful final screen before any candidate reaches the rubric. Ask “Will the same situation produce the same decision every time?”, “Can exception handling be clearly explained?”, and “Would the process run consistently without experienced employees?” If the answer to any of these is no, HFS concludes, the process is not ready for autonomy (HFS Research, 2026). In our reading, a no on the first two questions means the work should stay human-led, or at most move to an agent-suggests, human-acts arrangement. A no on the third means the process needs stabilizing before any automation.

The scoring rubric: criteria, weights and thresholds

Analysts use the rubric to convert the suitability signals into a weighted score, and the organization chooses the weights, because no Gartner, Forrester, Everest Group, or HFS Research publication discloses numeric weights for volume, rule-based share, or exception rate. Academic models do publish weights, but they use different criteria sets and scales; one analytic hierarchy process study weights frequency and digital data highest, with number of systems and human input among the lowest (Costa et al., 2023), while others rank standardization or robot step count first. Averaging them into a composite would produce a number with no provenance.

The matrix below is a starting point for the automation center of excellence (CoE) to calibrate against its own portfolio. A spreadsheet version of this scorecard is available on request from Skan AI. Whichever version you use, record the measurement behind every score:

Table: Illustrative Weighted Scoring Matrix for Automation Candidates

Thresholds need to be set at two levels. The first is an economic floor: the Telefónica O2 program studied by Lacity and Willcocks treated a process as automatable only if automation could save at least three FTEs (LSE, 2015), while other programs set floors well below that, so the CoE should choose a floor that matches its cost base rather than copy one.

The second threshold governs routing between deterministic and agentic paths. The only numeric routing threshold we found in published research comes from McKinsey’s 2025 banking analysis of financial crime operations, which argues manual intervention should be reserved for the highest-complexity exceptions and escalations, typically less than 15 to 20 percent of total volume (McKinsey, 2025). In practice a candidate that scores high on rule-based share and low on exceptions is an RPA referral, a candidate that scores high on volume but low on rule-based share is an agentic referral, and a candidate that scores low on both is a redesign referral.

When discovery is bundled into an execution platform, the vendor’s own toolchain shapes the score, so a high “automation potential” rating doubles as a recommendation to buy more of that platform. With Automation Explorer, a CoE gets two separate outputs from observed work, an RPA Opportunity Score for deterministic, repetitive tasks and an Agentic Automation Score for tasks requiring context, reasoning, or judgment. The scoring is vendor-neutral, so a process can route to whichever RPA or agent platform the enterprise already runs without the assessment steering the answer.

Worked example: scoring and costing one invoice process

An AP invoice process illustrates the full arithmetic, from observed hours to payback, using one labor-cost benchmark and one exception-rate benchmark so every multiplier has a source. Assume a shared services center that receives 240,000 supplier invoices a year, where a processor opens the invoice, matches it to a purchase order (PO) in the ERP system, checks the receiving record, and releases it for payment, and where discovery measured an average of 10 minutes of touch time per invoice.

The hours and FTE calculation:

1. Annual hours consumed: 240,000 invoices × 10 minutes ÷ 60 = 40,000 hours.
2. FTE equivalent: 40,000 hours ÷ 1,800 productive hours per FTE = 22.2 FTE. (Published labor statistics are per hour worked and do not specify an annual hours figure, so the CoE sets this divisor.)

The cost basis comes from U.S. employer compensation data. Office and administrative support occupations in private industry cost $36.73 per hour worked in wages and benefits for the June 2026 reference period (BLS, 2026). Applied to the process: 40,000 hours × $36.73 = $1,469,200 a year in direct labor, before any overhead loading.

Not every invoice can be automated. Ardent Partners’ State of ePayables 2025 reports an overall invoice exception rate of 18.4% (Ardent Partners, 2025). Assume the rubric confirms that PO-matched electronic invoices, 80% of volume, score as RPA candidates, while the remaining 20% (missing POs, price variances, duplicate suspicion) stay with processors. That 80% share is this example’s own assumption, set close to the benchmark, and it is the reason this candidate can justify a payback far shorter than survey averages: every step in the matched path has a rule and the ERP screens are stable.

The savings and payback calculation:

1. Hours removed: 40,000 × 80% = 32,000 hours, or 17.8 FTE.
2. Annual gross saving: 32,000 × $36.73 = $1,175,360.
3. Implementation cost (assumed): $400,000 one-time for design, build, testing, and first-year licences, plus $150,000 a year in run cost for licence renewal, maintenance, and monitoring.
4. Annual net benefit: $1,175,360 − $150,000 = $1,025,360.
5. Payback period: $400,000 ÷ ($1,025,360 ÷ 12) = $400,000 ÷ $85,447 ≈ 4.7 months.

The candidate clears the three-FTE floor from the rubric section by a wide margin and pays back in under five months. Two cautions belong in the business case. The 17.8 FTE is capacity released, and finance should decide whether it becomes redeployment or headcount reduction before the number reaches a board deck. And the 20% exception queue remains human work that will now arrive with the easy cases removed, so per-case handling time in that queue should be re-measured after go-live rather than carried forward at 10 minutes.

How do you calculate ROI and FTE savings before you build?

Return on investment (ROI) before build depends on separating benefits into hard, soft, and strategic categories, counting only the hard category in the payback calculation, and stating the cost basis and hours assumption explicitly so finance can challenge each one. The invoice example used hard benefits alone; a complete business case records the other two categories without monetizing them unless an approved measurement exists.

Benefit categories to record:

• Hard benefits: Released FTE hours priced at a loaded hourly rate, rework eliminated, error cost avoided, and throughput increased without added staff.
• Soft benefits: Reduced manual burden on processors, improved audit trail quality, and fewer compliance findings tied to inconsistent handling.
• Strategic benefits: Volume growth absorbed without hiring, process data available for continuous improvement, and the ability to automate regulated work that less prepared competitors cannot yet address.

FTE savings formula: Hours per transaction × annual volume = total hours consumed; total hours ÷ annual productive hours per FTE = FTE equivalent; FTE equivalent × fully loaded cost = annual savings potential.

Payback formula: Implementation cost ÷ annual net savings = payback period. The cost basis is a common source of drift in business cases. Employer compensation statistics cover wages and benefits only; if finance requires overhead in the loaded rate, state the multiplier it applies and apply the same multiplier across every candidate so the ranking stays comparable.

Payback expectations should be tested against independent survey data rather than vendor-commissioned economic impact studies, which model a composite enterprise and are not failure-inclusive samples. Deloitte’s 2022 global intelligent automation survey found the average payback period for pilots had lengthened to 22 months (Deloitte, 2022). A business case that promises payback in a few months for a pilot should be able to explain, candidate by candidate, why its exception rate and system access are better than the survey population’s.

Choosing a discovery method: workshops, time-and-motion, task mining or process mining

The analysts’ choice of discovery method determines what the inventory captures, and the choice between event-log process mining and desktop-level observation decides whether cross-application handoffs and manual workarounds enter the scorecard at all. Each method trades cost against coverage:

Table: Comparison of Discovery Methods for Automation Assessment

Process mining tools such as Celonis and UiPath Process Mining reconstruct a process from timestamped events that enterprise systems record. The reconstruction captures work the system saw and omits work it did not.

McKinsey notes that event logs miss work such as email and phone change requests and spreadsheet manipulation before data entry. In one retailer’s process mining program, McKinsey found multiple sources of delay and rework driven by actions outside the ERP system (McKinsey, 2024). In a claims operation, that outside-the-ERP work is the adjuster reconciling a spreadsheet with an email attachment, which is where cost and delay enter.

Task mining records desktop activity and so captures those gaps, but conventional user-interface logs carry no notion of a case identifier, unlike event logs, so an analyst must segment and relate the recorded actions to a process execution before they are useful (Process Mining Handbook, 2022). Episodic recorders that capture a known task for a handful of users compound the problem: they confirm variations of what the team already knew to look for and cannot discover unknown work across an operation.

Skan AI addresses both limitations through continuous screen-level observation across mainframes, VDI, legacy desktop applications, web applications, spreadsheets, and office tools, without a backend connector for each system. Computer vision classifies the activity on screen, and neurosymbolic AI, neural perception combined with symbolic rule-based reasoning, stitches those observations into end-to-end flows while preserving an explainable path from observed activity to classification. The output is the Context Graph of Work, a continuously updated property graph connecting people, applications, tasks, decisions, policies, and outcomes, so that the opportunity inventory reflects observed exception paths and cross-system handoffs rather than the documented process. Email content and keystrokes are never captured, and the unit of analysis stays on work and processes rather than individual workers.

Matching opportunities to technology: RPA, BPA, IPA, AI agents and iPaaS

A scored candidate routes to one of five technology categories according to how deterministic its steps are, how structured its inputs are, how many systems it spans, and whether a judgment sits in its path. The categories overlap in vendor marketing, so the assessment should define each by the work it fits rather than by product name.

RPA and BPA: RPA is software that operates on the user interface of other systems the way a person would, following business rules with human exception management. Business process automation (BPA) platforms orchestrate workflows, approvals, and case management across systems through configured logic.

IPA and AI agents: Intelligent process automation (IPA) combines RPA with machine learning and natural language processing to handle unstructured inputs, a combination McKinsey described in 2017 as pairing process redesign with RPA and machine learning (McKinsey, 2017). AI agents are, in Gartner’s August 2025 definition, autonomous or semiautonomous software entities that use AI techniques to perceive, make decisions, take actions, and achieve goals (Gartner, 2025).

iPaaS: Integration platform as a service (iPaaS) moves data between systems through APIs and connectors and is an integration layer rather than an automation of work.

The four routing questions, applied in order, map a candidate to a category:

1. Is the task rule-based and repetitive, with structured inputs? Route to RPA, or to API integration where one exists.
2. Does the task require judgment, context, or multi-step reasoning with variable inputs? Route to an AI agent, with a human decision point wherever risk is high.
3. Does the process span multiple systems and need orchestration or data movement rather than screen work? Route to BPA or iPaaS.
4. Does the process begin with documents or unstructured content such as scanned invoices or claim forms? Route to intelligent document processing (IDP) combined with RPA, which is the IPA pattern.

The table applies those questions to common operations candidates.

Table: Candidate Process Patterns Mapped to Technology Categories

Routing to the best-fit platform matters more as agent programs scale, because Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 (Gartner, 2025). An enterprise that keeps its scoring independent of the execution stack can send a deterministic invoice match to the RPA platform it already licenses and a KYC exception review to an agent platform, and it retains the evidence behind each routing decision when a program is challenged.

From scorecard to roadmap: quick wins, deliverables and pilot sequencing

Leadership places every scored candidate on an impact-versus-effort grid, sequences the high-impact, low-effort quadrant as the first wave, and holds the high-impact, high-effort quadrant for funded programs with their own design phase. Everest Group’s RPA Process Selection Toolkit uses the same two-by-two output, scoring potential and cost or volume against ease of implementation (Everest Group, 2018).

The four quadrants and how to treat them:

• High impact, low effort (quick wins): Deterministic, high-volume processes with API or stable screen access. Sequence first; the invoice release example above belongs here.
• High impact, high effort (programs): Judgment-heavy or multi-system processes such as KYC review. Fund a design phase and a human-baseline evaluation before build.
• Low impact, low effort (fill-ins): Automate when delivery capacity is idle, and never ahead of a quick win.
• Low impact, high effort (defer): Record in the inventory and revisit when the process is redesigned or volume grows.

Pilot sequencing follows a rule the Xchanging insurance program stated in 2015 after rejecting several processes before choosing its first four: “Don’t automate a process that’s not ready… Stabilise it first” (LSE, 2015). The first pilot should be a quick win whose process owner is committed, whose exception paths are fully observed, and whose result can be measured against the baseline captured in discovery.

The assessment team closes with four deliverables that leadership can act on:

• Opportunity inventory: Every discovered process with its volume, variant count, exception rate, and dual score.
• Business case: FTE savings, cost basis, implementation cost, and payback per shortlisted candidate, with assumptions stated.
• Roadmap: Wave-sequenced candidates with technology path, owner, and target measure for each.
• Blueprint: Step-level design for first-wave candidates, including decision rules, exception handling, and write-backs to systems of record.

Skan AI Blueprint produces the inventory-to-roadmap chain from observed activity rather than workshop maps, ranking opportunities by measurable impact and attaching dollar impacts per opportunity, and produces a prioritized roadmap tied to measurable business outcomes. Because the observation that fed the roadmap continues after approval, the team can re-score the roadmap when a process drifts instead of letting it expire the day the deck is presented.

How long does an assessment take, who is involved, and what does it cost?

An observation-based assessment delivers an initial process inventory and variant analysis within a few weeks, and the full scored register and roadmap in weeks, not months, while log-based discovery adds a data engineering project per source system before analysis can begin. Workshop-only assessments move at the pace of SME availability and tend to produce documented processes rather than observed ones.

Typical phase timing:

• Discovery and process analysis: Initial operational insight within a few weeks of deploying observation.
• Prioritization and solution design: Scored register and first-wave blueprints in weeks, not months.
• Roadmap and business case: Delivered with the register; refreshed continuously as observation continues.

Client roles the assessment needs:

• Executive sponsor: A head of operations or transformation lead who owns the roadmap decision and the FTE conversation with finance.
• Process owners and SMEs: Validate observed variants and classify exceptions; their time is the largest internal cost.
• Automation CoE or delivery lead: Owns the rubric weights, the register, and the handoff to build teams.
• IT and data engineering: Required for log-based discovery and for API feasibility checks; lighter for screen-level observation, which needs no backend connectors, though IT still governs desktop deployment.
• Compliance and information security: Sign off on data handling for observation and on the risk tier for each candidate.

No analyst firm or major consultancy publishes a fixed fee or fee range for an enterprise automation opportunity assessment; the only public figures are small partner offers on cloud marketplaces, public-sector day-rate ceilings, and public procurement values, neither of which reflects a regulated Global 2000 engagement. Cost scales with process count, the number of source systems that need connectors, consultant day rates, and tooling licences. Commercial models are also shifting from headcount-based fees toward outcome- and platform-based pricing, which may tie assessment fees to outcomes rather than to days consumed.

Governance, risk, and human-in-the-loop controls after the assessment

Every candidate that passes the rubric must still clear technical feasibility gates and a governance design before build, because a high score describes economic fit and says nothing about whether the automation can be operated inside the enterprise’s control environment. The gates belong in the solution design phase, not after the bot or agent is in production.

Feasibility gates to document per candidate:

• API availability: Whether each system exposes a stable interface, or whether the automation must operate at the screen level and tolerate layout changes.
• Legacy and mainframe access: Whether terminal and VDI sessions can be reached and whether screen-level operation is permitted under the application owner’s policy.
• Data structure: Whether inputs arrive structured, or whether IDP must sit in front of the process with a measured extraction accuracy.
• Security and compliance sign-off: Whether the automation’s access rights, segregation of duties, and data residency meet the control owner’s requirements. For screen-level observation, Skan PRISM applies pixel-level redaction inside the customer environment so protected information stays within the customer-controlled perimeter before any data leaves it.

Human-in-the-loop design should follow the risk tier of the decision. Article 14 of the EU AI Act (Regulation (EU) 2024/1689) requires that high-risk systems be designed so natural persons can oversee them effectively, including the authority to disregard or override outputs. Overseers must also be able to reverse outputs and intervene through a stop function (EUR-Lex, 2026). The NIST AI Risk Management Framework asks for the same capability in MANAGE 2.4: mechanisms to supersede or disengage a system, as well as deactivate it (NIST, 2023). BCG’s December 2025 trust protocol frames the escalation of autonomy in three tiers. At tier one, the agent suggests and the human acts. At tier two, the agent acts and the human approves. At tier three, humans become exception handlers (BCG, 2025). A claim-status inquiry can start at tier three; a fraud referral reversal should start at tier one.

An operations team cannot govern an agent from a process diagram. The agent needs the decisions, exceptions, policies, and escalation points that shape the work in practice, encoded in a form it can execute against.

Agent Operating Procedures: Agent Operating Procedures are machine-usable representations of observed work that encode workflow steps, decision rules, exception handling, policies, escalation thresholds, execution rules, and success criteria, so that an agent receives a bounded operating procedure rather than a generic prompt. When an adjuster reverses an agent’s claims recommendation, the process owner uses the approved reversal to update the governing procedure rather than allowing it to disappear into a case note.

Continuous controls monitoring: The control team closes the loop after deployment through continuous controls monitoring. The team uses observation of process activity to detect deviations from approved procedures and raise alerts without system integrations, which gives the control owner evidence for Anti-Money Laundering (AML), KYC, HIPAA, and segregation-of-duties reviews drawn from how the work ran rather than from how the procedure said it should run. The control and governance layer records inputs, outputs, actions, decisions, and rationales for case-level review.