Planning checklist
RPA Opportunity Assessment
A practical scorecard for deciding whether a desktop or browser task is suitable for robotic process automation, direct integration or process redesign.
Published by SpeedInno · Material review 15 August 2026
Quick checklist
Review these items first. Marking an item is not proof of readiness; retain the decision, evidence and accountable owner described in the detailed guidance below.
- Trigger and outcomeName what starts the task, the required result, its frequency and the person accountable for the completed work.
- Stability and rulesRecord whether the steps and target screens are stable, where judgment enters and how often the path changes.
- Volume and effortMeasure handling time, waiting, rework and exception rate with observed samples rather than estimates alone.
- Alternative routeCheck for a supported API, file exchange, configuration change or process simplification before choosing user-interface automation.
- Attended or unattendedChoose whether a person starts and supervises the automation or whether managed machines and schedules run it without a person present.
- Applications and accessInventory screens, selectors, files, credentials, permissions, machine requirements and session constraints for every target system.
- Exceptions and recoveryDefine business exceptions, technical failures, retry limits, a human work queue and how partially completed work is reconciled.
- Change and supportAssign monitoring, alerts, runbooks, application-change testing, release approval and retirement ownership.
How to use this resource
- 1.Work through it with the people who own the workflow, data and release decision.
- 2.Attach evidence or a named open question to every material answer.
- 3.Separate confirmed facts, assumptions, risks and decisions that require approval.
- 4.Finish with an owner, next decision and review date, not a checked document only.
Use four decision states, not a misleading percentage score
Confirmed
Evidence exists and the accountable owner accepts it.
Assumption
A working belief is recorded with a validation action and date.
Risk
The uncertainty can materially change scope, safety, cost or release.
Not applicable
The rationale is explicit and has been reviewed; it is not simply unanswered.
Qualify the work before automating it
A repetitive task is only a useful RPA candidate when its rules, inputs, ownership and exceptions can be made explicit.
Trigger and outcome
Name what starts the task, the required result, its frequency and the person accountable for the completed work.
Questions to resolve
- What is the verified current state of trigger and outcome, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Stability and rules
Record whether the steps and target screens are stable, where judgment enters and how often the path changes.
Questions to resolve
- What is the verified current state of stability and rules, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Volume and effort
Measure handling time, waiting, rework and exception rate with observed samples rather than estimates alone.
Questions to resolve
- What is the verified current state of volume and effort, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Alternative route
Check for a supported API, file exchange, configuration change or process simplification before choosing user-interface automation.
Questions to resolve
- What is the verified current state of alternative route, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Design an operable RPA boundary
The automation needs an identity, environment, failure path and owner after the first successful run.
Attended or unattended
Choose whether a person starts and supervises the automation or whether managed machines and schedules run it without a person present.
Questions to resolve
- What is the verified current state of attended or unattended, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Applications and access
Inventory screens, selectors, files, credentials, permissions, machine requirements and session constraints for every target system.
Questions to resolve
- What is the verified current state of applications and access, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Exceptions and recovery
Define business exceptions, technical failures, retry limits, a human work queue and how partially completed work is reconciled.
Questions to resolve
- What is the verified current state of exceptions and recovery, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Change and support
Assign monitoring, alerts, runbooks, application-change testing, release approval and retirement ownership.
Questions to resolve
- What is the verified current state of change and support, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
How to turn the checklist into an implementation decision
1. Establish the baseline
Record what exists, how it was observed and where evidence is incomplete. Keep reported behavior separate from reproduced behavior. This prevents the future design from treating assumptions or one person’s workaround as an approved requirement.
2. Define the target and boundary
Describe the capability or decision the next phase must enable, the users and records it covers, and the adjacent work it deliberately does not replace. A clear exclusion is useful only when its operational consequence and owner are understood.
3. Resolve the highest-consequence uncertainty
Prioritise questions that can change architecture, data purpose, security, migration, acceptance, commercial scope or launch readiness. Test or decide those before polishing lower-risk screens and convenience features.
4. Create traceable delivery evidence
Link each accepted requirement to its decision source, implementation boundary, test or review method and release owner. When the requirement changes, update the connected artifacts instead of leaving contradictory copies in documents, tickets and code.
Expected output
The result should identify a bounded pilot, a better non-RPA alternative or a clear reason to stop. It should also name acceptance evidence, exception handling and the owner who will operate the automation.
Related capability