Experiments & Data
Queue and Capacity Calculator
Why the line explodes. Capacity planning fails because waiting time does not rise in a straight line with load — it bends, and then it goes vertical. A team at 70% busy has a queue you can live with; the same team at 90% busy, doing only a fifth more work, has one you cannot. This puts numbers on that curve for a support desk, a checkout, a clinic, a service team, or anything else where arrivals meet a fixed number of servers.
Inputs
- Arrivals per hour
- Average service time
- Number of servers
How to use this calculator
- Run this on your busiest hour, not your daily average. A support desk that averages 60% utilisation across the day can be at 95% every weekday morning, and the morning is where the queue and the complaints live.
- Enter arrivals per hour, then the average service time: the full handling time for one job, start to finish, not the part a stopwatch would catch.
- Enter how many servers, agents, chairs, or bays are genuinely available at once. Someone half on the queue and half on other work is half a server, not one.
- Read utilisation and the wait together. Between 70% and 85% the wait rises gently; past 85% it goes near-vertical, and a 5% rise in arrivals can double the queue. That bend is the whole reason this tool exists.
- Use the 'one more server' row as your business case. It converts a headcount request into a wait time your operations lead can recognise, which is a far better argument than a utilisation percentage.
- Treat every number as a floor. Real arrivals bunch up more than the model assumes, and the model already assumes nobody gets fed up and leaves, so your real queue behaves worse than this, not better.
What each term means
- Utilisation (ρ)
- The share of time a server is busy: arrivals divided by total capacity. The one number that decides whether waits are manageable, and the one most often reported with pride at exactly the level that should worry you.
- Offered load (erlangs)
- Arrivals per hour times service time in hours: the number of servers you would need if work arrived perfectly evenly. It never does, which is why you always need more.
- Erlang C
- The probability an arrival finds every server busy and has to wait at all. Distinct from how long they then wait.
- Wq and Lq
- Average time waiting before service starts, and the average number of people waiting. Related by Little's Law: Lq = arrival rate × Wq.
- M/M/c
- The standard model here: random (Poisson) arrivals, exponential service times, c identical servers, one shared queue. Textbook assumptions that let the maths close.
- Balking and reneging
- Customers who see the line and never join, and customers who join and then give up. Neither is modelled here, and both are how a real queue hides its true cost in lost business rather than in wait time.
- Pooling
- Why one shared queue of five servers beats five separate queues of one, and why a large team survives high utilisation that would swamp a small one: idle time is shared instead of stranded.
Educational disclaimer: Outputs are simplified educational estimates built from the numbers you enter — they are not financial, legal, tax, or investment advice, and real decisions deserve verified figures and qualified professionals.