Erlang C calculator

What Erlang C actually does

Erlang C answers one question: given a random stream of arriving contacts and a pool of agents, what fraction of callers get answered within T seconds? Staffing calculators run it backwards: they search upward through agent counts until one of them clears your target.

It rests on four assumptions, and knowing them is the difference between using it and being used by it. Contacts arrive randomly (Poisson). Callers queue and wait rather than hang up. Nobody is turned away. All agents are interchangeable and equally able to take the next contact.

The formula

First, offered load in Erlangs: the number of agents you would need if there were no randomness at all, and every agent could be busy every second:

Then the probability that a caller has to wait at all, given N agents. This is Erlang C, and it is built on Erlang B, which is computed by a recursion rather than by factorials; factorials overflow long before you reach the agent counts a real contact center uses:

Service level and average speed of answer both fall out of that, and occupancy is simply load spread across the agents you have:

Notice that every one of these divides by (N − A). If you have fewer agents than Erlangs of load, that term is zero or negative and the model breaks, correctly, because the queue genuinely never clears. Any calculator that returns a tidy service level when N is below A is not doing the maths. That is the single fastest way to check whether a staffing tool is real.

A worked example

250 contacts in a 30-minute interval, 240 seconds AHT, targeting 80% answered in 20 seconds, capped at 85% occupancy, with 30% shrinkage.

1. Offered load. (250 × 240) ÷ 1800 = 33.33 Erlangs. So 34 agents is the first count that could possibly be stable.
2. Search upward. 38 agents gives 77.4%, short. 39 gives 84.2%, which clears the 80% target.
3. Check occupancy. At 39 agents, occupancy is 33.33 ÷ 39 = 85.5%, just over the 85% ceiling. The cap lifts the requirement to 40 agents, where occupancy is 83.3% and service level is 89.1%.
4. Apply shrinkage, last. 40 ÷ (1 − 0.30) = 57.1 rostered FTE.

Two things are worth sitting with. First, the occupancy cap (not the service-level target) is what set the final number, which is common and almost never visible in vendor tools. Second, the gap between 38 and 40 agents is 11.7 points of service level. Erlang C is steep near the target, which is why staffing is an interval-level problem and a daily headcount tells you almost nothing.

Where this goes wrong in practice

The formula is rarely the problem. These are:

• Shrinkage applied in the wrong place. Shrinkage belongs after the queueing maths, converting required productive agents into rostered FTE. Applied inside it, or applied twice, once in the forecast and again in the roster, it silently understates what you need.
• Averaging across intervals. Required staffing for a day is not the average of the intervals, and it is not computed from the day's total volume. Erlang C is non-linear; a peak and a trough do not cancel. Solve every interval separately.
• Ignoring abandonment. Erlang C assumes infinite patience. Where callers abandon quickly it overstaffs, sometimes materially. Erlang A models abandonment and is the better fit for those queues.
• Using it for deferred or concurrent work. Email, tickets and chat with concurrency are not Erlang C problems. Work that carries between intervals needs a workload model, not a queueing one.
• Scheduling to the cap. Occupancy above roughly 85% sustained is an attrition machine. The cap is not a nice-to-have; on high-load intervals it is frequently the binding constraint, as in the example above.

Common questions

What is Erlang C?

A queueing formula that estimates how many agents are needed to answer a given contact volume within a target waiting time. It assumes random arrivals, callers who queue rather than abandon, and no blocking. Derived by A. K. Erlang in 1917 for telephone exchanges, it is still the standard staffing model in workforce management software.

How many agents do I need for 80/20?

It depends on offered load, not raw volume. 250 contacts in 30 minutes at 240s AHT is 33.3 Erlangs and needs 39 agents for 80/20, 40 once an 85% occupancy cap is applied, and 57.1 rostered FTE at 30% shrinkage. Change the AHT and the answer moves substantially; change the interval length and the load changes with it.

Where should shrinkage be applied?

After the queueing maths, never inside it. Erlang C returns the agents who must be productive and available. Rostered FTE = required productive ÷ (1 − total shrinkage). Feeding an already-shrunk headcount back into the formula double-counts it.

What is an occupancy cap and why does it change the answer?

Occupancy is A ÷ N, the share of productive time spent handling contacts. It falls as headcount rises, so a ceiling on occupancy sets a floor on staffing. When the cap requires more agents than the service-level target does, the cap is the binding constraint and should be reported as such.

When is Erlang C the wrong model?

When callers abandon (use Erlang A), when work is deferred or concurrent (use a workload model), when routing is skills-based across genuinely non-interchangeable pools, or when arrivals are not stable within the interval. It is a good default and a bad universal.