Automating repetitive work is tempting: the same transfer, approval and report, delivered faster. Yet speed is not always the first question. A step with no identifiable consumer may remain wasteful even when executed perfectly. Conversely, removing a step that provides a real control can make a workflow look shorter while making it riskier. The useful starting question is what value the step actually protects.
Find out why the step exists
In a hypothetical example, a receptionist copies order details from a form into a file and sends it to the delivery team. Perhaps the file compensates for missing access. Perhaps it also supports a discrepancy check that the form does not show. Those tasks look similar but have different purposes. Before buying software, speak with both the person producing the output and the person using it.
GOV.UK's second service principle favors the user's whole problem over a preselected technology. The practical interpretation offered here is to examine the work on both sides of the proposed automation, rather than treating the chosen step as an isolated task. GOV.UK: the user's whole problem
Removing work is not the same as removing a control
For each step, record its output, its consumer and the error it is supposed to prevent. If a transfer only creates another copy, access to a shared source might replace it. If the step checks identity, quality or permission, that control still needs a clear owner and location in the new workflow. Removing a form does not remove accountability. The responsibility must remain traceable.
NN/G describes a service blueprint as a map linking people, processes and customer touchpoints. A modest version of that map can expose the backstage transfers in this example. The point is not to produce an impressive diagram; it is to see which part becomes uninformed or loses authority when another part disappears. NN/G: mapping service delivery
Consider three options, not just a bot
Compare three choices: remove a step whose purpose has disappeared; simplify a step that still matters; or automate a part with clear rules and dependable inputs. A workflow need not use one choice throughout. Recording information might be automated, unusual cases might remain with a person, and an obsolete report might be retired altogether. The work should determine the combination.
For the order example, a first experiment could simply give the delivery team access to a shared status. If conflicting copies and repeated follow-ups caused the difficulty, that small change offers something concrete to test. If the necessary information is still missing, automation cannot repair its absence; it merely sends the incomplete record onward faster. These options are hypotheses, not promised results.
Test an ordinary day and a difficult one
Do not test only a complete, cooperative order. Include amendments, incomplete inputs, lost access and corrections. Who notices a stoppage? Who can reverse a decision? Does the customer still need to phone? GOV.UK's simplicity principle also calls for testing both online and offline parts of a service with users. GOV.UK: simplicity and usability testing
The proposed measure here is not the number of installed bots. Compare time to a usable outcome, repeated entry, detectable errors and traceability before and after the change. If faster execution creates more ambiguity, revisit the route. Valuable automation does more than take a task out of someone's hands: it places the work where it belongs and makes the remaining responsibilities understandable.