Process Mapping Guide
How to map the process that actually happens, not the one everyone describes. The gap between them is where the money goes.
The process you describe and the process you run are different. Mapping is how you find out by how much.
Every business has a stated procedure and an actual one. The stated version is tidy, linear, and what gets explained to new hires. The actual version contains the workarounds, the exceptions, and the three things someone does out of habit that nobody has questioned in two years.
You can only improve the second one.
Try the Process Mapper · Request Your Free Systems Audit
The rule that governs everything else
If you have one source, you have the stated version.
Asking the owner how a process works gives you an org chart of intentions. Watching it happen gives you the process. Checking it against real data gives you the truth.
Use all three, in that order, and treat the disagreements as information rather than noise.
Step 1 — Find the real executor
Not the person who owns the process. The person who does it most often.
Ask: "Who does this the most?" That's who you map with. A manager describing a process they supervise will give you the stated version in good faith.
Step 2 — Ask for a demonstration, not a description
"Walk me through how you do this" produces a summary. "Show me the last three you did, on your screen" produces the process.
Record it if they're comfortable. You will miss things in the moment.
Step 3 — Take notes in four columns
While watching, keep these separate:
| What they do | What they say they do | Where they hesitate | Where they say "depends" |
|---|
The first two columns diverging is normal and useful — it's not dishonesty, it's that nobody narrates their own habits accurately.
The third column marks friction: a lookup, a decision, a thing they have to remember.
The fourth is the most valuable thing on the page.
Step 4 — Chase every "it depends"
Every time someone says "it depends," "usually," or "normally," stop and ask:
"What makes you choose one or the other?"
Then write the condition down in their words.
These are undocumented decision rules. They live in one person's head, they're the reason the process can't be delegated, and they're the reason it can't be automated. A map that leaves them as "depends" hasn't finished.
Step 5 — Walk three real cases
Ask for three recent cases, and insist that at least one went wrong.
Go through each in the actual data — the orders, the messages, the records — not from memory. Memory reconstructs processes as they should have gone.
The failed case is worth more than the other two combined. It shows you where the process has no path.
Step 6 — Mark every handoff
A handoff is any point where work passes from one person or system to another. These are where things get lost.
For each one, note three things: what gets transferred, through which channel, and what happens if it doesn't arrive.
The third question usually has no answer. That's the finding.
Step 7 — Get the numbers
For each step: how long it takes, how often it runs, who does it.
Estimates are fine. Mark them as estimates. A documented estimate beats an undocumented certainty, and you need a baseline to compare against later.
Step 8 — Write the map
Text, not diagrams. A diagram looks more professional and is harder to correct, which means people nod at it instead of fixing it.
TRIGGER: what starts this
STEP 1 — [who] [does what] [in which tool] [how long]
DECISION: [condition] → branch A | branch B
STEP 2 — ...
EXCEPTION: [when] → [what happens instead]
OUTPUT: what results, where it goes
OBSERVED FAILURE POINTS
- [what breaks] [how often] [what it costs]
GAPS
- [what I could not confirm]
The gaps section is mandatory. A map with no gaps is a map that stopped asking questions.
Step 9 — Get it confirmed
Send the map to the person who does the work and ask them to mark what's wrong. Not "does this look right" — that gets you a yes.
An unconfirmed map is not a basis for changing anything.
When it's confirmed, mark it: confirmed on [date] by [name].
What to look for once you have it
Steps nobody can justify. "We've always done it that way" means the reason is gone and the step may be too.
Decisions with no rule. Every one is a delegation blocker.
Handoffs with no failure path. Each is a place where work goes quiet.
Duplicate data entry. The same information typed into two systems is both a time cost and a source of disagreement between them.
Waiting time. Often larger than all the working time combined, and usually invisible until mapped.
The step everyone works around. If three people have a personal workaround, the official step is broken.
Common mistakes
Mapping too much at once. Over fifteen steps, you have more than one process. Split it and map the one with the highest volume.
Mapping the ideal. If you catch yourself writing what should happen, stop. The improvement comes later and it needs a real starting point.
Skipping the failed case. It's the uncomfortable one to ask for and the most informative one to get.
Mapping alone. A map built from interviews without observation is a map of what people believe.
How long it takes
A single process, mapped properly: two to four hours of your time, plus about ninety minutes of the executor's.
The confirmation round adds a day of waiting. Build that in — rushing confirmation to save a day is how you end up redesigning around a mistake.
Map what happens, not what's supposed to happen. The difference between them is the opportunity.
Want the map done for you?
A free systems audit includes mapping your highest-volume process and showing you where it leaks.