This page uses the Erlang C model, the standard multi-server queue in which arrivals are random, service times are exponentially distributed and anyone who has to wait stays in the queue. It is the model behind contact centre staffing, and it applies reasonably well to any counter, desk or help queue where work arrives unpredictably.
The result that matters is not the formula but its shape. Waiting time does not rise smoothly with load: it rises gently up to about 70% utilisation, noticeably by 85%, and then explodes. This is why an operation that looks comfortably staffed can collapse after a modest increase in volume, and why running servers at 95% utilisation to look efficient produces waits many times longer than at 85%.
Randomness is the whole cause. If arrivals were evenly spaced and service times identical, a server at 99% utilisation would produce no queue at all. It is the variability that creates waiting, which is why adding one more server to a small team helps so disproportionately. On the sample entries 84 arrivals an hour against 7 servers each handling 14.29 an hour is 84.0% utilisation, a 57.4% chance of queueing and an average wait of 2.15 minutes.
The formula
λ- Arrival rate per hour
μ- Service rate per server per hour = 60 ÷ handling time
c- Number of servers
ρ- Utilisation = λ ÷ (c × μ)
How to use this calculator
- Enter the arrival rate per hour.
- Enter the average handling time per item in minutes.
- Enter how many servers or agents are working.
- The gauge shows the expected wait in minutes; utilisation and queue length follow.
Worked examples
84 arrivals an hour across 7 servers
Each server handles 14.29 an hour, so the offered load is 5.88 erlangs and utilisation is 84.0%. The Erlang C probability of queueing is 57.4% and the average wait is 2.15 minutes, with 3.01 people waiting on average.
The cost of the last few points of load
With 8 servers utilisation falls to 73.5% and the wait to 0.65 minutes. With one fewer, utilisation rises to 98.0% and the wait to 33.08 minutes. One server changes the wait by far more than it changes the utilisation.
How to read your score
Frequently asked questions
What assumptions does Erlang C make?
Random Poisson arrivals, exponential service times, no abandonment and no limit on queue length. Real queues abandon, which makes actual waits shorter than the model predicts — Erlang A adds that behaviour.
Why does the wait explode near full utilisation?
Because randomness means arrivals bunch. As utilisation approaches one, there is no spare capacity to absorb a bunch, so queues that form have no chance to clear. The wait rises roughly as one over one minus utilisation.
Why does adding one server help so much?
It adds capacity precisely where it is scarcest — the moments when everyone is busy. On a small team the proportional gain in spare capacity is large, which is why the effect is dramatic below about ten servers.
Can I use this for staffing?
For a rough size, yes, but real scheduling needs half-hourly arrival profiles, abandonment behaviour and a service level target rather than an average wait. Averages hide the peaks that cause the complaints.
Queueing reference
| Servers | Utilisation | Probability of queueing | Average wait | In queue |
|---|---|---|---|---|
| 6 | 98.0% | 94.5% | 33.08 min | 46.31 |
| 7 | 84.0% | 57.4% | 2.15 min | 3.01 |
| 8 | 73.5% | 33.0% | 0.65 min | 0.91 |
| 9 | 65.3% | 17.8% | 0.24 min | 0.34 |
| 10 | 58.8% | 9.1% | 0.09 min | 0.13 |
| 12 | 49.0% | 2.0% | 0.01 min | 0.02 |
Offered load is 5.88 erlangs, so six servers is the minimum for stability and produces a wait many times longer than eight.
| Servers | 3 min handling | 4.2 min handling | 5 min handling | 6 min handling | 7 min handling |
|---|---|---|---|---|---|
| 6 servers | 0.56 | 33.08 | unstable | unstable | unstable |
| 7 servers | 0.18 | 2.15 | unstable | unstable | unstable |
| 8 servers | 0.06 | 0.65 | 3.18 | unstable | unstable |
| 10 servers | 0.01 | 0.09 | 0.37 | 1.89 | 32.49 |
| 12 servers | 0.00 | 0.01 | 0.06 | 0.31 | 1.30 |
At 84 arrivals an hour. Cells marked unstable mean the queue grows without limit.