operations · simulation
Where does the queue pile up? Finding the bottleneck before customers do
Every process has one stage that sets its pace. A short guide to spotting it with Little's law and utilisation, why adding people elsewhere doesn't help, and how to simulate a change before making it.
A support team adds two agents and the backlog doesn't move. An engineering team doubles the number of stories in flight and ships no faster. Both have the same cause, and it's visible in about five minutes once you know where to look.
Every process has one stage that sets its pace
Work flows through stages: quick checks, triage, investigation, escalation, close. Each stage has a capacity — people × hours per day ÷ hours per item. The stage with the lowest capacity relative to the work reaching it is the bottleneck, and the throughput of the whole process is that stage's throughput. Nothing else matters as much.
Adding people anywhere else feels productive and changes nothing. It just moves the pile.
Two numbers tell you where it is
Utilisation — how busy a stage is, as a share of its capacity. Below about 80% a queue stays short. Above 90% it grows with every small fluctuation, because there's no slack to absorb a busy morning. At 100% the queue grows without bound: work arrives faster than it can leave, forever.
Little's law — the number of items in a system equals the arrival rate times the time each one spends there. Put the other way: lead time = work in progress ÷ throughput. If your team has 120 tickets open and finishes 20 a day, the average ticket takes six days, whatever the SLA says. This is arithmetic, not opinion, and it's the fastest way to check a claim like "we're fine, it's just a busy week".
Why the symptom shows up somewhere else
The queue piles up in front of the bottleneck, but the complaints arrive after it: late escalations, missed release windows, customers chasing. Teams respond to where the complaint is, not where the constraint is. Watching the process move — not the dashboard, the actual items — is how you see that the "escalation problem" is really a 95%-busy investigation stage.
Simulate before you change it
The honest way to answer "would one more person at triage help?" is to try it on a model before trying it on people. The model needs very few inputs: items per day, people per stage, hours per item, how often items branch or come back for rework. Run it for a month of working days. Watch which queue grows, what the lead time does, how many items miss the target.
Then change one number and run it again. One more reviewer at QA sign-off. A Monday spike. A 20% rework rate instead of 10%. The comparison tells you where the next person pays for themselves and where they don't. It's a model on your assumptions — it won't predict Thursday's queue — but it will tell you where the structure breaks, which is the decision you're actually making.
We put exactly this into Ovenbird: the simulation reads the stages from your own process document, defaults the numbers so that the first run keeps up, and lets you push until it doesn't. Try the demo on the home page; raise tickets per day from 20 to 30 and watch "Triage by symptom" go red.
Three habits that keep the bottleneck visible
- Measure utilisation per stage, not per team. A team at 70% can have a stage at 98%.
- Count work in progress every week and divide by throughput. If the lead time that gives you is worse than what you're promising, no amount of urgency fixes it.
- When the document changes a step, re-run the model. Adding an approval to a stage is adding capacity demand; the document rarely says where the capacity comes from.