Erlang C calculator: how many call center agents do I need?
Enter the calls you expect in an interval, your average handle time and your service level target. The calculator returns the agents you need on the phones, the people to schedule after shrinkage, and the service level, speed of answer, occupancy and chance of waiting you can expect at that staffing level.
Quick answer
An Erlang C calculator turns call volume into staffing. Traffic in Erlangs is calls per interval × average handle time ÷ interval length. Erlang C then finds the fewest agents whose predicted service level meets your target, and dividing by (1 − shrinkage) gives the people to schedule. Example: 120 calls in 30 minutes at 240 seconds is 16 Erlangs; 20 agents answer 81.7% within 20 seconds; with 30% shrinkage you schedule 29.
Workload
Targets and shrinkage
Agents needed on the phones
People to schedule with shrinkage
Set by your service level target.
Agents vs service level vs speed of answer
The first row is the recommended staffing. Each extra agent improves service, by less each time, and lowers occupancy.
| Agents on the phones | To schedule | Service level | Average speed of answer (s) | Occupancy | Chance of waiting |
|---|---|---|---|---|---|
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
How this calculator works
Traffic A in Erlangs is calls × average handle time ÷ interval length in seconds. For each agent count N above A, the calculator computes the Erlang B blocking probability with the stable recursion B(k) = A·B(k−1) ÷ (k + A·B(k−1)), converts it to the Erlang C probability of waiting, P(wait) = N·B ÷ (N − A·(1 − B)), and derives service level = 1 − P(wait)·e−(N−A)·T÷AHT, average speed of answer = P(wait)·AHT ÷ (N − A) and occupancy = A ÷ N. The recommendation is the smallest N that meets the service level target and, if you set one, keeps occupancy at or below the cap. People to schedule = N ÷ (1 − shrinkage), rounded up.
Results are model estimates based only on the numbers you enter. Erlang C assumes random arrivals, callers who never hang up and agents who can all take every call; real queues differ, as explained below. Nothing you enter leaves your browser.
What is Erlang C?
Erlang C is a queueing formula published by the Danish engineer A. K. Erlang in 1917 for telephone exchanges. It answers one question: if calls arrive at random and wait in a single queue for the next free agent, what is the chance a caller has to wait at all? From that one probability you get the numbers a contact center plans with: the share of calls answered within a target time (service level), the average speed of answer (ASA) and agent occupancy.
It needs only three inputs: traffic, the number of agents and the average handle time. Traffic is measured in Erlangs. One Erlang is one hour of call work per hour, or the number of agents that would be busy all the time if calls arrived perfectly evenly:
Traffic (Erlangs) = calls in the interval × AHT in seconds ÷ interval length in seconds.
That number is the floor, not the answer. With exactly as many agents as Erlangs, the queue grows without limit, because random clusters of calls create waits that idle time never wins back. Erlang C tells you how far above the floor you must staff for the service you want. Our guide How many call center agents do I need? walks through the reasoning step by step.
Worked example: 120 calls in 30 minutes
The calculator opens with this example, so you can check it against the table above. A support queue expects 120 calls between 10:00 and 10:30. AHT, including after-call work, is 240 seconds. The target is 80/20: 80% of calls answered within 20 seconds. Shrinkage is 30%.
- Traffic: 120 × 240 ÷ 1,800 = 16 Erlangs. Sixteen agents is the floor.
- Agents on the phones: 19 agents answer 70.9% within 20 seconds, short of the target. 20 agents answer 81.7%, with an ASA of about 15 seconds, 80% occupancy and a 25.6% chance that a caller waits at all. The answer is 20.
- People to schedule: 20 ÷ (1 − 0.30) = 28.6, rounded up to 29 people rostered for that half hour.
| Agents | Chance a caller waits | Answered within 20 s | ASA | Occupancy |
|---|---|---|---|---|
| 16 | Unstable: the queue grows without limit | |||
| 17 | 73.7% | 32.2% | 177 s | 94.1% |
| 18 | 53.1% | 55.0% | 64 s | 88.9% |
| 19 | 37.4% | 70.9% | 30 s | 84.2% |
| 20 | 25.6% | 81.7% | 15 s | 80.0% |
| 21 | 17.1% | 88.7% | 8 s | 76.2% |
| 22 | 11.1% | 93.3% | 4 s | 72.7% |
Two things stand out. Going from 17 to 18 agents lifts service level by 23 points; going from 21 to 22 lifts it by under 5. And staffing does not scale in a straight line: if calls rise 10% to 132, keeping 20 agents drops service level to about 61%, and you need 22 to get back above 80%. Cutting AHT by 30 seconds, to 210, does the opposite: 18 agents then reach about 84%.
How to use the results with shrinkage
Erlang C tells you how many agents must be logged in and available in the interval. It knows nothing about breaks, training, one-to-ones or people off sick. Shrinkage closes that gap:
People to schedule = agents on the phones ÷ (1 − shrinkage), rounded up.
Divide, do not add. Adding 30% to 20 gives 26, which leaves you short: 30% of 26 people are away, and only 18.2 are on the phones. Dividing by 0.7 gives 28.6, so 29.
- Use measured shrinkage. Many contact centers plan with roughly 25% to 35%. Measure yours from schedule adherence and absence data and update it monthly.
- Shrinkage varies by interval. Breaks and meetings cluster mid-shift; training clusters on quiet days. If you know an interval carries more planned shrinkage, use a higher figure for it.
- Run every interval. A day is not one calculation. Run each 15- or 30-minute interval, then build shifts that cover the curve. The peak interval, not the daily average, decides how many people start at 09:00.
Service level, ASA and occupancy: which target should drive staffing?
| Metric | What it measures | Typical planning value | Watch out for |
|---|---|---|---|
| Service level | Share of calls answered within a target time | 80/20; 90/30 for priority lines; 70/30 for low-priority queues | Says nothing about the callers who waited longest |
| Average speed of answer | Mean wait across all calls, including those answered at once | Derived from your service level target | An average hides a long tail of waits |
| Occupancy | Share of logged-in time agents spend handling calls | Cap around 85% to 90% | Above the cap, absence and attrition rise, which raises shrinkage |
| Probability of waiting | Share of callers who hear hold music at all | Result, not usually a target | Useful when you announce queue position or offer callbacks |
Most teams set the service level target and let ASA follow. Add an occupancy cap when the queue is large: big teams can meet 80/20 at very high occupancy, which looks efficient and wears people out. When the cap decides the agent count, the calculator says so under the result. For how these metrics fit with the rest of your reporting, see call center KPIs, metrics and formulas.
Assumptions and limits of Erlang C
Erlang C is the standard first answer for inbound staffing, and it rests on assumptions real queues break:
- Nobody hangs up. Erlang C assumes infinite patience. Real callers abandon, and each abandoned call removes work, so with meaningful abandonment Erlang C recommends slightly more agents than you need. Erlang A adds an average patience time and models abandonment; simulation goes further. If your abandon rate is low, the difference is small and errs on the safe side.
- Calls arrive at random at a steady rate within the interval. A marketing email at 10:05 or a service outage breaks this. Shorter intervals reduce the error.
- Every agent can take every call. With languages, skills or several queues, agents are not interchangeable. Calculate per skill group and adjust for agents who cover more than one.
- Calls are served in order, one at a time. Callbacks, priority queues, overflow and blended outbound work all change the real picture.
- Handle time does not depend on load. In practice AHT often rises when agents are rushed or queues are long.
| Model | What happens to a caller who cannot be served at once | Use it for |
|---|---|---|
| Erlang B | Blocked and lost (busy signal) | Sizing trunks and channels |
| Erlang C | Waits in queue for as long as it takes | Inbound agent staffing (this calculator) |
| Erlang A | Waits, but may hang up after a random patience time | Queues with significant abandonment |
None of this makes the model useless. Start with Erlang C, then compare its predictions with your measured service level and abandonment per interval, and adjust your inputs where reality differs.
Where the inputs should come from
The calculator is only as good as the forecast you give it. Calls per interval, AHT and the service level you actually delivered should come from your contact center platform, per queue and per interval, not from monthly averages. In DialerBee, each inbound queue has its own SLA target and threshold, queue depth and queue stats are live on the wallboard, and queue performance and inbound call reports cover the period afterwards. Agents handle inbound queues and outbound campaigns from one desktop.
Two levers reduce the agents you need without hurting service. The first is handle time: as the example showed, 30 seconds off AHT saved two agents per half hour. The second is the number of calls reaching the queue. Routine calls such as opening hours, bookings and FAQs can be answered by an AI voice agent, which hands calls that need a person to your team; in DialerBee a number is pointed at an AI voice agent the same way it is pointed at a queue. If that fits your business, the AI receptionist page explains what it handles. Rerun this calculator with the lower call volume to see the effect on staffing, and see pricing for per-agent plans.
See the queue data behind the forecast
We will walk through inbound queues, SLA targets, the wallboard and reports on a demo tenant.
FAQ