The bot that processes a returning queue faster
In this fictional scene set in 2024, a team wants to automate reimbursement requests. A bot opens emails, copies references and prepares replies. The demonstration is quick. Yet the same cases return because the evidence requirement is unclear and two managers interpret the approval threshold differently. All people, amounts, volumes and results are invented for teaching. They describe no CYTIZEN client engagement. The bot speeds up the first manipulation without addressing why a case fails to reach a valid outcome.
A poor process is not simply a slow process. It may contain an unnecessary decision, ambiguous responsibility, information requested too late or a misplaced control. Automation can make defects more frequent and harder to notice. This retrospective discussion of 2024 uses official sources checked in October 2026. Digital.gov's RPA Playbook and the UK Service Manual are methodological references; their current pages are not claimed historical snapshots of 2024.
Follow the case to its real conclusion
Observe complete cases rather than timing a single task. In the scenario, a case moves through receipt, checking, approval, payment and closure. It returns to checking when evidence is missing or a decision is challenged. Record active work, waiting and rework, retaining difficult cases. Testing only simple, well-prepared requests exaggerates automation value and says little about the service as a whole. Define completion through the intended result: correct payment confirmed, an understandable rejection or a clear request for additional information.
A sent reply is not necessarily a resolution. Include returns, corrections and work shifted to applicants or support. A tool that saves one team time while adding work elsewhere might still be worthwhile, but that choice must be explicit. The business case should show total workload and who accepts the change. Separate reduced effort from usable capacity and cashable savings. Without an operational destination for saved time, a theoretical saving remains a potential benefit.
Trace rework to a testable cause
Classify returns by reason and verify those reasons against evidence. “User error” is insufficient. Did the form request the right document? Did the message explain the format? Was the rule accessible during entry? Did an interface lose information? Did a manager receive contradictory instructions? Successive questions should identify a testable cause rather than a person to blame. Broad claims such as “lack of discipline” do not support a precise remedy or a credible comparison after the change.
In the fictional flow, supporting evidence is requested only after the first review. The team tests a clearer entry requirement with an example and a presence check. It also finds two approvals examining the same risk. The sponsor asks competent control owners to justify both controls. They do not remove an approval solely to save time: they examine its purpose, evidence and whether a simpler equivalent can protect the same decision. Speed is one design consideration, alongside accountability and service quality.
Business decisions precede the bot. For each branch, specify who may approve, reject or request more information and on what evidence. Stable, verifiable rules can be automated. Contextual judgement stays with a person unless delegation conditions are established. Separate collection, deterministic checks, decisions and exceptions. Automation may assist a decision without receiving authority to make it. Make that boundary visible in interfaces, logs and ownership, rather than burying it in technical documentation.
A completed causes and decisions table
This fictional table links a symptom to a cause, a pre-automation decision and a test. Before development, trial the corrected flow manually within a limited scope.
| Illustrative symptom | Cause and evidence | Decision before automation | Test and owner |
|---|---|---|---|
| Document requested after initial review | Incomplete entry form; returned cases | Request evidence at entry and explain format | Returns by reason; service owner |
| Two identical approvals | Same risk checked twice; instructions and signatures | Confirm target control and decision authority | Review evidence and exceptions; control owner |
| Incorrect copied reference | Manual transcription; source comparison | Automate reading with review of uncertain cases | Error rate and review time; technical owner |
The full register records decision dates, dependencies, prohibited bot actions and conditions for manual fallback. An unresolved rule remains open; it is not turned into a default in code to meet a deadline. A technically functional automation can execute an unauthorised business decision. The business owner accepts the rule, the control owner accepts the evidence and the technical owner verifies compliance with the agreed boundary. Each responsibility needs a named person and an escalation path.
Compare three options
First, remove or simplify the step. Eliminating unnecessary work may create more value than automating it. Second, repair the flow while retaining human execution, which may suit low volumes or frequently changing rules. Third, automate a defined process. For each option include design, control, maintenance, exception handling and effects on other teams. Avoid assuming that the most technically impressive option is the most economical. Revisit the case after simplification, because the opportunity itself may have changed.
In an illustrative calculation, 400 monthly cases require six minutes of copying each, producing 40 hours of gross potential capacity. That figure is insufficient. Reviewing every case for two minutes already consumes more than thirteen hours, before exceptions and maintenance. If an improved form removes most copying, the bot may lose its justification. These fictional figures demonstrate sensitivity to assumptions. They do not predict returns for another organisation or establish a standard review time.
Where possible, compare the corrected flow without a bot against the corrected flow with one. Comparing a bot against a deliberately unrepaired process confuses simplification value with technology value. Measure end-to-end timing, correct decisions, rework, control workload and ageing exceptions. Record volumes and categories: a quiet month can conceal peak-load failures. Outcome quality remains a release condition even when execution speed improves. Include uncertainty and explain which claims the pilot cannot yet support.
Design operation and stopping conditions
A bot requires an operational owner, support, appropriate permissions and usable records. Unexpected input should trigger detection rather than silent approximate interpretation. Exceptions enter a queue with ownership and priority. If half the cases are rejected without sufficient human capacity, the service can become slower. Design maximum exception workload and conditions for suspension. Keep the state of each transaction clear so a restart does not duplicate payment or lose a request.
Agree stopping criteria before the demonstration. In the scenario, an unauthorised decision causes immediate suspension; excessive rework triggers scope review; a changed form or rule requires verification before restart. Precise thresholds are documented local choices. The team must be able to stop without losing cases and resume manually. That fallback capacity limits the cost of a failed trial. It also makes a bounded pilot more credible because the organisation can withdraw it safely if its assumptions prove wrong.
The review chooses continuation within tested scope, modification and retest, or termination. Stopping can be sensible when the simplified process is sufficient or controls consume the gain. Show evidence, limits and remaining costs to the sponsor. Transaction count alone is inadequate: a bot can perform many unnecessary actions. The final criterion is an effective service with acceptable total workload and risk, supported by a process whose decisions and exceptions are understood.
Adapt causes and controls to the sector
Manufacturing defects may come from unsynchronised references or unconfirmed physical events. Financial-service approvals can protect specific risks and require competent control review. Public-service evidence requests can create exclusion or repeated returns; simplification must preserve a justifiable decision. Professional-service approval loops may reveal unclear commercial responsibility. These are diagnostic examples, not observed engagements. Follow the real case outcome, verify causes, decide the rules and test the corrected process. Automate where additional value can be demonstrated.
Verified primary references
Sources checked in October 2026. The references support process selection, improvement and understanding complete user journeys. Examples, calculations and stopping rules are independent teaching material.
- Digital.gov — RPA Playbook, primary reference from the US federal programme.
- GOV.UK Service Manual — Map and understand a user's whole problem.
- GOV.UK Service Manual — Creating an experience map, initially published in 2017, current page consulted in 2026.