Erlang calculator for call center staffing
Enter your busiest hour and your service level target. You get the agents required on the floor, the headcount that implies once shrinkage is allowed for, and what happens either side of that number.
- Runs in your browser
- Nothing is stored
- No email required
Standard Erlang C: random arrivals, handle times varying around the mean, and nobody hanging up. Because it credits you with none of the callers who abandon, it staffs slightly high — the safe direction to be wrong in.
14agents on the floor
to answer 80% of calls within 20 seconds
- 10.0Erlangs of arriving work
- 71%Occupancy at that staffing
- 75sAverage wait, callers who queue
- 13sAverage wait, all callers
| Agents | Service level | Occupancy | Wait if queued |
|---|---|---|---|
| 10 | queue never clears | 100% | — |
| 11 | 36.2% | 91% | 5m 0s |
| 12 | 60.7% | 83% | 2m 30s |
| 13 | 76.6% | 77% | 1m 40s |
| 14target | 86.7% | 71% | 75s |
| 15 | 92.7% | 67% | 60s |
| 16 | 96.2% | 63% | 50s |
| 17 | 98.1% | 59% | 43s |
| 18 | 99.1% | 56% | 38s |
A 1917 formula that still runs every WFM tool you have been sold
Erlang C answers one question: given work arriving at some rate and a number of people to handle it, what is the probability that the next arrival has to wait? Agner Krarup Erlang worked it out for the Copenhagen telephone exchange, and it survived the century because queues have not changed — only the thing in them has.
The input that does the work is traffic intensity, measured in Erlangs: calls per hour multiplied by handle time in hours. A queue taking 120 calls an hour at five minutes each carries 10 Erlangs. The critical consequence is that you always need more agents than Erlangs, and it is not a rounding matter — at exactly ten agents for ten Erlangs every agent is busy 100% of the time, the queue never empties, and no service level target is achievable at any answer time.
- Traffic intensity
A = (calls per hour × AHT in seconds) ÷ 3600Measured in Erlangs. 120 calls an hour at 5 minutes each is 10.- Probability of waiting
Pw = ErlangC(N, A)The chance an arriving call finds every agent busy. Computed from the Erlang B recursion rather than the textbook factorial form, which overflows to NaN past about 60 agents.- Service level
SL = 1 − Pw × e−(N − A) × T / AHTThe share answered within T seconds. Average wait for the callers who do queue isAHT ÷ (N − A); multiply that by Pw for the average across all callers, which is what most SLAs are written against.
80/20 is a convention, not a standard
Eighty per cent of calls answered within twenty seconds became the default through Bell System network design and ICMI’s benchmarking in the 1980s, and it is now baked into most ACD reports and outsourcing contracts. That is a reason it is common, not a reason it is right for your queue.
The honest way to set the target is from your own abandon curve: find the point where callers start hanging up in numbers you cannot accept, and set the answer time inside it. Everything else is inherited from somebody else’s contact center.
| Queue | Typical target | What sets it |
|---|---|---|
| General business queue | 80/20 | The ICMI and COPC default, and what most ACD reports are pre-configured to measure. |
| Healthcare triage | 80/30 or 90/20 | Callers tolerate a longer wait when the alternative is a clinic visit — but far fewer of them can be allowed to abandon. |
| Financial services, private client | 90/10 | The cost of a lost call is a relationship rather than an order, so the target is set by retention risk. |
| Emergency dispatch | 95/5 or better | Set by mandate rather than by economics. |
| E-commerce at peak | 70/30 | A deliberate seasonal trade: accept a longer wait for six weeks rather than hire for a peak that ends. |
Turning one number into next month's schedule
The calculator sizes a single interval. A staffing plan is what you get after running it against the whole week and reconciling the answer with the fact that people work in shifts.
- 01Export calls offered and AHT per 30-minute interval for your busiest recent week, from the ACD rather than from memory.
- 02Run each interval through the calculator on its own numbers. A day does not have one staffing answer; it has forty-eight.
- 03Read the gross FTE line, not the agent line. Shrinkage of 15–30% is what turns seats on the floor into people on the payroll.
- 04Fit shift patterns to the per-interval demand curve, and accept the overshoot. Shifts come in eight-hour blocks; demand does not.
- 05Re-run monthly. Volume and handle time drift seasonally, and a staffing model built on data older than about six months is usually wrong in both directions at once.
Four assumptions, and when each one breaks
Erlang C is a model, and every model is wrong somewhere specific. These are the four places, in the order they are likely to matter to you.
- Calls arrive randomlyPoisson arrivals — each call independent of the last. True of most inbound queues, and false immediately after a marketing email goes out or an outage notice posts.
- Handle times vary exponentially around the meanA reasonable fit for mixed inbound work. Poor for queues where nearly every call takes the same scripted four minutes, where the model is more pessimistic than reality.
- Nobody hangs upThe big one. Erlang C assumes infinite patience, so it never credits you for the callers who abandon and relieve the queue. That makes it staff slightly high — a safe direction to be wrong in, but if you routinely abandon more than 10% you want Erlang A or a simulation.
- Every agent can take every callSkills-based routing splits one pool into several smaller ones, and small pools are less efficient than one large one. Model each skill queue separately rather than the floor as a whole.
For a broad-skill inbound queue running under about 5% abandonment, the output is close enough to plan against. Outside that, treat it as the floor rather than the answer and add ten to fifteen per cent of headroom — which is still a better starting point than the spreadsheet it replaces.
Frequently asked questions
What is the Erlang C formula?
A queueing formula, published by Agner Krarup Erlang in 1917, that gives the probability an arriving call has to wait because every agent is already busy. From that one probability you get the two numbers a planner needs: the service level a given headcount achieves, and the average wait for the callers who queue. It is the engine underneath every workforce-management product on the market.
What is traffic intensity, and why is it measured in Erlangs?
One Erlang is one resource occupied continuously for one hour, so it measures arriving work rather than arriving calls. Calls per hour multiplied by handle time in hours gives it: 120 calls at five minutes each is 10 Erlangs. The consequence matters more than the unit — you always need more agents than Erlangs, and it is not a rounding question. At exactly ten agents for ten Erlangs, every agent is busy 100% of the time, the queue never empties, and no service level is reachable at any answer time.
What is the 80/20 service level standard?
Eighty per cent of calls answered within twenty seconds. It became the default through Bell System network design and ICMI’s benchmarking work in the 1980s, and is now the preset in most ACD reporting and the baseline in most outsourcing contracts. That makes it common rather than correct: the table above lists the queues where a different target is the defensible one.
Why does the calculator want my peak hour rather than my daily volume?
Because queues do not average. A day of 960 calls is not eight hours of 120: if 300 of them land between 9 and 10, staffing to the average means that hour fails badly while the afternoon sits idle. Erlang C describes a steady state, so it is run per interval and the intervals are added up afterwards.
What is the difference between the two wait figures?
“Callers who queue” is the average wait among the people who actually waited. “All callers” averages in everyone answered immediately, so it is always lower and is the one usually reported as average speed of answer. Supervisors recognise the first; SLAs are usually written against the second. Quoting one where the other is meant is a common way for two teams to disagree about the same queue.
Why does adding one agent sometimes change almost nothing?
Because the curve is not linear. Below the requirement each missing agent costs a great deal of service level; above it each extra one buys less than the one before, until you are paying a full salary for a fraction of a point. The table on this page is there to show you where on that curve you are standing.
Should shrinkage be added or divided?
Divided. Shrinkage is a share of paid time, so fourteen agents at 15% shrinkage needs 14 ÷ 0.85 = 17 people, not 14 × 1.15 = 16. The difference is small at 15% and substantial at 30%, and it is the commonest reason two calculators disagree on the same inputs.
Does this work for chat and email?
Not directly. Erlang C assumes one contact per agent at a time, which holds for voice and not for a chat agent running three concurrent conversations. Divide the requirement by realistic concurrency as a rough first pass, and treat email as a workload-and-backlog problem rather than a queueing one, since nobody is waiting on the line.
Do you store what I type in here?
No. The whole model runs in your browser — the inputs are never sent anywhere, there is no account, and there is nothing to unsubscribe from afterwards. You can check the arithmetic yourself.
How do I turn this into a weekly FTE budget?
Run every 30-minute interval of your busiest week separately, take the gross FTE line from each, and fit shift patterns to the resulting demand curve — the five steps above set it out in order. The number that goes in the budget is the gross figure, not the agent figure: shrinkage is what turns seats on the floor into people on the payroll.
Or let the platform do this weekly.
Forecasting, scheduling and adherence are part of DialPhone AI Contact Center — the same arithmetic, run against your live queue instead of a slider. Fourteen days, no card.
No credit card required · Free number porting · Cancel anytime