The first version of a process map is usually too tidy. It shows the official sequence, not the spreadsheet copied on Friday afternoon, the approval requested in chat or the customer who sends incomplete information. Those unofficial steps are where useful automation work begins.
Bring together one person who performs the work, one who receives its output and the person accountable for the result. Map a recent real case before discussing software.
Set the boundary with one example
Choose a start and finish that can be observed. “From a customer submitting the quote form to a salesperson accepting or rejecting the lead” is workable. “Automate sales” is not.
Put a real case number or date at the top of the map. This keeps the room anchored to what happened. Later, compare a normal case with one difficult case rather than blending them into an imaginary average.
Record the trigger precisely
A trigger is the event that starts the process, not the tool that notices it. Examples include a verified form submission, an invoice becoming overdue or stock falling below an agreed threshold. State the evidence and the time at which the event counts.
Write down duplicate and late triggers. A payment provider may retry a webhook; a customer may submit twice; an imported file may arrive after a manual update. The process needs a rule for each situation.
Follow the work from the user’s view
GOV.UK Service Manual guidance recommends mapping the whole problem, including touchpoints, behind-the-scenes work and evidence from research. Although it is written for public services, the method prevents an internal automation from optimising one team’s step while making the customer journey worse.
Ask what the customer knows at each point. If an automated check takes two days, show the waiting state and message. Silence is part of the journey even when no staff member considers it a task.
Add decisions and evidence
Draw each decision as a question with named outcomes. “Is the request complete?” is better than “validate”. Beside it, note the data or policy used, who owns that rule and when it was last reviewed.
Do not automate a judgement nobody can explain. If experienced staff disagree about the rule, capture examples and resolve the business decision before translating it into code.
Show every handoff
A handoff occurs when responsibility moves between people, teams or systems. Record what is passed, how the receiver is notified and the expected response time. Mark places where staff currently retype information or ask for missing context.
Include the customer as a participant when they must provide evidence, approve a proof or correct a record. An automation that repeatedly chases somebody for information already supplied is not an improvement.
Give exceptions their own route
For each step, ask what can be missing, invalid, duplicated or unavailable. An exception should lead to an owned queue or safe fallback. “Send admin an email” is weak when nobody monitors that inbox or knows how to resume the case.
Describe which actions may be retried and which must pause. Repeating a data lookup is different from repeating a charge. Keep the original record, failure reason and correction history available for investigation.
Mark data and control points
- Personal, financial or confidential fields entering the process.
- The lawful or operational reason each field is needed.
- People and systems permitted to view or change it.
- Approval needed before money, access or customer status changes.
- Logs required to answer who did what and when.
- Retention or deletion event at the end of the lifecycle.
Do not paste real customer data into a workshop diagram. Use neutral examples and keep any evidence in its approved system.
Choose a small measurable first release
Measure the current process before claiming a saving. Useful measures can include elapsed time, staff handling time, correction rate, abandoned cases and customer wait. Select the step that removes a verified constraint without hiding risk.
Turn the map into acceptance tests and an operating guide. After launch, compare actual exceptions with the map. Update both the workflow and documentation when a new route appears.
Sources and further reading
- GOV.UK Service Manual: map a user’s whole problem — the source for viewing touchpoints and back-end delivery as one journey.
- GOV.UK Service Manual: creating an experience map — a practical reference for evidence-led stages, steps and iteration.
Xapner’s automation and AI integration service can facilitate this mapping before any platform or build is selected.