A process mapping workshop brings the people who perform a workflow together to describe what actually happens from a defined start to a defined finish. Its useful output is a shared current-state map, with decisions, handoffs, delays, and exceptions visible. An improvement proposal comes after participants check that the map matches real work.
A workshop can fail while producing an attractive diagram. If the map shows the process everyone wishes existed, it cannot explain why work gets stuck. Start with one recent case, include the people who handled it, and distinguish recorded facts from assumptions.
The ASQ flowchart guidance recommends defining boundaries, arranging activities, and walking through the result with people involved. The agenda below applies those principles to a team workshop. It is a suggested practice, not a formal certification method.
Choose a boundary that fits one meeting
“Map our delivery process” is too broad for a first session. “From a customer reporting a billing error to confirming the correction” gives participants a recognizable start and finish. Write the trigger and completed outcome in the invitation.
Choose a recent ordinary case and one meaningful exception. An ordinary case reveals the main path; an exception reveals a decision or loop that a tidy diagram might omit. Remove customer identifiers and other unnecessary personal information from the evidence you share.
Invite representatives who perform the work, including the person who receives the final output. A department head may know the intended process while a support specialist knows which spreadsheet makes it run. If a key role cannot attend, mark that part of the map as unverified rather than filling it with managerial assumptions.
A 75-minute process mapping agenda
| Minutes | Work | Deliverable |
|---|---|---|
| 0–10 | Confirm trigger, finish, and example case | Scope statement |
| 10–25 | Reconstruct the case in order | Actual activities |
| 25–40 | Add roles, decisions, and handoffs | Current-state map |
| 40–50 | Walk the case through the map | Corrections and missing branches |
| 50–65 | Mark waits, rework, and uncertainty | Evidence-backed problem list |
| 65–75 | Select one improvement to test | Owner, measure, and review date |
Keep activity labels concrete: “support checks invoice record,” rather than “triage.” A label should tell someone what happens, not merely name a stage. Use an arrow for sequence and a question for a decision. A process map does not need sophisticated notation to make missing ownership visible.
If you use a column-based collaboration board, capture steps and evidence there, then transfer connections into a diagramming tool if needed. Do not assume every board supports flowchart connectors. You can use Nextretro’s shared board for workshop observations and decisions without treating it as a specialist process-modeling application.
Worked example: a billing correction loops twice
Consider a hypothetical subscription business. A customer reports an incorrect charge. Support checks the account, sends a request to finance, waits for clarification, and eventually confirms a correction. These steps look straightforward until participants reconstruct a particular case.
Finance had returned the request because the original invoice number was missing. Support then asked the customer, reopened the request, and waited again. The second handoff used a different message thread, so the finance reviewer did not see the first explanation. The case returned to support a second time.
The map now contains two separate loops: missing information and fragmented context. The team resists writing a broad action such as “improve communication.” It tests a request template that includes the invoice reference and keeps subsequent clarification attached to the same request.
The example is invented to show the method. It does not demonstrate that a template will solve every billing delay. The team would still check whether approval authority, workload, or another constraint dominates in actual cases.
Add evidence without turning the workshop into an audit
Use this companion table next to the map:
| Step | Evidence | Uncertainty | Question to resolve |
|---|---|---|---|
| Support prepares request | Example request lacks invoice reference | How often does this happen? | Review a small defined sample |
| Finance asks for clarification | Timestamped reply | Was the request visible earlier? | Confirm queue behavior |
| Support resubmits | Separate thread exists | Is a new thread required? | Ask the workflow owner |
| Customer receives confirmation | Closure message | Did correction match expectation? | Check acceptance evidence |
A timestamp establishes when something was recorded, not necessarily when someone became available to act. Ask how the system captures events before calculating waiting times. If there is no reliable data, label the delay as an observation to investigate.
Do not use the map to rank employees. The purpose is to understand the arrangement of work. Publicly counting how long a named person “held” a request can conceal priorities and capacity while discouraging honest descriptions of workarounds.
Select a change and preserve the baseline
Choose a change that the people in the room can authorize or take to a named decision maker. Record the expected mechanism: “Including the invoice reference should reduce clarification before finance can assess a request.” Then define what you will inspect and when.
Preserve the current-state map before drawing the proposed future. Otherwise the team may lose the evidence that motivated the change. After a trial, revisit the actual path. A new intake template may remove one loop while adding another burden for support.
A retrospective is a useful place to inspect that trial with the same people. Use retrospective ideas for a structured reflection format, while keeping the process evidence attached to the decision.
Frequently asked questions
Who should attend a process mapping workshop?
Include people who perform the main steps, people who receive the output, and someone able to resolve process decisions. Keep missing perspectives visible; an absent department’s workflow should not be treated as verified.
Should we map the current or future process first?
Map the current process first when the purpose is improvement. Check it against real cases before designing a future version. For a genuinely new workflow, label the map as a proposal and test its assumptions.
What if the workflow does not fit into one session?
Narrow the boundary to one meaningful segment and record its inputs and outputs. Schedule a connected session for the next segment rather than compressing the entire organization into vague boxes.