Automation process map An automation process map shows each step, owner, system, choice and failure route.
Every first draft of a process map comes out tidier than the process. 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.
Mapping one process
A dental practice wants to automate appointment reminders. The boundary is set with one example: from the moment a booking is confirmed to the moment the patient either attends or the slot is released.
Following the work from the receptionist’s view turns up something the brief had missed. Reminders are not the bottleneck. The bottleneck is what happens after a cancellation: someone has to look down the waiting list and ring people in order. on a busy day that does not happen. the slot goes empty.
The first release is therefore not the reminder at all. It is a text to the top three names on the waiting list when a slot opens, with the first reply taking it. One trigger, one decision, one message. Reminders came later, and mattered less.
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.
Our automation and AI integration service can facilitate this mapping before any platform or build is selected.
Quick automation process map action plan
- Start with one work trigger. Write down the result. Name one owner.
- Write each step in plain words. Test this step. Keep proof of the test.
- Name who owns every choice. Use real data. Check each fact.
- Mark each system handoff. Ask one user. Note what feels hard.
- Show the happy path first. Fix each fault. Run the check again.
- Add common failure routes. Set a due date. Review the result.
- Check the map with real staff. Write down the result. Name one owner.
- Update it after each change. Test this step. Keep proof of the test.
- Choose one clear goal. Use real data. Check each fact.
- Name the owner for each task. Ask one user. Note what feels hard.
- Test the full path before launch. Fix each fault. Run the check again.
- Set the next review date. Set a due date. Review the result.
- Keep the plan where staff can find it. Write down the result. Name one owner.
- Use plain words in each note. Test this step. Keep proof of the test.
- Save proof for each key check. Use real data. Check each fact.
- Fix one issue at a time. Ask one user. Note what feels hard.
- Check the result with a real user. Fix each fault. Run the check again.
- Remove work that does not help the goal. Set a due date. Review the result.
- Share each major change with the team. Write down the result. Name one owner.
- Run the same checks after each update. Test this step. Keep proof of the test.
- Check the source of every key fact. Use real data. Check each fact.
- Keep private data out of public notes. Ask one user. Note what feels hard.
- Plan what to do when a check fails. Fix each fault. Run the check again.
- Give each choice a clear reason. Set a due date. Review the result.
- Keep old files until new work is proven. Write down the result. Name one owner.
- Ask for help when the risk is high. Test this step. Keep proof of the test.
- Check phone and desktop views. Use real data. Check each fact.
- Make the next step easy to find. Ask one user. Note what feels hard.
- Track the result that matters most. Fix each fault. Run the check again.
- Close each task when proof is saved. Set a due date. Review the result.
Use this automation process map plan as a live check. Keep the notes short. Review the work after each major change.
