How to map a process with the people who actually do it

Why map the process with the people who do it?

Every business process exists three times. There is the one in the procedure manual, the one the manager describes, and the one that happens. They drift apart from the day the manual is written. Automate the first or the second and the AI meets the third on its first day in production.

The people doing the work know the exceptions, the workarounds and the spreadsheet. They know which step is theatre and which one saves the customer. They are also the people who have to live with whatever changes. A map they drew is a map they will defend and keep fixing. A map done to them is one they will quietly route around.

Who should be in the room?

• One person for each step, including the teams on either side of a handoff. If sales hands to onboarding, both are in the room.
• Four to six people. More than eight and it becomes a meeting.
• A facilitator who does not do the work and has no stake in the answer. Their job is to keep asking "and then what?" and to stop the room solving things.
• Not the vendor, and not anyone who assesses the performance of the people in the room. The process owner joins the playback, not the mapping. Say this out loud at the start, so people describe what they do rather than what they are supposed to do.

How do you run the session?

Ninety minutes, a wall or a shared online whiteboard, and a pad of sticky notes. In sequence:

1. 1Pick one real, recent case. A specific application, claim or order, with its reference number. Not "a typical case". There is no such thing, and the room will argue about it instead of describing what happened.
2. 2Start at the trigger. What arrived, from whom, through which channel, and who saw it first. That is the first card on the wall.
3. 3One step per card. Who does it, in which system, what they need before they can start and what they hand on. Keep asking "and then what happens?" until the case reaches its outcome.
4. 4Capture the waiting. Between every two cards, ask how long the case usually sits. Write it on the arrow. Most of the elapsed time in a process is here, not inside the steps.
5. 5Ask "what happens when?" Information is missing. Two records do not match. The customer does not reply. Each answer is a branch. Draw it, however roughly. The branches are where the workarounds live.
6. 6Mark the pain. Each person puts a red dot on the steps they would get rid of if they could, with a few words on why. Do not debate the dots yet.
7. 7Park the solutions. When someone says "we should just…", write it on a separate list and move on. The session is for understanding. Solutions come after the map is checked.
8. 8Close with the three worst points and the number. Ask the room: if this process were working well, what would be different, and how would we know? The answer is the measure you will baseline.

What should you record for each step?

The wall gives you the shape. A spreadsheet, filled in during or straight after the session, gives you the detail. One row per step, with these columns:

• Step and owner. What is done and by which role.
• System. Where it is done, including email, spreadsheets and paper.
• Input and output. What is needed to start, and what is handed on.
• Touch time. How long the step takes when someone is actually working on it.
• Wait time. How long the case sits before this step starts.
• Volume. How many a day or week, and how it varies.
• Exceptions. What goes wrong here, how often, and what people do about it.
• Decisions. Who decides what at this step, and on what rule.
• Personal information. What information about people is read, entered or changed.
• AI or automation already involved. Any tool, feature or rule that does part of the step on its own.

The last two columns are why the map is also governance evidence. They feed your AI register, and they tell you which steps the Privacy Act's automated decision rulesmay apply to from 10 December 2026. You get that for the cost of two extra questions per step.

How do you check the map is true?

The room will be honest and still wrong, mostly about time. People remember the work and forget the waiting. So go and see. Sit with two or three people as they handle two more real cases, and note where what happens differs from the wall.

Then pull the system timestamps for twenty recent cases: when each arrived, when it reached each stage, when it finished. Compare the elapsed times with what the room said. The waits are nearly always longer than anyone thought. Update the map.

Finally, play it back to the team and the process owner in thirty minutes. Frame it as "this is what we found", not "this is what is wrong". Ask them what we missed. Then it is their map.

What do you do with it?

Three things, in order. Record the baseline for the number the room chose: hours per case, days from trigger to outcome, errors, complaints, whatever proves the outcome. Pick the one point most worth fixing. It is usually a wait or a rework loop, and not always the step with the most red dots. Then decide what to remove, what to consolidate and who owns the outcome before you ask where AI fits.

That order matters. Our guide on why automating a broken process makes it worse explains what happens when it is skipped.

What are the common mistakes?

• Mapping the ideal process. If the map has no branches, it is the manual, not the work.
• Letting the manager narrate. The room goes quiet and you get the design, not the reality.
• Mapping everything. One process, one case. The map of the whole business is never finished.
• Skipping the waits. A map of steps without waits will tell you to speed up the wrong thing.
• Buying mapping software first. Run the session with sticky notes. Buy a tool when you have a map worth keeping.
• Treating the map as the deliverable. It is the input. The deliverable is the number that moves.

Frequently asked questions