01 / UNDERSTAND
What is process mapping?
Process mapping represents activities, decisions and connections from a trigger to an outcome. A flowchart is one common form; lanes can show which role acts. The question is how work actually moves, including what happens when information is missing.
A process map describes operational flow. A Customer Journey Map follows a person’s experience, while a Service Blueprint connects experience with delivery. These complementary views make different claims.
Why use Process Mapping?
Teams can agree on activity names while disagreeing about what starts them, what counts as complete and who receives the result. Mapping makes those differences discussable and reveals repeated checking, invisible waiting and requests that circle back.
The value comes from checking the diagram against real work. A procedure manual can conceal informal coordination. Use the map to locate questions, then investigate what causes a delay.
When to use it
USE IT WHEN
A repeated service or administrative process has unclear handovers or recurring rework.
A proposed change affects several roles and the team needs a common operational picture.
People disagree about where a process begins, ends or branches.
When to choose another method
Use SIPOC Diagram first when suppliers, inputs and the process boundary are still uncertain.
Use Service Blueprint when you also need to connect delivery work with customer touchpoints.
Use RACI Matrix after mapping when the main uncertainty concerns responsibility and authority.
What you’ll need
Choose a meaningful start and end condition. Invite people from different stages, including someone who handles exceptions. Bring recent case records or observations with confidential details removed. Date the map and label it as current practice or a proposed arrangement. A shared board, simple shapes and a visible legend are sufficient.
What a process map needs
Keep the elements that help answer your question and support a decision.
The trigger that starts the process and the condition that finishes it.
Observable actions written with a verb and a concrete object.
Questions with labelled routes for each relevant answer.
The people or teams that perform activities and receive handovers.
Missing information, unsuccessful outcomes and routes that return to earlier work.
Case references, observations and unresolved differences supporting the diagram.
02 / PUT IT INTO PRACTICE
How to map a process
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Define the case
Name the process, its purpose and its start and end conditions. Pick a representative case to trace so the discussion stays concrete.
Trace one request through to recorded return.
02
List the actions
Ask each role what they do, receive and pass on. Write one observable activity per note. Start with the broad flow before expanding complicated sections.
Separate checking stock from reserving an item.
03
Connect the sequence
Arrange activities and draw directional arrows. Add lanes if ownership or handovers matter. Follow the same level of detail across comparable branches.
Show the handover from desk to storekeeper.
04
Expose the branches
Write decisions as questions and label their outgoing routes. Add cancellation, rejection and missing information where they affect the outcome.
Show both available and unavailable routes.
05
Mark waiting and evidence
Distinguish active work from queues and pending responses. Add measured timings only where evidence exists; label estimates and unknowns.
Waiting for payment differs from verifying it.
06
Walk actual cases
Trace recent cases with people who performed the work. Include an exception case. Mark disagreement and update the map rather than forcing premature consensus.
Include direct calls omitted from the formal procedure.
07
Choose an investigation
Select one consequential delay, loop or handover. State a question, the evidence needed and an owner. Sketch a proposed flow only after the current one is understood.
Check stock before confirming a collection slot.
Example: borrowing equipment from a community workshop
Fictional scenario: a community workshop lends tools to members. The team initially draws request, confirm, collect and return. Tracing an invented request reveals more work: the booking desk checks membership, confirms a slot, and asks the storekeeper to prepare the tool. The storekeeper sometimes discovers that the tool is still awaiting inspection.
The map adds a decision about inspection status and a loop back to the borrower when a substitute is needed. It also distinguishes collection from completing the loan record. That distinction matters because a collected tool can still appear available in the booking system.
The team would test a readiness check before confirming a collection slot and define who updates the record at handover. It would observe whether that change reduces avoidable rearrangement while preserving inspection. These events are invented to explain the method, not results from a workshop study.
03 / BELOW THE SURFACE
Below the surface: a removable step may be a coordination buffer
Making a flow shorter does not necessarily make the service more dependable.
FLOW
What starts the next activity?
Name the information, object or permission that must arrive.
EXCEPTION
Where does an unsuccessful case go?
Trace rejection and recovery as carefully as success.
PROTECTION
What does this extra step prevent?
Check what would replace its coordinating function.
An extra check or wait can look wasteful while quietly absorbing variation elsewhere. Removing a confirmation call may save staff effort but leave the borrower to discover an unavailable item after travelling. Locate the uncertainty a step absorbs before recommending its removal.
For a contested activity, record what it prevents, who benefits and what would replace that protection. Some checks genuinely duplicate work; others compensate for unreliable information or unclear authority. A map alone cannot distinguish them. Compare case evidence and ask the people who perform recovery work.
The editorial extension in this guide is a simple protection question beside proposed deletions: what failure becomes possible if this step disappears? Improve the whole outcome, including effort transferred to another role, rather than optimising the number of boxes on the page.
Process Mapping companion worksheet
The original two page Design Iceberg companion worksheet records boundaries, flow and handovers on page one. Page two reviews exceptions, evidence and proposed changes. Use a larger board when needed.
Practical tips
Write observable actions, such as verify membership or release item.
Review a real case and assign someone to check unknown routes.
Common mistakes
Mapping only the official procedure and excluding the work people use to make it succeed.
Combining current and proposed activities without identifying which is which.
Treating every handover or checking step as unnecessary before examining its purpose.
What you’ll get
A useful process map establishes an agreed account of the flow, with visible exceptions and limits to its evidence. Carry one improvement question into observation or a bounded trial, with a named owner and a way to assess the entire outcome.