How is a process map different from a swimlane diagram or flowchart tool?

It's the content those diagrams are drawn from, produced faster and in plain text — the ordered steps, the roles, the handoffs, and the pain points, extracted from real interviews rather than assumed from a policy doc. Once you have process-map.md, turning it into a visual swimlane in your diagramming tool of choice is a fast, mechanical step; skipping the extraction and diagramming straight from memory is how flowcharts end up describing a process nobody actually follows.

What if the interview and the actual system export disagree?

That's exactly what the cross-check step is for — flag the discrepancy explicitly and resolve it with the people involved rather than letting Claude average the two versions or default to whichever sounds more current. A process map that silently picked a side is worse than one that honestly flags 'we don't know which is current yet.'

Do I need to interview every single person in the process?

No, but you need at least one source per role that touches the process, plus a second source overall to cross-check the sequence — one person's walkthrough is one seat's view. The two- or three-source minimum is what turns 'how Sarah thinks it works' into an as-is map the rest of the team can trust.

How detailed should the step sequence be?

Detailed enough that someone unfamiliar with the process could follow it end to end and know who does what next — but not so granular it includes every click. A good test: if a pain point can't be pinned to a specific step, the map is either too coarse (steps are hiding sub-steps) or the pain point needs a clearer source.

Turn interview notes into a clear as-is process map

when to reach for this

A process that everyone follows from memory is a process nobody can actually agree on — ask five people to describe how an invoice gets approved and you'll get five different answers, each confident and each incomplete. The fix is an as-is process map: the real sequence of steps, who does each one, the handoffs between roles, and exactly where it breaks down or stalls, built from what people actually said and showed rather than how the process is supposed to work on paper. This is what makes a gap analysis or a redesign start from reality instead of an idealized flowchart nobody follows.

gather this first

Your interview notes or a transcript of a process walkthrough — someone talking through 'here's what I actually do' is far more useful than a policy document describing what's supposed to happen.
Any screenshots, screen recordings, or exported reports from the systems involved, dropped into the folder you open in Claude Desktop — these anchor vague descriptions ('then I check the system') to something concrete.
A rough idea of where the process starts and ends, so the map has a clear boundary — e.g. 'from invoice received to payment released', not an open-ended everything-that-touches-finance.

the workflow

Extract the raw step sequence — before naming pain points

Open the folder with your notes, screenshots, and transcripts in Claude Desktop and ask in the chat — no terminal needed. Get the literal sequence of what happens first, in order, before judging any of it. Naming problems too early skips steps nobody thought to mention because they seemed obvious.

you ask

Read this walkthrough transcript and the screenshots. Extract the process as a literal, ordered step-by-step sequence: what happens first, then what, then what, ending when [end point]. For each step, note who performs it (by role, not just system) and what triggers it moving to the next step. Don't flag problems yet — just get the honest sequence, including any step that seems redundant or manual.

what you get back A plain numbered sequence — "1. Invoice arrives by email to AP clerk. 2. AP clerk manually re-keys into the finance system. 3. System routes to manager for approval if over $1,000..." — with a role attached to every step.

Resist tidying the sequence as you extract it. The clumsy, manual step you're tempted to smooth over is often the exact pain point step three is designed to surface.
Map the handoffs and where responsibility actually changes hands

A process breaks most often at the seams between people, not inside a single person's steps. Make every handoff explicit: who passes what to whom, and how they know it's their turn.

you ask

Go through the step sequence and mark every handoff — where the work moves from one role or system to another. For each handoff, note what's actually transferred (a document, a notification, a verbal ask) and how the receiving person knows it's now theirs to act on. Flag any handoff where that trigger is unclear or informal (e.g. 'they just know to check').

what you get back The same sequence with handoff points marked and annotated — "Handoff: AP clerk → Manager. Trigger: an email notification from the finance system. Flagged: no reminder if the manager doesn't open it for days."

An informal handoff trigger — 'they just know', 'someone usually mentions it' — is exactly the kind of gap that causes delays nobody can point to a single cause for.
Flag the pain points and breakdowns inline

Now, and only now, name what's actually broken — where the process stalls, where rework happens, where someone works around the system instead of through it. Attach each pain point to the specific step it lives in.

you ask

Go back through the mapped sequence and flag every pain point directly on the step it belongs to: where the process stalls or waits, where rework or double-entry happens, where someone described a manual workaround, and where the same request seems to bounce back and forth. For each, note who mentioned it and what they said the impact was (time lost, errors, frustration).

what you get back The sequence with inline pain-point flags — "Step 2 [PAIN POINT]: manual re-keying, AP clerk estimates 2 errors/week; Step 3 [PAIN POINT]: approvals sit an average of 3 days because there's no escalation if the manager is out" — grounded in what people actually reported, not inferred.
Check the map against a second source

One person's walkthrough is one person's view of the process. Before calling the map final, cross-check it against a second interview, a screenshot trail, or an exported system log to catch what one telling missed or misremembered.

you ask

Here's a second interview transcript / system export covering the same process. Compare it against the mapped sequence and flag any step, role, or handoff that's described differently, missing, or contradicted — don't silently merge the two into one version. List every discrepancy so I can resolve it with the actual people involved.

what you get back A discrepancy list — "First interview says approvals route to the Finance Manager; the export shows some routing to the Controller instead — confirm which is current" — each one a real conflict to resolve with a person, not something to average or guess.

Never let a discrepancy get silently reconciled by Claude picking whichever version sounds more likely. That's exactly the kind of plausible-but-unconfirmed detail that undermines the whole map.
Assemble the process-map.md

Pull the finished, cross-checked map into one canonical file: the step sequence, the roles, the handoffs, and the pain points, in a format readable by someone who's never seen the process. This is what a gap analysis or a redesign starts from.

you ask

Assemble everything into one process-map.md: the ordered step sequence with roles, the handoff points with their triggers, and the pain points flagged inline at the step they belong to. Add a short 'process boundary' note at the top (start point, end point, what's out of scope) and a one-line summary of the two or three biggest pain points. Keep it scannable — someone unfamiliar with the process should be able to follow it top to bottom.

what you get back A single, paste-ready process-map.md — the as-is process in plain sequence, with roles, handoffs, and pain points all in one place — ready to hand to whoever runs the gap analysis or designs the to-be process.

Save this file alongside requirements.md. The pain points flagged here are frequently exactly the non-functional requirements or scope items that got missed in the interviews.

make it your own

Feeds the gap analysis: hand process-map.md straight into the stage-2 gap analysis — it measures the to-be design against these exact steps and pain points, so the gaps are grounded in a documented as-is, not memory.
Cross-reference the requirements doc: a pain point flagged here ("approvals sit 3 days with no escalation") often becomes a non-functional requirement or an open question in requirements.md — reconcile the two rather than letting them diverge.
Re-map after a reorg or a system change: a process map is a snapshot — re-run this when roles, systems, or the steps themselves genuinely change, rather than trusting an old map that quietly no longer matches reality.
Make it a reusable skill (Power Track): load the process-mapping prompt sequence as a skill or a /asis command so every new process gets the same disciplined extract-then-flag treatment (see the Features tab).

watch out for

A map built from one person's telling is one person's opinion, not the process. Cross-check against a second source before calling it final — the discrepancy step exists because the same process genuinely looks different from two seats.
Don't let Claude smooth over the messy, manual steps. A tidied-up version of the process that skips the workaround nobody's supposed to do is a map of the policy, not the reality — and the workaround is usually the pain point worth fixing.
A pain point with no one attached to it is an assumption, not a finding. Every flagged breakdown should trace to something a specific person actually said or a system actually showed — a plausible-sounding pain point Claude inferred is not the same as one reported by the people who live the process.
Don't silently reconcile a discrepancy between sources. If two interviews or an interview and a system export disagree, that disagreement is real information — resolve it with the people involved, not by picking whichever answer reads more confidently.

you'll end up with A single `process-map.md` — the as-is process as an ordered step sequence with roles, handoffs, and inline pain points, checked against a second source — that a gap analysis, a redesign, or a requirements doc can build from instead of relying on memory or an idealized policy description.

Questions people ask

How is a process map different from a swimlane diagram or flowchart tool?: It's the content those diagrams are drawn from, produced faster and in plain text — the ordered steps, the roles, the handoffs, and the pain points, extracted from real interviews rather than assumed from a policy doc. Once you have `process-map.md`, turning it into a visual swimlane in your diagramming tool of choice is a fast, mechanical step; skipping the extraction and diagramming straight from memory is how flowcharts end up describing a process nobody actually follows.
What if the interview and the actual system export disagree?: That's exactly what the cross-check step is for — flag the discrepancy explicitly and resolve it with the people involved rather than letting Claude average the two versions or default to whichever sounds more current. A process map that silently picked a side is worse than one that honestly flags 'we don't know which is current yet.'
Do I need to interview every single person in the process?: No, but you need at least one source per role that touches the process, plus a second source overall to cross-check the sequence — one person's walkthrough is one seat's view. The two- or three-source minimum is what turns 'how Sarah thinks it works' into an as-is map the rest of the team can trust.
How detailed should the step sequence be?: Detailed enough that someone unfamiliar with the process could follow it end to end and know who does what next — but not so granular it includes every click. A good test: if a pain point can't be pinned to a specific step, the map is either too coarse (steps are hiding sub-steps) or the pain point needs a clearer source.