Erlang C Calculator
Calculate agents needed on phones and staff to schedule. Adjust call volume, your service target, and shrinkage, then compare the results.
Your call workload
Count a typical busy period, not an average day. The busiest stretch is what sizes the team.
Notes, updating a record, anything that stops the next call arriving. Zero if there is none.
Advanced settings
Breaks, training, meetings, leave. Converts agents needed on phones into scheduled staffing.
Maximum share of available agent time spent handling calls. 85% is an example ceiling; choose one suited to your workload.
Active assumptions
Period: 30 minutes · 80% / 20 s
Shrinkage: 30% · Maximum occupancy: 85%
What the numbers say
- Agents required on phones
- 14
- Staff to schedule
- 20
Agents on phones are handling calls or ready to answer. Scheduled staff includes time off phones; it is not a total hiring requirement.
- Service level (20 s)
- 88.8%
- Callers who wait at all
- 17.4%
- Average wait, counting everyone
- 7.8 s
- Average wait for those who do wait
- 45 s
- Occupancy
- 71.4%
- Work arriving
- 10 erlangs
- What set this number
- the target you chose
One additional agent
The same 30-minute period with one additional agent on phones:
- Service level (20 s)
- Current: 88.8%+1 agent: 94.1%
- Average wait, counting everyone
- Current: 7.8 s+1 agent: 3.7 s
- Occupancy
- Current: 71.4%+1 agent: 66.7%
One file: the numbers, and every assumption behind them.
A whole day at once
A CSV with a label, a call count, and optionally a handling time per row.
Worked example: 14 on phones, 20 scheduled
With 100 calls in 30 minutes and 180 seconds of handling time, an 80%-within-20-seconds target needs 14 agents on phones. At 30% shrinkage, schedule 20 staff. The calculated service level is 88.8%; the 85% occupancy ceiling does not set the headcount in this example.
What this answers, and what it does not
The model behind this page is Erlang C. It assumes calls arrive at random at a steady average rate across the period, that anybody free can take any call, that one person handles one call at a time, that callers are answered in the order they arrived, and that nobody hangs up. Those assumptions are what make the arithmetic possible, and each one is a way the answer can be wrong.
The model excludes abandonment. Callers leaving can shorten a real queue, but repeat calls and routing restrictions also affect staffing. Treat the result as an estimate to validate, not a guaranteed upper bound. Because the arrival rate is steady across the period, a five-minute rush inside a half hour is invisible to it; use a shorter period if your day has spikes. And because one person handles one call at a time, it does not describe somebody also working three chats, and it does not describe the case where only two of your five people are able to take a given call.
It also will not tell you a rota. Feeding it a day of intervals gives you a requirement per interval, each calculated independently, with no shift lengths and no breaks placed anywhere. That table is an input to building a schedule. It is not a schedule.
Checked against published examples
A calculator that is wrong by one person still looks entirely plausible, so the only useful claim is one you can check. Every case below was read off the publisher's own page on the date shown, and the right-hand column is this page's own arithmetic on the same inputs. Automated checks compare these reference figures with the same calculation used above.
| Case | The inputs | What the source publishes | What this page computes | Source |
|---|---|---|---|---|
| Westbay Engineers | 400 calls an hour, 180 seconds each, willing to tolerate a 30-second average delay. | 23 on phones | 23 on phones | Erlang C calculator, Westbay Engineers Read 2026-09-06 |
| Call Centre Helper | 100 calls in 30 minutes, 180 seconds each, 80% answered within 20 seconds, 30% of paid time off the phones. | 14 on phones, 20 on the rota, 88.8% answered in time, 7.8 s average wait, 71.4% occupancy | 14 on phones, 20 on the rota, 88.8% answered in time, 7.8 s average wait, 71.4% occupancy | Erlang C formula worked example, Call Centre Helper Read 2026-09-06 |
| Call Centre Helper | 500 calls in 30 minutes, 360 seconds each, 80% answered within 20 seconds, and nobody worked past 90%. | 112 on phones, 160 on the rota, 91.4% answered in time, 5 s average wait, 89.3% occupancy | 112 on phones, 160 on the rota, 91.4% answered in time, 5.0 s average wait, 89.3% occupancy | How to calculate occupancy in the contact centre, Call Centre Helper Read 2026-09-06 |
Note that the Westbay case sets an average wait of 30 seconds, not “80% answered in 20 seconds”. Read as an 80/20 target it gives a different answer: at 23 people the 20-second service level is about 70%. The two targets are different promises, which is why the calculator makes you pick one.
How it works underneath
Everything starts with offered load, measured in erlangs: the calls arriving multiplied by how long each takes, divided by the length of the period. A hundred calls of three minutes in half an hour is ten erlangs, which means ten people would be busy every second of it with nothing to spare. Ten people is therefore the floor nobody can staff below, and the whole question is how many more than ten you need so that callers are not waiting forever.
From the load and a headcount, Erlang B gives the chance every person is busy, and Erlang C turns that into the chance a caller has to wait at all. Both are computed here by the iterative recurrence B(n) = A·B(n−1) / (n + A·B(n−1)) rather than by the textbook expression with factorials in it. The two are the same mathematics; only one of them survives contact with a computer. Powers and factorials overflow a double-precision number somewhere around 170 people and start losing accuracy well before that, while every value in the recurrence stays between 0 and 1.
The wait figures follow from there. The average wait across every caller is the chance of waiting multiplied by the handling time over the spare capacity. The average wait of the callers who actually wait leaves out everybody answered instantly, and is several times larger, which is why this page prints both. A tool that shows you eight seconds when the people who wait are waiting forty-five has told you something true and useless.
Then two corrections that do different jobs at different points. Occupancy is a property of the available agents, and capping it can force the headcount up on its own. Shrinkage is applied last and only converts “on phones” into “on the rota”. Mixing them up is the most common way a staffing figure goes wrong, so the calculator reports which of the two, or neither, actually set your number.
All of it runs in your browser, in a few dozen floating-point operations. There is no endpoint behind this page: your call volumes, handling times and shrinkage describe how your business runs, and they are none of ours.
Bringing a day of your own
The file the tool reads is a CSV with a label, a call count, and optionally a handling time, one row per period, up to 96 of them, which is a full day at quarter-hour resolution. The first row may be a header and is skipped. A semicolon-separated file is read correctly too, because that is what a spreadsheet in a French locale writes.
The result you download carries the numbers and every assumption behind them in the same file: the volumes, the target, the shrinkage, the occupancy ceiling and the model's own limitations. A staffing figure pasted into a plan without those is a number nobody can check afterwards, including whoever produced it.
If you would rather read the reasoning first, the worked example behind all of this is in how many people do you need to answer calls.
Questions
How many people do I need to answer my calls?
It depends on three things and not on your total call volume: how many calls arrive in your busiest stretch, how long each one takes including the work afterwards, and how long you are willing to make somebody wait. Ten calls an hour of three minutes each needs one person free if you accept a long wait, and two if you do not. The calculator above works it out, and the number it gives you is people free and on the phones, not people employed.
What is the difference between the agents required on phones and the people I schedule?
Nobody is on the phones for every minute they are paid for. Breaks, training, meetings, holidays and leave are all real, and the share of paid time they take up is called shrinkage. If fourteen agents need to be on phones and three in every ten paid minutes go elsewhere, you need twenty on the rota to keep fourteen on phones. Shrinkage never changes how many agents need to be on phones; it changes how many you schedule to get there.
What is occupancy, and why is 100% a bad target?
Occupancy is the share of an available agent’s time actually spent on calls. It sounds like a number you would want at 100%, and at 100% the queue never empties and the wait grows without limit. Higher occupancy leaves less recovery time between calls. An appropriate ceiling depends on workload, call complexity, and how the team works; 85% is an example setting, not a universal threshold. The calculator holds occupancy below a ceiling you set, and tells you when that ceiling, rather than your answer-time target, is what set the headcount.
Why does one more person change the wait so much?
Because the wait does not fall in a straight line. Near the point where work arrives about as fast as it can be finished, each extra person absorbs a share of the queue that the people already there could not, so the wait drops steeply. Further out the same extra person changes very little. That is why a team of four feels transformed by a fifth and a team of forty barely notices a forty-first, and it is the single most useful thing this model tells a small business.
Does this account for callers who hang up?
No, and that is the model's main limitation. Erlang C assumes every caller waits as long as it takes. Abandonment can shorten the observed queue, but repeat calls, demand spikes, and routing restrictions can change staffing needs in either direction. Compare this estimate with observed operations; it is not a guaranteed upper bound.
Can I use this for a team that also answers chats and email?
Not directly. This model assumes one person handles one call at a time, start to finish, in the order the callers arrived. Somebody handling three chats at once, or picking work off a shared inbox between calls, is doing something the arithmetic does not describe. It also does not describe skills-based routing, where only some of the people can take a given call. Use it for the phone line.
Once you know the number
This tells you how many agents need to be on phones. It does not tell you which of them gets the next call, what a caller hears while they wait, or where a call goes when the answer is that nobody is free right now. Those are the parts a phone system decides, and no software reduces the number above.