Bottleneck Mapping & Throughput Worksheet

A practical, step-by-step workbook to map service or production flow, collect the right data, identify true bottlenecks, prioritize high-impact experiments, and measure results so ticket times and table turns improve without sacrificing food quality.

Welcome — Why this matters

Slow spots in your service flow quietly limit how many guests you can serve and how quickly dishes reach tables. This worksheet helps you find the true constraints (not the noisy symptoms), design focused experiments to improve throughput, and measure whether changes actually help. Keep quality and guest experience central: faster isn't better if it harms plate consistency or guest satisfaction.

How to use this guide

  1. Map the flow for a typical ticket or dish during a representative shift.
  2. Collect cycle-time data for each step across multiple tickets and conditions.
  3. Identify the slowest steps and determine capacity limits.
  4. Prioritize experiments using an impact vs. effort matrix and simple scoring.
  5. Run short, clearly defined experiments (with measurement and rollback criteria).
  6. Evaluate results and standardize improvements that work.

Core concepts (plain language)

  • Cycle time: how long a specific task or station takes to complete one unit (one plate, one prep batch, one ticket handoff).
  • Throughput: how many completed items the system delivers per time unit. The slowest step often caps throughput.
  • Bottleneck / Constraint: the step that limits the entire flow because it cannot keep up with upstream or downstream demand.
  • Work-in-progress (WIP): items between steps. High WIP often hides imbalance and creates longer lead times.

Step 1 — Map the service flow

Create a simple linear map for a representative ticket or dish. Focus on observable stations and discrete tasks rather than abstract ideals.

Suggested map elements (one row per step):

  1. Step ID — short label (e.g., Expeditor, Grill, Fry, Plating)
  2. Station name / location
  3. Task description — exactly what happens at this step
  4. Inputs — what must be ready before this step starts (ingredients, prepped components)
  5. Outputs — what this step hands off (plated dish, cooked component, ticket advanced)

Step 2 — Data collection plan

Good decisions come from consistent, practical data. Use POS timestamps when possible and supplement with short stopwatch observations during peak and off-peak windows.

What to record for each step (one row per observation):

  1. Ticket ID and time window (lunch/dinner/rush)
  2. Step ID (from your map)
  3. Start time and end time for the step (or cycle time in seconds)
  4. Any blocking or waiting observed (yes/no + brief note)
  5. Quantity handled (plates, portions)
  6. Observer notes: rework, missing components, equipment issues

Sampling guidance:

  • Collect at least 15–30 observations per step across representative shifts (more for highly variable steps).
  • Include rush periods and quiet times to see variance and bottleneck behavior under load.
  • When continuous POS timestamps exist (order placed, in-kitchen, served), pair them with 10–15 manual observations to validate who/where time is spent.

Step 3 — Analyze and spot the bottleneck

For each step compute:

  • Average cycle time
  • Median and 90th percentile (to understand variability)
  • Capacity estimate: how many units per hour could this station deliver during a rush (if staffed normally)?
  • Blocking frequency: % of observations where the step was waiting on something else

Interpretation hints:

  • The step with the longest average cycle time or lowest capacity under load is a likely bottleneck.
  • High variability (big gap between median and 90th percentile) means occasional spikes create perceived slowness; experiments should reduce variability as well as average time.
  • Repeated blocking indicates upstream or downstream imbalance rather than pure speed problems.

Step 4 — Prioritization: impact vs. effort

Score candidate experiments across two axes: expected Impact (1–5) and Effort/Risk (1–5). Compute a simple priority score: Priority = Impact × (6 - Effort) so high-impact/low-effort moves to the top.

Use short justification notes for each experiment so decisions remain auditable.

Example categories of experiments:

  • Low effort, high impact: tweak mise-en-place, pre-portion common ingredients, move a garnish station closer to plating.
  • Moderate effort: add an expeditor during rush, redesign plating sequence, trial batch-cooking for popular items.
  • High effort: change line layout, buy a new piece of equipment, rewrite menu items.

Step 5 — Design small, measurable experiments

Each experiment should include:

  1. Hypothesis (what you expect to change and why)
  2. Measurement plan (what you will measure, for how long, sample size)
  3. Success criteria (numeric improvement target and no-harm constraints for quality)
  4. Duration and schedule (short runs: 3–7 shifts for quick feedback)
  5. Rollback criteria and who signs off

Sample experiment templates:

  • Task redistribution: Move garnish tasks from grill to a dedicated runner during dinner rush. Measure plating time and ticket completion over 5 dinner shifts. Success = 15% reduction in plating cycle time without increase in plating defects.
  • Batch prep trial: Pre-cook a batch of a high-volume component off-peak and hold properly. Measure reduction in grill cycle time and impact on quality over 7 shifts.
  • Expeditor role trial: Assign an experienced server as expeditor for 4 Friday/Saturday shifts. Measure ticket-to-serve time, plating errors, and table turn rate.

Step 6 — Run, measure, learn, and standardize

  1. Run the experiment per plan and collect before/after measurements.
  2. Analyze results: did you hit success criteria? Also check unintended consequences (worse quality, increased waste, staff overload).
  3. If successful, create a short standard work note and train affected staff. Track a KPI (e.g., ticket time) for several weeks to ensure change sticks.
  4. If not successful, capture learnings and consider a follow-up experiment that addresses the missing assumption.

Common pitfalls to avoid

  • Fixing symptoms: changes that reduce visible queues but don’t increase throughput usually shift the constraint elsewhere.
  • Insufficient data: one-off observations can mislead—measure under different demand levels.
  • Ignoring quality: faster plating that increases remakes or guest complaints is a false win.
  • Overcomplicating: prefer small, reversible experiments that the team can run and learn from quickly.

Practical next steps

  1. Create your flow map right now for one high-volume dish or a typical ticket.
  2. Run a 1-shift pilot of the data collection plan to validate templates and observer notes.
  3. Pick one low-effort, high-impact experiment and run it for 3–5 shifts with defined measurements.
  4. Document the result and, if successful, convert it to standard work and a brief training note.

Where this ties into larger systems

Throughput improvement often connects to forecasting, staffing, inventory, and equipment reliability. If experiments repeatedly point to insufficient capacity, consider using broader capabilities (demand forecasting, scheduling changes, preventive maintenance) to address systemic constraints.

Template fields to copy into a worksheet

  1. Mapping table: Step ID | Station | Task | Inputs | Outputs
  2. Data row: Ticket ID | Time window | Step ID | Start | End | Cycle time | Blocking (Y/N) | Qty | Notes
  3. Analysis row: Step ID | Avg | Median | 90th% | Capacity est. | Blocking % | Variability note
  4. Experiment card: Title | Hypothesis | Priority score | Measurement plan | Success criteria | Duration | Owner | Result

Use these templates as starting points and adapt them to your kitchen’s language and rhythms. Small teams often prefer paper or a whiteboard during trials, then transfer validated templates to an electronic format for documentation.

If you want this as an interactive worksheet

An interactive form that collects step observations, auto-calculates averages and priority scores, and stores experiment results would speed adoption across locations. See the capability notes for possible next steps.

Good luck — run small experiments, keep quality first, and let measured learning guide larger changes.


Discussion

Comments and conversation will live here.