Before you start
Process mapping is not a theoretical exercise. It is a practical skill you learn by doing. This guide walks you through mapping a real process from start to finish. You can follow along with any process you know - how your team handles a request, how a new employee gets set up, how an order moves from intake to delivery.
You will need something to draw with. Sticky notes on a wall work. A whiteboard works. A digital tool like Crismo works. The method matters more than the tool.
Pick one process and define its boundaries
The most common mistake is trying to map everything at once. Start with one process. Define where it begins and where it ends.
Good scope
"How we onboard a new employee, from the moment they accept the offer to their first day being fully set up."
Too broad
"How HR works."
Write down three things before you draw anything:
- 1.Trigger - what kicks off the process? (An email arrives, a form is submitted, a date is reached.)
- 2.Outcome - what does "done" look like? (The employee is set up and working, the order is shipped, the complaint is resolved.)
- 3.Roles - who is involved? (HR, IT, the hiring manager, the new employee.)
Talk to the people who do the work
Do not map from memory. Do not map from a policy document. Talk to the people who actually execute the process every day.
Ask open-ended questions:
- -"Walk me through what happens when [trigger]. What do you do first?"
- -"Then what? Who gets it next?"
- -"What can go wrong at this step?"
- -"How do you know when this step is done?"
- -"Is there anything you do that is not in the official procedure?"
That last question is the most important one. The gap between the official process and the real process is where the most valuable insights live.
Draw the happy path
The happy path is the ideal scenario - everything goes right, no exceptions. Map this first. It gives you the backbone of the process.
For our onboarding example, the happy path is:
At this stage, do not worry about decisions, exceptions, or parallel paths. Just get the main sequence down. You will add complexity in the next step.
Add decisions, parallel work, and roles
Now enrich the happy path with reality:
- -Decisions - where does the process branch? In our example: what if the new hire does not sign the contract on time?
- -Parallel work - what can happen at the same time? IT sets up the laptop and accounts while the manager assigns a buddy. These do not need to happen in sequence.
- -Roles - who does each step? Put tasks in the right lane. HR sends the email, IT sets up the laptop, the manager assigns the buddy.
- -Handoffs - where does work move from one person to another? Each handoff is a potential point of delay or miscommunication.
If you are using BPMN, this is where the notation really helps. Parallel gateways (+) show concurrent work. Exclusive gateways (X) show decisions. Lanes show responsibilities. The diagram communicates all of this visually.
The finished map
Here is our onboarding process after adding parallel work and roles. Notice how HR, IT, and the Manager each have their own lane, and parallel gateways show where work happens simultaneously.
This diagram took about 15 minutes to build. It replaces pages of documentation and is immediately understandable by anyone in the organization.
Validate with everyone involved
Show the map to every person who touches the process. Ask:
- -"Does this match what actually happens?"
- -"Am I missing any steps?"
- -"Where does this process break down most often?"
This validation step almost always reveals surprises. Sales might discover that operations handles things differently than expected. HR might learn that IT has an unofficial workaround. These discoveries are the whole point of mapping.
Look for improvements
With a validated map in front of you, patterns become visible:
- -Bottlenecks - steps where everything waits on one person or one approval.
- -Redundancies - the same data being entered in two different systems.
- -Unnecessary handoffs - work bouncing between people when one person could handle it end-to-end.
- -Missing error handling - what happens when the new hire does not sign the contract? If nobody knows, that is a process gap.
- -Automation opportunities - manual steps that a system could handle (sending reminder emails, creating accounts, updating status).
Document these as annotations on the map or as a separate improvement list. Then prioritize: what is the highest-impact, lowest-effort change?
Practical tips
Keep it on one page
If your diagram does not fit on one screen, you are at the wrong level of detail. Break complex steps into sub-processes and map them separately.
Use verb-noun labels
Name tasks as actions: "Review application", "Send notification", "Approve request". Not "Application" or "Notification" - those are things, not steps.
Map the current state first
Resist the urge to design the ideal process immediately. Map how things work today (as-is), then create a separate diagram for how they should work (to-be).
Date your maps
Processes change. A map without a date is a map you cannot trust. Always note when it was created and when it was last validated.
Start mapping
You now have the method. Pick a process, grab a tool, and draw it out. The first map is always rough - that is fine. The value comes from making the invisible visible.
Frequently asked questions
How long does it take to map a process?▼
A simple process (5-10 steps, one role) takes 15-30 minutes. A cross-departmental process with decisions and exceptions takes 1-3 hours including interviews. The time investment pays back immediately in clarity.
Should I map the current process or the ideal process?▼
Always map the current state (as-is) first. You need to understand how things work today before you can design how they should work. Create a separate to-be diagram for the improved version.
How detailed should my process map be?▼
Detailed enough that someone unfamiliar with the process can follow it, but not so detailed that it becomes unreadable. If a step is complex, make it a collapsed sub-process and map the details in a separate diagram.
Who should be involved in process mapping?▼
The people who actually do the work. Always. Not just managers or process owners. The people on the ground know the real process, including the unofficial workarounds that make things actually function.
Do I need BPMN or is a simple flowchart enough?▼
For a quick internal sketch, a flowchart is fine. For anything that will be shared, maintained, or used as a basis for improvement or automation, use BPMN. It removes ambiguity and scales to complex processes.