Observe where work waits, returns or piles up before changing software, staffing or process rules.
Look for waiting rather than busyness
Handoff detail
A bottleneck is the constraint limiting flow, not necessarily the person who looks busiest. Follow several jobs from request to completion and record time spent working separately from time waiting for information, approval, equipment or a slot. A ten-minute task delayed for three days deserves attention. Use timestamps already available in email, job cards or calendars where they are reliable, and label estimates rather than presenting them as measured facts.
Ask what condition blocks release
Handoff detail
For each wait, identify the precise release condition: customer approval, a named manager’s decision, parts arrival, access information or completion evidence. ‘Waiting for admin’ is too vague. Find out whether the condition is required, whether it is requested early enough and whether only one person can satisfy it. This distinguishes genuine capacity constraints from policy rules, unclear authority and missing inputs.
Count queues and returns
Handoff detail
At a fixed time each day, note how many jobs wait at each stage and the age of the oldest. Also record work sent backwards because information or quality was insufficient. A growing queue before scheduling may point to capacity, but repeated returns from scheduling to sales may reveal incomplete scope instead. Keep job types separate where their routes differ; emergency repairs and planned installations should not be averaged into one misleading flow.
Run one small change as a test
Handoff detail
Choose a reversible change aimed at the observed constraint. Examples include collecting access details at booking, setting a daily approval window or limiting work released into an already full stage. State what should change and what must not deteriorate, such as error rates or customer communication. Trial it for a defined set of jobs and compare with the observation log; do not redesign the entire operation from one difficult week.
Practical table
Bottleneck observation log
Complete one row for each observed wait or return; use a short observation window before proposing fixes.
Job and typeRecord a safe reference and distinguish job categories that follow materially different routes.
Stage enteredName the stage and use a known timestamp, noting when the time is only an estimate.
Work startedRecord when active work began so queue time is not confused with processing time.
Release timeRecord when the job left the stage and where it went next, including returns to an earlier stage.
Blocking conditionState exactly what was awaited: decision, information, capacity, part, access, payment or evidence.
Queue snapshotAt the observation time, note jobs waiting and age of the oldest within the same job type.
Return reasonIf rework occurred, state the missing or defective input and where it originated.
WorkaroundRecord calls, side spreadsheets, message chasing or priority swaps used to move the job.
Testable changeSuggest one reversible response tied to the observed blocker, with an owner and trial period.
Effect checkAfter the trial, compare queue, age, completed jobs and rework, then note where waiting moved.