Map the process people actually follow before automating the ideal version
Map a business process by recording the work people actually perform, from a defined trigger to an agreed finish. Include decisions, handovers, missing information and exceptions. Review the map with the people involved before designing automation around it.
Put the advice into practice
Build a workflow your team can actually rely on
Connect systems and follow-up with agreed rules, human review and exception handling.
Discuss your workflowAn ideal workflow diagram can look convincing while leaving out the calls, spreadsheets and informal checks that make the real process function. Those details are often where a new system needs the clearest decisions.
Choose a process small enough to examine
Write a start and finish that the team can recognise. “A service enquiry is accepted for assessment” and “the responsible person records the next decision” create a manageable boundary. “Improve the customer journey” is too broad to map usefully in one sequence.
Identify the people who perform the work and the people who receive its output. Include at least one person who understands the difficult cases. A manager’s description of how the process should work may differ from the steps colleagues use to complete it.
Record the current state without redesigning every step
ASQ’s flowchart guidance recommends defining scope, arranging activities in sequence and reviewing the result with people involved. For an automation brief, use the map to make the current work visible before agreeing a future process.
Use simple labels: an action, a decision and an output. Note the source of important information and the point at which another person takes responsibility. If a step depends on judgement, write the question the person is deciding rather than disguising it as a routine transfer.
Keep disputed points visible. “Finance confirms the exception rule” is a useful unresolved decision. A neat arrow that assumes an answer can conceal a problem the implementation team will otherwise inherit.
An illustrative enquiry-assessment map
| Stage | Information or decision | Possible gap |
|---|---|---|
| Enquiry received | Service requested and contact route | The message lacks enough context |
| Initial assessment | Whether the organisation provides the service | Several people use different suitability rules |
| Owner assigned | Who should respond | Ownership depends on who notices the message |
| Clarification requested | What information is missing | The question is not recorded with the enquiry |
| Next decision logged | Proceed, redirect or close | The final status remains in a private inbox |
This hypothetical example does not assume that every organisation needs the same process. Its purpose is to show the questions that a map can expose before a tool is asked to move records between systems.
Separate process improvements from automation opportunities
Review which steps can be removed, combined or clarified. A consistent assessment rule may solve more than a faster notification. A better brief may remove repeated clarification. A named owner may resolve a delay without another software connection.
Then identify tasks with reliable inputs and rules. Copying an approved reference, creating a draft record or notifying an agreed owner may be suitable candidates. Committing a service scope or resolving a commercial exception may require a person’s authority and context.
Use the automate, delegate or simplify guide to compare those options. A process map should help the business choose an improvement, not create an expectation that every box will become automated.
Walk through ordinary and difficult cases
Test the map against a normal example, an incomplete input, a duplicate and a changed instruction. Ask the people involved to explain what they would actually do. Update the map when it omits a necessary handover or assumes information that is unavailable.
Agree which version becomes the approved basis for the next stage. Name the process owner and record the remaining decisions. The implementation brief should identify the trigger, inputs, permitted actions, review points and finish, along with the exception route.
A useful map does not have to be visually elaborate. It needs to be accurate enough for the people doing the work and the people building the system to share the same understanding. That makes later design, testing and maintenance more straightforward.
