Bottleneck Identification & Throughput Workshop

Welcome — what this workshop helps you do

This facilitator guide helps managers and shift leaders run a focused workshop (60–120 minutes) to uncover the real bottleneck slowing ticket throughput, collect a few usable metrics on the floor, and create short, measurable experiments. The aim is faster tickets, fewer remakes, and more predictable shifts — not band-aid fixes that simply move the problem elsewhere.

When to run this

• Repeated slow ticket times or long guest wait times.
• High variation in ticket times between shifts or stations.
• After a layout change, staffing change, or new menu item introduction.

How long and who to invite

Recommended length: 60–120 minutes depending on scope. Invite a mix of participants who actually work the flow: a front-of-house lead, head cook or line lead, two or three shift team members (one from each station if possible), and a facilitator (manager or operations coach). Include a scribe/data collector.

Workshop agenda (90-minute example)

1. 0–10 min — Frame the hunger: Briefly describe the problem (tickets too slow, guests waiting). Agree the goal (for example: reduce average ticket time from 18 to 14 minutes within two weeks). Make the goal measurable and timebound.
2. 10–25 min — Map the service flow: Draw a swimlane map from order in to food served. Mark stations, handoffs, wait points, and where items queue.
3. 25–40 min — Collect simple real-time metrics: Decide what to measure now (see templates below). If practical, do a 15-minute floor snapshot; otherwise use the most recent shift data or POS timestamps.
4. 40–55 min — Identify candidate bottleneck: Compare cycle times and queue lengths. Use root-cause prompts to test the hypothesis. Look for stations whose throughput potential is lower than demand.
5. 55–75 min — Generate fixes and rank them: Brainstorm countermeasures, then prioritize by expected impact and ease of testing.
6. 75–90 min — Design a single-variable A/B test and measurement plan: Define the experiment, acceptance criteria, roles, and duration. Agree how to collect and store results.

Practical materials & roles

• Whiteboard or large paper for flow map.
• Stopwatch, phone timers, or POS timestamps for ticket times.
• Printed data templates (examples below) or convert them to an InteractiveForm for saved submissions.
• Roles: Facilitator (keeps time and decisions), Scribe (draws map and records), Data Collector (measures ticket or station times), Operators (challenge assumptions and validate feasibility).

Key measurement guidance — keep it simple and objective

Good measurement doesn't require perfection — it requires being consistent and objective. Use POS timestamps when possible to avoid manual error.

• Prefer median over mean if there are big outliers — medians show typical performance. Report both when useful.
• Collect at least 10 ticket times for a quick local snapshot; for a stronger baseline use 30+ tickets or several shifts depending on volume.
• When measuring station cycle times, observe 3–5 cycles per station as a quick snapshot. For more confidence, extend to 10 cycles spread across peak minutes.
• Keep tests short and comparable: choose control and treatment windows where demand and staffing are similar (same day-of-week and time window if possible).
• Record context notes: specials, large parties, equipment issues, or missing staff that could bias results.

Simple data templates (convert these to interactive forms if your platform supports it)

Collect a few straightforward measurements. Use numeric samples for quick decisions rather than trying to measure everything.

Ticket time log (use POS timestamps when possible)

Station cycle-time snapshot (observe 3–10 cycles each)

Queue length / backup log (every 5 minutes)

Count items waiting for a station (e.g., number of plates waiting at expo). Record time and count to see patterns.

Mapping exercises — how to reveal the bottleneck

1. Draw the flow with swimlanes for FOH, line, expo, and dish.
2. Add average cycle times to each station from your snapshot.
3. Calculate rough throughput potential: a station with a 120s cycle can handle 30 items/hour (3600 ÷ 120 = 30).
4. Spot where throughput potential is lower than demand — that is the likely bottleneck. Validate by observing queue lengths and blocked downstream work.

Root-cause prompts (use these aloud to probe causes)

• When the line backs up, which station has the longest queue?
• Are we waiting for cooking, assembly, plating, or an external delay (allergens, ordering error)?
• Do we have uneven prep that creates peaks for one station?
• Are communication or handoff failures causing idle time at downstream stations?
• What variation exists between team members or shifts?

Common fixes and when to use them

• Line balancing: Reassign tasks so cycle times align across stations.
• Prep batch adjustment: Increase or shift prep to feed the bottleneck during peak windows.
• Station redesign: Move equipment or change layout to cut motion and handoffs.
• Temporary floating support: Assign a runner or expeditor during peak minutes.
• Menu or ticket-level changes: Limit complex items during rush or stagger production.
• Standard work: Create short checklists to reduce variation and remakes.

A/B test planning template (keep tests short and observable)

Define one change, a control period, and a treatment period. Keep other conditions as close as possible. Avoid changing staffing, menu, pricing, or equipment mid-test.

Interpreting results — practical rules

• Compare comparable windows: same day-of-week and same hour block when possible.
• Look for consistent direction in the metrics, not a single lucky night.
• If the acceptance criteria are met and quality is unchanged or improved, consider adopting or adapting the change.
• If results are mixed, run a quick follow-up test with a slightly modified protocol rather than abandoning immediately.

Measurement & follow-up

• Collect the agreed metrics for the baseline period and the treatment period. Use POS timestamps where possible to avoid manual error.
• Review results within 48–72 hours of completing the test. Discuss what changed and why with the team who ran the experiment.
• Decide to "adopt, adapt, or abandon". If adopted, document the new standard work and communicate across shifts/locations.

Common pitfalls to avoid

• Changing multiple variables at once (hard to know what worked).
• Relying on impressions instead of simple measurements.
• Fixing visible pain points without checking downstream effects.
• Using too-small samples for noisy metrics — prefer repeated short tests over single-night conclusions.

Recommended KPIs for rapid throughput experiments

• Median ticket time and average ticket time (by shift/hour)
• Number of remakes per 100 tickets
• Average queue length at identified bottleneck (sampled every 5 minutes)
• Ticket completion rate (tickets/hour)
• Customer wait complaints or negative mentions tied to speed

Next steps and scaling

After a successful local test, package the experiment as a short standard operating note (SOP) that includes the data, exact steps, and ownership so other shifts or locations can replicate. Consider converting the ticket log and station snapshot into an InteractiveForm so teams can collect and compare results over time and across locations.

Appendix: Quick checklist for facilitators

• Frame the specific ticket-time goal.
• Collect at least 10 ticket times or a 15-minute snapshot of cycle times (30+ tickets for a stronger baseline).
• Create the swimlane map and mark cycle times.
• Design a single-variable A/B test lasting 2–5 shifts/nights depending on volume.
• Agree on ownership, where to save data, and when to review results.

Practical tip: making data capture repeatable

If your platform supports it, convert the Ticket Time Log, Station Snapshot, and Queue Log into saved InteractiveForms so results are stored centrally and can be compared across tests and locations. Use the shared POST /content/{contentItemId}/submit endpoint to store submissions in JSON for later reporting. See CapabilityEnhancementNotes below for implementation ideas.

Facilitator notes — conversation starters

• "What part of this flow feels like it's almost always backed up?"
• "What one small change could we try tonight that won't require new hires or equipment?"
• "If this works for this shift, how could we document it so other teams can try it without re-running this workshop?"

Closing

Use this workshop as a lightweight, repeatable capability rather than a one-off event. Small, well-measured changes and fast learning loops compound into noticeably better throughput and guest experience over time.