Erlang C is the queueing formula that sits underneath almost every contact centre staffing tool in existence. It takes three things, how many contacts arrive, how long each takes to handle, and how quickly you want to answer, and returns the number of agents you need. Understanding what it does, and what it assumes, is the difference between using a staffing tool and being used by one.
Step 1: convert demand into workload
Everything starts with traffic intensity, measured in erlangs:
Traffic intensity (A) = (contacts in interval x AHT in seconds) / interval length in seconds
Example: 250 calls in a 30-minute interval with a 240-second AHT.
A = (250 x 240) / 1,800 = 33.33 erlangs
One erlang is one hour of work per hour, so 33.33 erlangs means you need 33.33 agents' worth of continuous handling time just to keep up on average. It also means 33 agents can never be enough: the queue would grow without limit. Erlang C requires agents > A before it will return a finite answer at all.
Step 2: the probability of waiting
Erlang C calculates the probability that an arriving contact finds every agent busy and has to queue. The formula is usually written recursively, via Erlang B, because the factorials in its direct form overflow quickly at realistic agent counts. What matters for practitioners is the shape of the answer, not the algebra: as you add agents above A, the chance of queueing falls very fast at first, then flattens out.
Step 3: service level and ASA
From the probability of waiting, P(W), two familiar metrics follow:
Service level = 1 - P(W) x e^(-(agents - A) x target answer time / AHT)
ASA = P(W) x AHT / (agents - A)
Continuing the example, with 33.33 erlangs of workload and an 80% in 20 seconds target, the model returns 39 agents. At 39 agents:
- Service level: just over 80% answered within 20 seconds
- Occupancy: 33.33 / 39 = 85.5%
- ASA: a handful of seconds
Why extra agents help so unevenly
This is the single most useful intuition Erlang C gives you. Starting from 34 agents against 33.33 erlangs:
- Agent 35 might move service level by twenty points or more
- Agents 36 to 39 each add several points
- Agent 45 adds a fraction of a point
- Agent 50 adds almost nothing measurable
Two consequences follow. First, a 98% service level target costs vastly more than 80%, and the last few points are the most expensive headcount you will ever buy. Second, being one or two agents short in a single interval causes a disproportionate collapse in customer experience, which is why intraday adherence and shrinkage control matter so much more than the annual forecast being perfect.
Then apply shrinkage
Erlang C gives you agents on the phone. It says nothing about breaks, absence or training. Convert to headcount afterwards:
Staff to schedule = required agents / (1 - shrinkage %)
39 agents at 30% shrinkage = 39 / 0.70 = 56 people rostered. Multiplying by 1.30 instead gives 51 and understaffs you by five people.
What Erlang C assumes, and where it breaks
Every one of these assumptions is wrong to some degree in a real operation. The model is still useful; you just need to know which way each error pushes you.
- No abandonment. Erlang C assumes every caller waits forever. Real callers hang up, which removes workload, so actual service level is usually slightly better than predicted. Erlang A models abandonment if you need it.
- Random (Poisson) arrivals. Fine for most inbound queues. Wrong for scheduled callbacks, marketing bursts, or an IVR that releases queues in batches.
- Steady state within the interval. Model 15 or 30-minute intervals, never a whole day at once. A day-level average hides the peaks entirely.
- Interchangeable agents. Heavy skill-based routing means you have several small queues, not one big one, and small queues are much less efficient. Model each skill separately, or use simulation.
- Immediate answer when free. Delays from wrap-up drift or slow desktop load are effectively extra AHT. Measure AHT to include them.
- Voice-shaped work. Concurrent chat, email backlogs and deferrable work do not obey Erlang C. Use concurrency-adjusted models for chat and deferred-work models for email.
Using it well in practice
Run Erlang C at interval level for every 15 or 30 minutes of the operating day, apply an interval-level shrinkage profile, then build rosters against that requirement curve rather than a daily average. Re-run it whenever AHT or volume assumptions change, and sanity-check occupancy in the output, if the model returns occupancy above 92%, your plan has no room for forecast error.
You can run all of this in the free Erlang C staffing calculator, or work backwards with the service level calculator to see what the agents you actually have will deliver.