A process map presentation is a decision aid, not a wall of boxes. The audience should see where work starts, where it waits, who owns each handoff and what evidence proves a step is complete. A useful first draft can begin from a written outline in Presenti’s text-to-presentation workflow, but the map still needs review with the people who run the process.
Define the process boundary
Write the start event, end event and customer of the process. “Order to cash” is too broad for one meeting; “approved order to first invoice” is a workable boundary. State what is outside the map so reviewers do not mistake a teaching view for a complete operating model.
Choose the level of detail for the audience. Executives need stages and decisions; operators need handoffs, systems and exception routes. Use one overview slide and a small number of zoom slides rather than shrinking every task into one unreadable diagram.
Use one request to define the map
Here is a fictional internal-design service. An employee requests a campaign banner; a coordinator checks the brief; a designer prepares the asset; the requester accepts it. Start when the request arrives and end when the requester accepts the final file. Campaign planning, brand-policy approval and publishing the campaign are outside this boundary.
The presentation question is “Why do complete requests wait before design starts?” It is not “How can we make every part of marketing faster?” That narrower question determines which timestamps and handoffs belong on the slides. The records below are constructed for this tutorial, not measurements from Presenti or a customer.
ASQ’s flowchart guidance recommends defining boundaries and walking through the map with people involved in the process. Use that walk-through to correct the current-state map before drawing a preferred future process.
Map handoffs and ownership
For each step, record the owner, input, output and next recipient. Draw the handoff where responsibility changes, not only where a tool changes. If two teams share a step, name the decision owner and the person who supplies evidence.
Use consistent verbs: validate, approve, schedule, publish or reconcile. A noun such as “review” hides the expected action. Keep system names in a secondary label so the process remains understandable if the tool changes.
The swimlane content, ready for a slide
| Lane | Step and input | Output / next recipient | Exception arrow |
|---|---|---|---|
| Requester | Submit purpose, dimensions, copy and needed-by date. | A request record goes to the coordinator. | Missing information returns here. |
| Coordinator | Validate the brief and confirm readiness. | A ready-to-design record joins the designer’s queue. | Incomplete brief → requester, with the missing item named. |
| Designer | Take a ready request and create the banner. | A versioned proof goes to the requester. | Unclear copy → coordinator for clarification. |
| Requester | Compare the proof with the agreed brief. | Accepted file closes the request. | Correction within the brief → designer; changed scope → coordinator. |
On the overview slide, turn each row into a lane and place the ready-to-design queue between coordinator and designer. Label both exits from “Brief complete?” rather than relying on arrow color. A separate correction loop is useful: correcting a typo is not the same event as requesting a new banner size after work begins.
Surface waits, rework, and controls
Mark waiting time separately from working time. A queue can be the largest source of delay even when every task is efficient. Show rework loops and the reason for returning to an earlier step. This gives the audience something concrete to improve.
Controls should be visible but proportional. Add the evidence that proves a high-risk step is complete, such as an approval record or reconciliation. Do not imply that a diagram itself proves compliance; it only shows where the check belongs.
Separate elapsed time from working time
In one synthetic case, the complete brief reaches the queue at 09:00, design starts at 11:00, the proof is sent at 11:45 and the requester accepts it at 12:15 on the same day. Elapsed time is 195 minutes: 120 waiting for design, 45 in production and 30 awaiting acceptance. These intervals are additive because this simplified case has no overlapping work or rework.
Do not label all 195 minutes “design time.” Equally, removing a 120-minute queue would not necessarily save two staff-hours: waiting time and labor effort are different measures. For an actual service, agree whether the clock includes nights, weekends and paused requests before comparing cases.
| Synthetic case | Ready → design start | Production | Proof → acceptance | Total elapsed |
|---|---|---|---|---|
| R-01 | 120 min | 45 min | 30 min | 195 min |
| R-02 | 90 min | 60 min | 20 min | 170 min |
| R-03 | 150 min | 40 min | 30 min | 220 min |
The supporting record needs a case ID, ready timestamp, work-start timestamp, proof timestamp, acceptance timestamp and exception reason. If a case loops back for revisions, record the extra interval separately instead of forcing it into the straight-through example.
Explain the bottleneck with evidence
Choose one bottleneck for the main story. Compare expected cycle time with observed samples, and label the measurement period. If the sample is small, say so. A range or confidence note is more honest than a precise-looking average with no context.
Then show two feasible changes and the trade-off for each. Faster handoff may require a new approval rule; automation may move work to exception handling. A good map makes those choices discussable instead of promising that one redesign fixes everything.
What the evidence does—and does not—justify
A suitable slide headline is “The ready queue is the longest interval in these three examples.” All three constructed cases support that statement. “The designer is the bottleneck” is stronger than the records justify. The delay could reflect release timing, competing priorities, missing capacity or a timestamp recorded too early.
Compare two proposals. A twice-daily queue review is easy to test but may leave urgent requests waiting between reviews. A continuously staffed intake desk could respond sooner but requires capacity the team has not justified. Show both trade-offs and test the lighter intervention first; do not label a future-state arrow “instant” before anyone has tried it.
Keep production and acceptance measures alongside queue time. A shorter queue is not an improvement if work is rushed and revisions increase. The map should show where to collect evidence, not display a projected saving as an observed result.
End with an owner and a next test
Close with the decision needed, the owner, the smallest test and the date for review. Link the supporting data or procedure in the appendix. The next version of the map should record what changed and whether the bottleneck moved.
Before presenting, ask a frontline operator to trace one normal case and one exception without your help. If they cannot follow the arrows or disagree with the owner labels, fix the map before asking leaders to approve a change.
The final decision slide
Proposed test: For the next ten complete requests, the coordinator reviews the ready queue at two agreed times each working day and names the next owner. Owner: the service coordinator. Records: the four timestamps above, plus revisions and urgent exceptions. Review: after the tenth accepted request, compare waiting intervals with a separately collected baseline using the same clock definition.
Ten requests make a small operational pilot here, not a statistically validated sample. If the next requests differ substantially in complexity, separate them rather than claiming a before-and-after effect. Shorter waits but more scope changes would suggest that the intake definition needs work.
Present four views: boundary, current handoffs, timing evidence and proposed test. Put the detailed case log behind the evidence slide. Leaders get a decision they can make, while operators retain enough detail to challenge the map.
To show what a proposed redesign changes, the before-and-after presentation example keeps the process boundaries comparable and separates a simpler workflow from a measured improvement.
