Erlang C Calculator
How many agents do you need on the phones for the calls you expect? Type in your volume and handle time and the answer updates as you go, with the math shown underneath and a table of what happens one agent either side. No email, no demo call, no signup.
- Service level
- 88.8%
- Avg speed of answer
- 7.8 s
- Occupancy
- 71.4%
- Chance a call waits
- 17.4%
- Answered at once
- 82.6%
- Traffic
- 10.00 E
Loading the math.
One agent either side
The row in green is the pick. Grey rows miss your target. Watch how fast service level falls apart as you pull agents off, then how little each extra agent buys once you are over the line.
| Agents | Service level | ASA | Waits | Occupancy | On schedule |
|---|
The math, with your numbers in it
- Working it out.
What is Erlang C, in plain words?
Erlang C is a formula from 1917, by a Danish mathematician named A. K. Erlang, that answers one question: if calls show up at random at some average rate, and each one takes some average time, how likely is a caller to wait, and for how long? You give it the traffic and a number of agents, it gives you back the chance of waiting. Everything else on this page (service level, speed of answer, the staffing number) falls out of that one probability.
I have run a call center and built real-time dispatch dashboards, so this is math I care about getting right. The part I like most is the first step, because it is so simple: traffic in Erlangs is just calls times handle time divided by the length of the interval. A hundred three-minute calls in half an hour is 10 Erlangs, which means ten people busy every second of that half hour just to keep up. Ten agents is not enough though, and that is the whole point of the formula.
Why isn't 10 Erlangs of traffic 10 agents?
Because calls do not arrive in a neat line. They clump. With exactly as many agents as Erlangs, every agent would need to be busy 100% of the time forever, and the first clump of calls would build a queue that never drains. The calculator treats that case as what it is: if traffic is at or above the agent count, the queue never clears, and it says so instead of printing a number.
Above that line the curve is steep, then flat. In the default example, 13 agents answer 79.6% of calls in 20 seconds and 14 answer 88.8%. That one agent is worth nine points of service level! The fifteenth is worth about five, and they keep shrinking from there. So when the question on a slammed interval is "do we need just one more?", the scenario table answers it, because it shows exactly what that one person buys.
(A small warning: 79.6% is not 80%. Some write-ups round it up and call 13 agents a hit. Your phone system will not round it up for you.)
Service level or speed of answer?
Service level (the classic 80% of calls answered in 20 seconds) protects the typical caller. Average speed of answer is an average, so a few very long waits can hide behind a lot of instant answers. A sensible default is to staff to service level and keep an eye on ASA as the sanity check, but some contracts are written in ASA, so the toggle is there. Both numbers show either way.
Why cap occupancy?
Occupancy is the share of logged-in time agents spend actually handling calls. Big queues can run hot and still hit service level, which looks efficient on paper and feels like a treadmill that never stops to the people on it. A cap forces extra agents in when the math says the team would be busy more than you are willing to ask of them. When the cap is what sets the number, the calculator tells you, so you know which knob you are really turning.
What Erlang C gets wrong
- Nobody hangs up. Erlang C assumes every caller waits forever. Real callers abandon, and those who stay wait less because of it, so Erlang C tends to overstaff. The Erlang A calculator adds patience and puts both side by side.
- Every agent is the same and there is one queue. Skills-based routing, overflow groups and callbacks are outside the model.
- The interval is steady. It assumes the rate holds for the whole interval, which is why you run it per half hour and not per day.
- People are not on the phones all day. The formula gives agents on the phones. Shrinkage turns that into people on the schedule, by dividing, never by adding a percentage on top.
Can I trust these numbers?
The formula here is tested against published worked examples before it ships. With the defaults on this page it reproduces the Call Centre Helper worked example digit for digit (wait probabilities 0.6821, 0.4494, 0.2853 and 0.1741 for 11 to 14 agents, 7.8 second ASA, 20 people after 30% shrinkage), Westbay Engineers' 400 calls an hour example (23 agents for a 30 second average delay), and the EventHelix Erlang B and Erlang C examples. Erlang B is computed with the step-by-step recursion rather than factorials, so a 10,000 agent queue does not freeze your browser. If you find a case where it disagrees with a source you trust, tell me, I want to know.
Your homework: pull last week's busiest half hour, plug in the real calls and handle time, and compare the answer to how many people you actually had on. The gap is the story of that half hour!