Process Mapping 101
Documenting a Workflow as It Actually Happens
Before you can improve or automate a process, you need an honest picture of what it actually is — not the clean version in the employee handbook, but the real one, including the workaround nobody wrote down.
What a Process Map Is
A process map is a simple visual sequence of the steps a task goes through, from trigger to completion, including who does each step and where decisions or handoffs happen. It doesn't need software. A whiteboard, sticky notes, or a sheet of paper works fine to start.
The Critical Rule: Map the Reality, Not the Design
The single most common mistake is mapping what the process is supposed to be, from memory or from a manual — instead of what people actually do. The real process almost always includes extra steps that exist for a reason nobody ever documented: a double-check that was added after a specific mistake, an email to "just confirm with Bob," a spreadsheet that exists because the official system doesn't do something it needs to.
Those extra steps are not noise to clean up before mapping — they're the most valuable thing the map can capture. If you skip them, you'll build a solution for a process that doesn't actually exist.How to Map It
1. Pick one process with a clear start and end. Start narrow — "how a customer refund gets processed" is mappable in one sitting. "How we handle customers" is not. 2. Map it with the person who does it — not alone, and not just from what a manager assumes happens. The person doing the work daily knows the exceptions, the workarounds, and the parts they've never mentioned because "that's just how it works." 3. Walk through it step by step, out loud, in order. For each step, capture:- What happens (the action) - Who does it (the role, not just "someone") - What triggers it to start - What's needed to complete it (information, a tool, an approval) - Where it goes next — including if it goes somewhere different depending on a decision
4. Use a simple, consistent shape system so anyone can read the map later:- Oval = start or end point - Rectangle = a process step (an action someone takes) - Diamond = a decision point (the path splits based on an answer) - Arrow crossing a dotted line = a handoff to a different person or team
5. Capture wait time, not just action time. "Then it sits in an inbox for two days" is a real and often invisible part of the process — and often where the biggest improvement opportunity is hiding. 6. Write down every workaround exactly as it happens, even the ones that feel embarrassing or inefficient to say out loud. "We're not supposed to do this, but..." is the most useful sentence in the whole exercise.Common Mistakes to Avoid
- Mapping alone, from assumption. A manager's mental model of a process is rarely the same as the version their team actually runs day to day. - Mapping the manual instead of the behavior. If there's an official SOP, use it as a reference — not as a substitute for watching or discussing the real thing. - Treating exceptions as "edge cases to ignore for now." If an exception happens often enough to be routine, it's not an edge case — it's part of the process. - Stopping at the first "normal" path. Most real processes have at least one decision point. Map both branches, even if one is rare.
What to Do With the Finished Map
Once you have an honest map, two things become possible that weren't before: you can spot where time and effort are actually being lost (see "Spotting Process Drag" in this Resource Centre), and you have the raw material to turn into a real, usable procedure — see "Documenting a Process So Someone Else Could Run It," the companion template to this guide.
---
Want help mapping a specific process with your team? A facilitated mapping session often surfaces things nobody had said out loud before. Book a free consultation →