Erlang C Calculator for Call Center Staffing

Practitioner guide

Understanding an Erlang C staffing calculation

What is Erlang C?

Erlang C is a queueing formula named after A. K. Erlang, the Danish engineer who published the underlying analysis of telephone traffic in 1917. For a given number of agents handling a steady stream of inbound contacts, it predicts the probability that a contact has to wait, how long contacts wait on average, and what share of contacts are answered within a chosen time.

Workforce planners usually run it the other way round: start from the expected contacts and a service-level target, and find the smallest number of agents that meets the target in one interval. In queueing theory the model is known as the M/M/N queue.

With A as the workload in Erlangs and N as the number of agents (more than A), the probability that a contact has to wait is:

P(wait) = [A^N ÷ N! × N ÷ (N − A)] ÷ [sum of A^k ÷ k! for k = 0 to N − 1 + A^N ÷ N! × N ÷ (N − A)]

The service-level formula further down this page uses P(wait), and the worked example puts real numbers through both.

What is an Erlang?

An Erlang is a unit of workload. One Erlang is enough work to keep one agent continuously busy for the whole interval. Offered workload is calculated as:

workload (Erlangs) = contacts offered × average handle time ÷ interval length

With 100 contacts, a 180-second handle time and a 30-minute interval, the workload is 100 × 180 ÷ 1,800 = 10 Erlangs. Ten agents would be busy all of the time, with no capacity left to absorb the natural clustering of arrivals. That is why the requirement is always above the workload: with 10 agents or fewer the model has no steady state, and waiting times keep growing through the interval.

How contact volume and AHT affect staffing

Contacts and handle time both enter the calculation through the workload, but the staffing requirement does not move in proportion to it. With the same 100 contacts, raising the handle time from 180 to 240 seconds increases the workload by a third, from 10 to 13.33 Erlangs. The requirement for 80% within 20 seconds rises from 14 to 17 agents, which is about a fifth more, and occupancy at the requirement rises from 71.4% to 78.4%.

Larger workloads can be served at higher occupancy for the same target, so a requirement has to be recalculated whenever the inputs change. Scaling a previous answer up or down gives the wrong number.

What service level means

A service-level target has two parts that belong together: a percentage and an answer-time threshold, such as 80% of contacts answered within 20 seconds. Changing either part changes the requirement. For the 10-Erlang example:

Erlang C predicts the share of arriving contacts that are answered within the threshold:

service level = 1 − P(wait) × e^{−(agents − workload) × threshold ÷ AHT}

Because the model assumes nobody abandons, the usual ways of reporting service level (answered within the threshold divided by contacts offered, or by contacts answered) give the same figure inside the model. In your ACD reports they can differ, and the reported number depends on which definition your operation uses.

A target of 100% cannot be met at any finite staffing level, because some contacts always have a chance of waiting. Elaris reports such a target as unattainable instead of returning an ever larger number.

How occupancy affects staffing decisions

Model occupancy is workload divided by agents: the share of agents’ time spent handling contacts. In the example, 10 Erlangs across 14 agents is 71.4%. Occupancy is an outcome of an Erlang C calculation, not an input to it.

Many operations also plan to a maximum occupancy as a policy. Elaris treats that maximum as a separate constraint alongside the service-level target, and the requirement is the smallest staffing level that satisfies every active constraint at once. The result says which constraint controlled it.

For example, a target of 50% within 60 seconds on the same workload needs only 11 agents, but occupancy would then be 90.9%. With an 85% occupancy limit, the requirement becomes 12 agents (10 ÷ 0.85, rounded up). The result names occupancy as the controlling constraint and flags that the service-level answer alone would have exceeded the limit. With the stricter 80% within 20 seconds target, service level already needs 14 agents at 71.4% occupancy, so the same limit does not change the answer.

How shrinkage differs from workload

Erlang C tells you how many agents need to be handling contacts during the interval. That is net staffing. People are also paid for time away from contacts: breaks, meetings, training, coaching and other planned activity. That is shrinkage, and it belongs in a separate step after the Erlang C result is final:

gross staffing = net staffing ÷ (1 − planned shrinkage rate)

With 30% planned shrinkage, 14 net agents become 14 ÷ 0.70 = 20.0 agent-equivalents to schedule. Two common shortcuts give different numbers:

• Multiplying instead of dividing (14 × 1.30 = 18.2) understates the requirement.
• Inflating handle time to “include” shrinkage (180 ÷ 0.70 ≈ 257.1 seconds) gives 18 agents, because it changes the queueing workload itself. Shrinkage is not workload, and it never enters the queueing calculation.

Planned shrinkage and unplanned absence are also kept apart. Unplanned absence is something you observe afterwards. It belongs in a requirement only as a deliberate, separately labelled allowance. Gross staffing for an interval is still not FTE: converting it needs the contracted hours that define an FTE in your organization.

Why interval duration matters

Erlang C assumes arrivals come at a steady rate within the interval being staffed. The inputs therefore have to describe that interval: the contacts expected in that 15, 30 or 60 minutes, and the handle time for those contacts. The interval length is an explicit input because the same count means a different workload over a different length of time.

The same 100 contacts spread over an hour instead of 30 minutes are 5.00 Erlangs, and the requirement for 80% within 20 seconds is 8 agents. That is not half of 14. The model should never be applied to a daily or weekly total: averaging a day hides the peaks you have to staff for, and requirements from different intervals or queues cannot simply be added together.

Erlang C assumptions and limitations

Erlang C is a model, and its results hold only as far as its assumptions do. It assumes:

• contacts arrive at random, at a constant average rate within the interval;
• handle times vary randomly around the average handle time (exponentially distributed);
• agents are interchangeable, and each handles one contact at a time;
• contacts are answered first come, first served;
• nobody abandons: every contact waits until it is answered;
• nobody is blocked: there is no busy signal or queue limit;
• each interval is treated on its own, with no queue carried over from the interval before.

Real contact centers depart from these in familiar ways. Customers hang up. When abandonment is material, Erlang C typically overstates the staffing requirement, and models that include caller patience, such as Erlang A, are designed for that situation. This calculator does not implement them. Other departures include callers retrying after abandoning, agents handling several chats at once, asynchronous work such as email, skills-based routing across queues, and agents who work at different speeds.

The result is also only as good as the forecast it is given. A requirement calculated for the expected volume does not cover volume above that forecast. An Erlang C result is an estimate under stated assumptions. It is not a guarantee of real-world performance.

A worked example, step by step

One interval from start to finish: 100 contacts in 30 minutes, a 180-second handle time and a target of 80% answered within 20 seconds.