Processes Discovery
Process Mapping in Practice: A Step-by-Step Guide
Most process maps take weeks to build and end up in a shared folder nobody revisits. This framework gives you a structured method to map any process clearly and usefully in 30 minutes — no consulting team required.A process map is not a documentation exercise. It’s a clarity exercise. The goal isn’t a perfect diagram — it’s a shared understanding of how work actually flows, where decisions happen, and where things break. This framework is built for speed and usefulness, not completeness.
If you can’t answer all three clearly, the map will be built on a misunderstanding. Take the five minutes. It saves the other twenty-five.
- Trigger: What event or condition starts this process?
- Outcome: What does “done” look like? What is the end state?
- Roles: Who is involved? (roles, not names)
- Trigger: Client submits a loan application form
- Outcome: Loan approved or rejected, client notified
- Roles: Client, Relationship Manager, Credit Analyst, Compliance Officer
Teams define the scope too broadly — “the entire onboarding process” instead of “document collection during onboarding.” A map that covers too much covers nothing well. Narrow the scope until one person can walk it from trigger to outcome in under five minutes.
Get the people who actually do the work in a room or on a call. Not the manager who thinks they know the process — the people executing it daily. Ask them to walk you through it step by step, from trigger to outcome. Your only job at this stage is to listen and capture — not correct, not optimize, not challenge.
- What’s the first thing you do when this arrives?
- Who do you pass it to next, and how?
- What do you do if X happens instead of Y?
- Where do you typically have to wait for something?
- What’s the most common thing that goes wrong?
- Is there anything you do that isn’t written down anywhere?
- Capture what IS, not what SHOULD be
- Don’t suggest improvements yet — it shuts people down
- Include the workarounds — they’re the most important part
- Note every system, tool, or form touched
- Ask about exceptions — “what happens if it’s not standard?”
- One person facilitates, one person captures
- One swim lane per role — keep them horizontal
- Every task as a rectangle with the role who owns it
- Every decision as a diamond with Yes/No branches
- Every handoff as an arrow crossing swim lanes
- Every system or tool used noted on the relevant step
- The main path first — exceptions can be added after
- Timing and SLAs — add these in the gap analysis
- Improvement ideas — note them separately for now
- Every edge case — map the 80% path first
- Sub-process detail — one level of depth is enough
- Technology architecture — that’s a separate conversation
- Org chart information — roles only, not reporting lines
Once the flow is visible, the gaps become obvious. This is the most valuable five minutes of the exercise — and the one most teams skip because they’re in a hurry to “finish the map.” The map is not the deliverable. The gaps are the deliverable.
| Gap Type | What to look for | Why it matters | What it signals |
|---|---|---|---|
| Bottleneck | Steps where work consistently waits or piles up | Increases cycle time for every case that passes through | Capacity constraint or approval dependency |
| Handoff gap | Transitions between roles with no confirmation mechanism | Work falls through and nobody knows until it’s late | Missing ownership definition at the boundary |
| Knowledge dependency | Steps that only one person knows how to handle | Process stops when that person is unavailable | Undocumented institutional knowledge risk |
| Manual bridge | Steps that exist only to transfer data between systems | Error-prone, time-consuming, adds no judgment value | Automation candidate |
| Undefined exception | Non-standard cases with no documented path | Creates ad hoc escalation and inconsistent outcomes | Missing process design for 20%+ of real cases |
| Compliance gap | Steps with no audit trail or validation mechanism | Regulatory exposure when the process can’t be evidenced | Control design problem |
- Document the map in a shared, accessible format
- List the gaps identified with a named owner per gap
- Validate with the team — confirm it reflects reality
- Assign a process owner if one doesn’t exist
- Set a follow-up to review prioritized gaps within 2 weeks
- Use the gap analysis to identify automation candidates
- Resolve undefined exceptions before automating the main path
- Document the map as the baseline for the automation design
- Share with IT and compliance before tool selection
- Review the map again after 3 months — processes drift

