A team is frustrated by a slow approval process. Emails are missed, documents are returned for correction and nobody can say exactly where requests are sitting. The proposed solution arrives quickly: buy a workflow tool, build an automated form or add AI.
That may help. But there is a catch.
If the team has not agreed on how the work happens today, automation can make the confusion move faster. An unnecessary approval becomes an automated unnecessary approval. Poor information reaches the next person sooner. Exceptions that used to be handled through a quick conversation become system errors.
Before choosing the technology, map the work.
Why This Matters
Most workplace processes are less tidy than their procedure documents suggest. Over time, people add checks, spreadsheets, workarounds and informal handoffs. Each addition may have made sense at the time, but the whole process becomes hard to see.
Process mapping brings the work into one shared view. It shows where a request starts, the steps it passes through, who performs them, where decisions occur and what counts as complete.
This is especially useful when work crosses teams. One person may understand the intake step, another the approval rules and someone else the final reporting. No individual sees every delay or repeated action.
The Australian Government’s Digital Service Standard puts people and business at the centre of service design. Its “Know your user” criterion encourages teams to observe real-world actions, identify pain points and map end-to-end journeys and behind-the-scenes processes. That is a useful principle beyond government: understand the actual experience before designing the solution.
Business process automation guidance commonly makes the same practical point: successful automation starts with understanding the workflow and selecting processes that are suitable for automation. Repetitive, high-volume, error-prone and compliance-critical activities can be good candidates, but only after the process is understood.
What a Useful Process Map Looks Like
You do not need specialist software or a perfect diagram. A whiteboard, sticky notes or a shared online board is enough.
A useful current-state map contains five things:
- A clear start and finish
- The main actions in the order they happen
- Decision points, such as approved or returned
- Handoffs between people or teams
- Visible friction, including waits, rework, duplication and unclear ownership
For cross-team work, use swim lanes. Give each role or team its own horizontal row, then place each action in the lane of the person responsible. The arrows between lanes make handoffs visible. This matters because delays often sit between steps rather than inside them.
The goal is not to document every mouse click. The goal is to create a shared picture that is detailed enough to expose the real problem.
A Practical 60-Minute Mapping Session
Step 1: Choose One Process and One Outcome — 5 Minutes
Pick a process with a clear trigger and result. “Improve onboarding” is too broad. “From receiving a completed starter form to confirming system access” is easier to map.
Write one outcome at the top of the board: “A new team member has the access needed for their first day.”
Keep the scope narrow. A smaller map that leads to action is more valuable than a huge map that nobody finishes.
Step 2: Bring in the People Who Do the Work — Before the Session
Include representatives from the main roles involved, not only managers or system owners. People who perform the task know where information is missing, where work waits and which exceptions occur.
Atlassian’s workflow guidance recommends speaking with stakeholders who understand the current process, including how work is received and handed off. This helps uncover pain points that may not appear in formal procedures.
Aim for four to eight participants. If the process affects a service user or internal customer, include that perspective through a participant, recent feedback or a short journey summary.
Step 3: Map What Happens Now — 20 Minutes
Start with the trigger. Ask: “What happens next?”
Write one action per sticky note using a verb and a noun: “Check request”, “Correct missing details”, “Approve access” or “Notify requester”.
Do not map the official process from memory. Map what people actually do, including spreadsheets, inboxes, follow-up messages and workarounds.
Add decision points when the path can change. Mark the person or team responsible for each step. If participants disagree, capture both versions. Variation is useful evidence, not a facilitation failure.
Step 4: Mark the Friction — 10 Minutes
Review the map from start to finish and mark:
- Where work waits
- Where information is entered again
- Where requests return for correction
- Where ownership is unclear
- Where an approval adds little value
- Where a person must copy information between systems
- Where sensitive information is exposed unnecessarily
- Where exceptions depend on one experienced person
Use simple symbols or coloured dots. Avoid debating solutions yet. The purpose is to find where the process loses time, quality or trust.
Step 5: Find the Constraint — 10 Minutes
Ask the group: “If we improved only one point, which change would most improve the end-to-end result?”
Do not automatically choose the most annoying step. Look for the point that limits the whole flow. A five-minute manual task may not matter if work waits three days for incomplete information to be corrected.
Use available evidence: turnaround times, error counts, volumes, complaints or a small sample of recent cases. If no data exists, label the team’s view as a hypothesis to test.
Step 6: Design a Small Future-State Test — 10 Minutes
Now remove, combine, clarify or simplify before automating.
- Could an approval be replaced by a clear rule?
- Could required information be captured correctly at the start?
- Could two handoffs become one?
- Could the standard path be separated from genuine exceptions?
- Could a notification replace repeated checking?
- Could a template reduce variation?
Draw a simple future-state map. Then choose the smallest safe test. Trial a revised form with one team, test a clearer intake checklist for a week or automate one low-risk notification.
Step 7: Decide What to Measure — 5 Minutes
Record a baseline and one or two measures before the test. Useful measures include total turnaround time, time spent waiting, percentage returned for correction, number of handoffs and staff effort per request.
Also choose a guardrail. A faster process is not better if it creates more errors, reduces accessibility or weakens privacy and governance.
A Realistic Example
Imagine a service operations team handling requests for access to a reporting system. The formal process has four steps: submit, approve, configure and notify. The average request takes six working days, so the team proposes an automated approval workflow.
During mapping, the team discovers that approval is not the main delay. Almost half the requests arrive without the correct access level or cost-centre details. An administrator then emails the requester, waits for a reply and re-enters the information. The visible approval step takes only a few hours; the hidden rework causes most of the delay.
The team does not automate the existing form. It first adds clear access options, examples and mandatory fields. It tests the revised intake with one business unit for two weeks. Returned requests fall, and the team gains cleaner information for a later automation.
The map changed the question from “How do we automate approvals?” to “How do we get a complete request at the start?”
Common Mistakes and Risks
Mapping the ideal process instead of the current one. Start with reality, including awkward workarounds.
Inviting only leaders. Include people who perform, receive and support the work.
Blaming individuals. Focus on the system. Rework often signals unclear information, rules or ownership.
Adding too much detail. Begin at a high level, then expand only where the problem sits.
Automating every step. Remove unnecessary work before selecting technology.
Ignoring exceptions. Separate common exceptions from rare cases and decide which need human judgement.
Skipping privacy, security or accessibility. Identify what information moves, who can see it and who may be excluded by a digital-only path.
Treating the map as permanent. Work changes. Review the map after testing and when measures show new friction.
Try This This Week
Choose one recurring workflow that causes delays or repeated follow-up.
Book a 60-minute session with the people closest to the work.
Define the trigger, finish and desired outcome.
Map the current steps, decisions and handoffs.
Mark waits, rework, duplication, unclear ownership and risk.
Choose one constraint and one small change to test.
Record a baseline, an outcome measure and a guardrail.
Do not buy or build anything in the session. Finish with a clearer problem and a small experiment.
Key Takeaway
Automation works best when it supports a process that people understand and have deliberately designed. A simple workflow map helps a team see the real work, find the constraint and improve the process before technology makes it harder to change.
The most useful Monday-morning question may not be “What can we automate?” It may be “Can we all see how this work actually happens?”
For related practical workplace AI and reporting guidance, see Use AI Like a Project Brief and Turn Messy Project Updates into a Decision-Ready Status Report with AI.
Connect with Raf on LinkedIn or follow rafsanga.com for practical ideas on project delivery, workplace AI and continuous improvement.
AI disclosure: AI tools assisted with research and drafting. The final article was reviewed and approved by the author.
Comments
Post a Comment