Process mapping

Every business has a hundred processes it runs on. Most of them live in people's heads. When someone leaves, the process leaves with them. Process mapping is how you extract them onto paper, and once they're on paper, they become something you can improve, automate, delegate, or eliminate.

Why map a process

• Make it improvable. You can't optimize something invisible.
• Make it transferable. New hire can pick it up without a month of shadowing.
• Make it automatable. Every automated process starts as a manually mapped one.
• Make it auditable. Regulators, customers, auditors all ask "show me how you do this" and deserve a real answer.

The level of detail

Processes get mapped at different levels. Pick the right one:

• Level 1 (Overview). End-to-end, 5–8 high-level steps. Good for onboarding executives to the business.
• Level 2 (Operational). Detailed enough that a trained operator could execute. 15–40 steps. Used for SOPs.
• Level 3 (Technical). Every click, every input field, every decision branch. For automation specs and systems of record changes.

Most process mapping exercises fail by aiming at Level 3 when Level 2 would've been enough. You get stuck in detail and lose the big picture.

The five elements of a mapped process

1. Trigger, what starts this process?
2. Steps, the actions, in order
3. Actors, who does each step (role, not person)
4. Decisions, branch points, with the criteria
5. Outputs, what this process produces

Mapping technique, the interview

The person doing the work maps the process. Not you. You facilitate:

1. "What starts this process?"
2. "What do you do first?"
3. "Then what?"
4. "What if X happens?" (decision branches)
5. "Who else touches this?" (handoffs)
6. "When is it done?"

Record on the fly. Don't pretty it up during the interview. A whiteboard or a Miro board beats a pre-built flowchart tool for first drafts.

What to look for, the improvement hunt

Once mapped, read the process with adversarial eyes:

• Unnecessary steps. "Why do we do this?" If the answer is "because we always have," investigate.
• Handoffs. Every handoff between people or systems is a delay point and an error point. Can you reduce handoffs?
• Loops + rework. Any step that often gets redone because the previous step was wrong.
• Approvals. Who actually needs to approve vs, who's listed as an approver? Unnecessary approvers add days.
• Manual transcription. Copying data from system A to system B. Almost always an integration opportunity.
• Tribal knowledge. Any step that "only Maria knows" is a single point of failure.

Swim lanes, when you need them

For processes with multiple roles, draw it as a swim-lane diagram:

                Lead arrives                         Prospect books meeting
 SDR    ────────[1. Enrich]────┐   ┌─────────────[4. Book]─────────┐
                               │   │                               │
Marketing ─[0. Campaign sent]──┘   │                               │
                                   │                               ▼
 AE                            [2. Contact]                  [5. Discovery]
                                   │                               │
RevOps                             └──[3. Assign]─────────────────┘

Swim lanes surface exactly where work crosses team lines. Those crossings are where processes break.

From map to SOP

A process map is the blueprint. The SOP is the instruction manual. Maps are visual; SOPs are step-by-step. You almost always want both for any process you plan to standardize.

What good looks like

• The 10 most-run processes in the business are mapped
• Maps are versioned and reviewed annually
• New hires receive relevant maps during onboarding
• Process improvements happen against the map, not instead of it

Related: SOPs · Automate vs hire · Vendor management