RPA Operations
Part of Robotic process automation
Choosing a stable task for a bot pilot
Screen a proposed RPA pilot task for clear rules, representative variations and expected process or application changes.
Choose a bot pilot task whose rules, inputs and application behaviour are likely to stay consistent long enough to learn from it. Define a narrow case type, inspect real variations and ask about planned changes before building. A frequent task can still be a poor pilot if staff disagree on how to finish it.
Describe the exact task
Write one sentence covering the task's trigger, action and result. Example: when an approved request with all required fields enters a queue, enter those fields in the destination application and confirm the new record's identifier. State which requests are excluded.
The organisation's process owner must supply the actual rules and fields.
Separate the bot's work from surrounding decisions. A manager's approval is an input to this example task. A disagreement about whether the request should be approved falls outside a straightforward data-entry pilot.
The result should be observable in the destination system, rather than inferred from the bot reaching its last step.
Steps to Define a Stable Bot Pilot Task
- Write one sentence describing trigger, action and resultExample: When an approved request with all required fields enters a queue, enter those fields in the destination application and confirm the new record's identifier.
- Exclude non-eligible requests explicitlyDefine boundaries to avoid ambiguous inputs.
- Separate bot work from human decisionsDo not include approval logic in the bot’s task scope.
- Ensure result is observable in destination systemAvoid relying on bot reaching last step as proof of success.
Examine recent cases and variations
Ask staff to walk through recent cases that fit the proposed rule, plus cases that looked eligible but took another route. Record the input format, steps, rule used and final state.
Where possible, compare their account with the request and destination record. A small sample can reveal variations; it cannot establish the share of all work a bot could handle.
Look for missing fields, alternative screen routes, duplicate requests, corrections after submission and decisions made from information outside the stated input. A variation may be legitimate. Include it under a defined rule or send it to a person.
Check two kinds of stability
Ask the process owner which rules, forms and approval paths are due to change during the pilot. Ask application owners about planned releases, screen changes and access changes. Treat expected process changes and expected application changes as separate questions, whether or not you use a formal assessment.
| Finding | Pilot decision to consider |
|---|---|
| The normal route is agreed and recent cases follow it. | Keep the candidate and document its rule. |
| Staff use several valid routes. | Limit the pilot to one route or define each branch. |
| A required field is often reconstructed manually. | Improve the input or add a human check before bot entry. |
| A screen or approval rule is due to change. | Set the pilot after the change or allow for rework. |
| Completion cannot be checked in the target system. | Establish a result check before proceeding. |
Use this as a qualitative screen. Record uncertainty instead of assigning a precise suitability percentage without local evidence.
Stability Check: Process vs Application Changes
- Process Stability
- Rules, forms and approval paths are stable and agreed upon
- Application Stability
- No planned releases, screen changes or access updates expected during pilot
Set a boundary that can be judged
State the included case type, anticipated cases during the trial, application and runtime, authorised identity, exception owner and source of completion evidence. Choose a period likely to encounter representative cases; its length depends on the task's frequency. Agree in advance what would count as a useful result.
Plan checks for a complete case, a missing field, a duplicate and an application rejection using safe records. Verify the destination state and track human review, corrections and unresolved items as well as bot runs.
If early cases show that the task changes often or its rules are disputed, pause expansion. Clarify the task or choose another candidate. The pilot should yield an interpretable decision, including a decision that a bot is unsuitable.
