Business Process Map Builder
Trace the work, the owners and the waits between teams.
Map current workflows, expose handoff gaps and distinguish working time from waiting.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are a process analyst mapping a business process end to end before any change is proposed.
Context:
- Process name and what triggers it: {{process_and_trigger}}
- Where it ends and what the finished output is: {{end_state}}
- Teams, roles and external parties involved: {{actors}}
- Systems and tools it passes through: {{systems}}
- Rough narrative of how it runs today: {{narrative}}
- Anything already known to be slow or contested: {{pain_points}}
Task: Return the map in four layers.
1. Swimlane list: each actor, and the steps they own in sequence.
2. Step table: step, actor, system, input, output, typical working time, typical waiting time before it starts.
3. Handoffs: every point where work changes hands, what is transferred, and how the receiver knows it has arrived.
4. Decision branches: condition, branches, who decides, and the rough share of volume down each branch.
Then analyse:
- Steps with no named owner, or with two owners.
- Handoffs that rely on someone noticing rather than a triggered notification.
- Rework loops: any point where work returns to an earlier step, and what causes it.
- Total working time versus total elapsed time, and where the gap sits.
Rules:
- Describe the process as it actually runs, not as policy says it should. Note both when they differ.
- Do not propose improvements in this output. Mapping and redesign are separate passes.
- Mark any timing you inferred rather than were given as ESTIMATED.
Finish with: the five questions you would need answered to make this map accurate enough to act on.Estimated results
Editor's note
Why this prompt matters
A request can look complete in one team's queue while the next team is still waiting for an attachment, approval or notification. A process map that records only tasks misses that gap. This prompt connects each activity to its owner, system, incoming information and outgoing handoff, so you can distinguish slow execution from work that has not started.
Start with a bounded process: one trigger, one finished output and the people who move work between them. Populate {{narrative}} with what happened on recent cases, including workarounds and returns for missing information. Use {{pain_points}} for disputed ownership or suspected delays, not predetermined solutions.
The result is a current-state map for validation with the people doing the work. It is not a redesign or a verified time study. Its value is making disagreements visible before an automation brief or staffing decision turns an incomplete account into an operating assumption.
Anatomy
Prompt engineering breakdown
Role
Current-state analyst, not redesign adviser.
Context
Boundaries, participants, systems and observed behavior.
Goal
A cross-team map ready for validation.
Constraints
Separate policy, observation and inference.
Output format
Four map layers, analysis and five questions.
Why this structure works
Cross-checks ownership, flow and timing.
What you'll get
Expected output
Worked example: supplier setup
Consider an illustrative process triggered by a purchasing request and ending when a supplier record is active. Purchasing submits details, finance checks them, and a systems administrator creates the record. The supplied narrative says incomplete requests return to purchasing; finance discovers new requests by checking a shared folder.
Four connected layers
The swimlane list assigns submission and correction to purchasing, validation to finance, and record creation to the administrator. Stable step IDs should connect these lanes to the table and handoff list.
| Step | Actor / system | Input → output | Work | Wait before start | |---|---|---|---|---| | S1 Submit | Purchasing / form | Details → request | 10 min | Unknown | | S2 Validate | Finance / folder | Request → approval or return | 20 min | 1 business day | | S3 Create | Administrator / supplier system | Approval → active record | 15 min | 2 business hours |
These are fictional example inputs, not benchmarks. In a real map, unsupported inferred durations must be marked ESTIMATED; unavailable durations can remain unknown.
The handoff list identifies the request packet, its folder destination and finance's manual checking routine. It also asks how the administrator receives approval rather than inventing an alert.
The decision branch is “details complete?” Finance decides; incomplete requests loop to purchasing. Branch shares remain unknown unless supplied or supported by records.
Bottleneck read and validation
This path contains 45 minutes of stated working time, but elapsed time remains incomplete because the initial wait and rework frequency are unknown. Keep business time separate from calendar time.
The closing five questions should resolve initial waiting, folder-check frequency, approval notification, return frequency and ownership during corrections. These clarify evidence gaps without prescribing fixes.
Under the hood
Why this prompt works
The Role anchors the model as an analyst documenting reality, not a consultant proposing changes. Context supplies boundaries through {{process_and_trigger}} and {{end_state}}, then gives {{actors}}, {{systems}} and {{narrative}} enough detail to trace work across organizational and technical boundaries. Without those boundaries, maps easily expand into adjacent processes or stop before the output is usable.
The Task requests four complementary views. Swimlanes expose responsibility; the table separates activity from delay; handoffs test whether transfer actually reaches a receiver; branches prevent exceptions from disappearing into a misleading straight line. Comparing these views can reveal an owner named in one place but absent elsewhere.
The Rules protect the evidence: actual practice stays distinct from policy, inferred timings remain visible, and recommendations wait. The final five questions turn uncertainty into a focused validation agenda rather than disguising missing information as completeness.
Model fit
Best AI models for this prompt
ChatGPT
Use it for linked tables and step IDs. Check that every handoff references an existing step.
Claude
The primary choice here for synthesizing cross-team narratives. Reinforce the no-redesign boundary when notes contain proposed fixes.
Gemini
Useful when supplying ticket exports alongside interviews. Ask it to distinguish timestamp evidence from descriptions of typical timing.
Grok
Use it to surface contradictions in informal process accounts. Require neutral wording and unknown labels instead of confident assumptions.
When to use
- Before scoping workflow automation.
- During cross-team ownership disputes.
- When requests stall between queues.
- Before an outsourcing handover.
When not to use
- Single-person tasks needing an SOP.
- Live queue monitoring requiring integrations.
- Compliance sign-off requiring qualified review.
- Timing claims without supporting records.
Get more from it
Pro tips
- 1
Define one trigger and one endpoint.
- 2
Include a recent failed case.
- 3
Name roles, not individual employees.
- 4
Label business versus calendar time.
- 5
Separate parallel paths before summing durations.
- 6
Validate handoffs with both teams.
Don't ship this
Common mistakes
✗ Treating shared access as notification.
Fix — Specify how receivers discover arrivals.
✗ Assigning invented branch percentages.
Fix — Use unknown until records support estimates.
People also ask
Frequently asked questions
Q.Why separate working time from waiting time?
Because they have different fixes. Working time responds to training, tooling and templates; waiting time responds to notifications, batching and ownership. In most processes waiting is the larger number and nobody measures it.
Q.Should I map the process as documented or as it actually happens?
As it actually happens, and note where policy differs. A map of the intended process hides the workarounds people invented, and those workarounds are usually where both the delay and the risk live.
Q.Why does the prompt refuse to suggest improvements?
Because a model allowed to propose fixes mid-map starts describing the process it would prefer. Keeping mapping and redesign separate keeps the current-state picture honest, then the optimisation prompt works from it.