An Erlang C calculator tells you how many agents a queue needs to answer a target share of calls within a target time. The industry default is 80% of calls answered in 20 seconds (Call Centre Helper), and Erlang C is the formula that turns that promise into a headcount.
It is worth understanding rather than just running, because the number it returns is wrong in two specific ways that catch people out — and both are recoverable once you know where they come from.
What Erlang C actually models
Erlang C answers one question: given a volume of calls, an average handling time, and a number of agents, what fraction of callers wait longer than t seconds?
It needs three inputs.
Offered load, measured in erlangs, is calls per hour multiplied by average handling time in hours. A queue taking 500 calls an hour at an average handle time of 363 seconds (Call Centre Helper) is carrying just over 50 erlangs of load. That is the amount of continuous talking the queue represents — roughly 50 agents' worth of conversation, before anything else is accounted for.
Target service level is the promise: answer X% within Y seconds.
Number of agents is what you solve for.
The formula assumes callers queue rather than hang up, that they arrive randomly, and that any agent can take any call. Those assumptions are why the raw answer is never the staffing plan.
The two corrections that matter
Shrinkage
Erlang C gives you agents on the phone. It knows nothing about breaks, training, sickness, coaching or admin. Industry shrinkage runs around 30% of paid hours (Call Centre Helper).
That is not a rounding error. If Erlang C says you need 50 agents on calls, you roster 50 ÷ 0.7 — about 72 people — to have 50 available. Teams that skip this step consistently miss service level and cannot work out why, because the model was right and the roster was not. This is the single most common reason a staffing plan fails in its first week.
Occupancy
Occupancy is the share of logged-in time an agent spends on calls. Erlang C will happily hand you an answer that implies 95% occupancy, and that answer is arithmetically fine and operationally useless — sustained occupancy above roughly 83% burns people out and drives attrition (Call Centre Helper).
If the model returns a plan that runs your team above that ceiling, add agents until it does not. The formula has no opinion about whether people quit.
Why bigger queues are cheaper per call
The counter-intuitive property of Erlang C is that it does not scale linearly. Double the call volume and you need noticeably fewer than double the agents.
This is pooling. In a small queue, an agent finishing a call frequently has nobody waiting, so the idle time is wasted. In a large queue, someone is nearly always waiting, so each agent's spare capacity is absorbed. It is why merging two small queues into one usually improves service level at the same headcount — and why splitting a queue into specialised skills, however sensible it looks on an org chart, quietly costs you agents.
Where the model stops being true
Erlang C assumes callers wait. Real callers abandon, and an abandoning caller frees a slot the model thought was occupied, so Erlang C tends to overestimate the agents you need when abandonment is high. Erlang A extends the model to include it.
It also assumes a steady state within the interval you are modelling. Model in 15- or 30-minute intervals, never a whole day — a day-level average hides the morning peak that actually breaks your service level.
And it assumes homogeneous agents. The moment you have skills-based routing, you are running several small queues, not one big one, and the pooling benefit above works against you.
Running it
The Erlang C calculator takes calls per interval, average handle time and your service level target, and applies the shrinkage and occupancy corrections rather than leaving them to you.
Two other calculators cover the corrections directly: shrinkage if you want to work out your real figure rather than assuming 30%, and occupancy to check a plan is sustainable before you commit to it.
Frequently asked questions
What is an Erlang C calculator used for? Working out how many agents a queue needs to hit a service level target — typically answering 80% of calls within 20 seconds — given call volume and average handle time.
Why does the calculator say I need more agents than my call volume suggests? Because calls arrive randomly rather than evenly. Staffing for the average leaves you short whenever arrivals cluster, which they do constantly.
Should I apply shrinkage before or after the Erlang C result? After. Erlang C returns agents needed on calls; divide that by one minus your shrinkage rate to get the number of people you must roster.
Does Erlang C work for chat or email? Not directly. It assumes one conversation per agent at a time, so concurrency in chat breaks the model. Email is not a queue in the Erlang sense at all.
