Skip to main content
TurnellaBeta
Inbound voice staffing

Erlang C explained — the contact centre staffing formula

Erlang C is the mathematical foundation of contact centre staffing. It answers one question: given this volume of calls and this average handle time, how many agents do you need to answer a specific proportion of calls within a specific time?

What problem does Erlang C solve?

Imagine your contact centre receives 120 calls in a 30-minute interval, each lasting an average of 4 minutes. If you schedule exactly the right number of agents, some calls will wait in a queue. Too few agents and the queue grows without bound. Too many and you're paying for idle time.

Erlang C tells you the probability that an arriving call will join a queue, and therefore the probability that it will be answered within any given time threshold at a specific agent count. Work backwards from your service level target (say, 80% answered within 20 seconds) to find the minimum agent count that achieves it.

The three inputs

📞

Call volume (contacts per interval)

The number of inbound contacts in the interval you're planning for — typically 30 minutes. Use your historical average for that day-of-week and time slot, not a daily total.

Common mistake: Don't use daily volume and divide by 8. The Erlang formula is non-linear — you must compute requirements interval by interval.

⏱️

Average Handle Time (AHT)

The average time an agent spends on a single contact, including talk time and after-call work (ACW). Usually measured in seconds. If your calls average 4 minutes of talk and 1 minute of ACW, AHT = 300 seconds.

Common mistake: Include after-call work. If you only use talk time, you'll under-staff: agents don't pick up the next call until ACW is done.

🎯

Service level target

Your threshold: X% of calls answered within Y seconds. Common examples: 80% in 20 seconds, 80% in 30 seconds, 90% in 15 seconds. This is what Erlang C solves for.

Common mistake: Service level and ASA (Average Speed of Answer) are different measures. Erlang C directly solves for service level.

How the formula works

Erlang C models a queueing system called M/M/N: Markovian arrivals (Poisson process), Markovian service times (exponential distribution), and N servers. The core calculation has two steps:

Step 1: Traffic intensity (Erlangs)

A = (λ × AHT) ÷ T

Where λ = calls per interval, AHT = average handle time in seconds, T = interval length in seconds. For 120 calls in 30 minutes with 4-minute AHT: A = (120 × 240) ÷ 1800 = 16 Erlangs. You need at least 17 agents to prevent the queue growing without bound.

Step 2: Erlang C probability

C(N, A) = P(queuing) = formula over factorial sums

Erlang C gives the probability that a call arriving into the system will have to wait, meaning all N agents are busy. If C = 0.25, 25% of calls queue. This probability is then used to compute service level for any answer-time threshold t.

Step 3: Service level

SL(t) = 1 − C(N, A) × e^(−(N−A) × t / AHT)

Where t is the target answer time in seconds. The formula solves: given N agents and an Erlang C probability, what fraction of calls are answered within t seconds? Flip it: find the smallest N where SL(t) ≥ your target.

Worked example

Scenario: Monday 09:00–09:30 planning

Calls this interval120
Average Handle Time240 seconds (4 min)
Service level target80% in 20 seconds
Shrinkage25%
1.Traffic intensity: (120 × 240) ÷ 1800 = 16 Erlangs. Minimum agents: 17.
2.At 18 agents: Erlang C probability ≈ 0.72. SL(20s) ≈ 62%, below target.
3.At 20 agents: Erlang C ≈ 0.52. SL(20s) ≈ 78%, close but still below.
4.At 21 agents: Erlang C ≈ 0.44. SL(20s) ≈ 82%. Target met. Seated requirement = 21.
5.Apply shrinkage: 21 ÷ (1 − 0.25) = 28. Scheduled headcount = 28.

Assumptions — and where they break down

Assumption: Callers never abandon

Reality: Real callers hang up after waiting too long. Erlang C over-states requirements slightly, which gives a conservative (safer) staffing estimate. Erlang B (Erlang C's sibling) models abandonment but is less commonly used in contact centres.

Assumption: Arrivals are Poisson (random)

Reality: True at the aggregate level for large volumes. For very low-volume intervals (fewer than 10 calls), the Poisson assumption is less reliable — use higher safety margins.

Assumption: Service time is exponential

Reality: Real AHT distributions are typically lognormal, not exponential. The impact is modest for planning purposes: Erlang C is robust to modest AHT variation.

Assumption: Steady state

Reality: Erlang C assumes a stable, continuous arrival rate throughout the interval. For very short intervals or rapidly changing demand, interval-by-interval planning (which Turnella does) is more accurate than daily planning.

When not to use Erlang C

Erlang C is wrong for these channels:

Live chat

Chat agents handle multiple sessions simultaneously. Erlang C models one agent → one call. Use a concurrency model: divide offered load by the maximum concurrent sessions per agent.

Email / tickets

Email doesn't queue in real time — it accumulates in a backlog and is worked down at a throughput rate. Use a flow model: incoming volume ÷ (throughput per agent × available hours).

Back-office / document processing

Same as email: backlog accumulates, throughput clears it. Daily/weekly planning with throughput targets, not interval-level Erlang C.

Outbound calling

Outbound uses agent occupancy and predictive dialler models. Erlang C models inbound queuing — completely different math.

Turnella applies the right model automatically: Erlang C for voice, concurrency for chat, backlog flow for email and tickets.

Erlang C — frequently asked questions

What is Erlang C?

Erlang C is a mathematical formula that calculates the probability that an arriving contact will be placed in a queue, and from that, the minimum number of agents needed to achieve a given service level (e.g. 80% of calls answered within 20 seconds). It was developed by Danish engineer A.K. Erlang in 1917 for telephone exchange design.

Is Erlang C accurate for contact centres?

Erlang C is accurate under its assumptions: Poisson arrivals (random, independent), exponential service times, infinite queue patience (callers never hang up), and steady-state conditions. Real contact centres violate some of these. Callers do abandon, calls are not perfectly random, and AHT varies. Erlang C tends to overstate requirements slightly because it assumes infinite patience. This gives a conservative (safe) estimate, which is generally preferable in staffing decisions.

Can I use Erlang C for chat, email, or back-office?

No. Erlang C models a real-time queue where one agent handles one contact at a time. Chat agents handle multiple sessions simultaneously, so the correct model uses Little's Law with a concurrency factor. Email and tickets accumulate in a backlog, not a real-time queue, so the correct model is a flow model: incoming volume vs. throughput capacity vs. SLA deadline. Using Erlang C for these channels will give the wrong answer.

What does 'traffic intensity' or 'Erlangs' mean?

Traffic intensity (measured in Erlangs) is the product of call rate and average handle time, expressed in consistent units. For a 30-minute interval: Erlangs = (calls per interval × AHT in seconds) ÷ 1800. It represents the average number of agents that would be occupied if the agents were infinitely fast to pick up. If traffic intensity is 8 Erlangs, you need at least 9 agents to prevent queue collapse.

Try the free Erlang C calculator

Enter your call volume, AHT, and service level target. Get the exact agent count and see the calculation explained.

Related