Erlang C Staffing: Why 16 Agents Become 23 Staff

The short answer: Erlang C gives you seats, not headcount

Erlang C tells you how many agents must be logged in and available during an interval to hit a service level target. It does not tell you how many people to hire or schedule, because every paid hour includes breaks, coaching, meetings, sick days and system downtime. For a queue receiving 120 calls an hour with a 6-minute average handle time and an 80/20 target (80% of calls answered within 20 seconds), Erlang C returns 16 agents. At 30% shrinkage you have to schedule 23 people to keep 16 available. The gap between those two numbers is where most small-team service levels quietly fall apart.

This guide walks through that example end to end, with the arithmetic laid out so you can repeat it on a spreadsheet, and then shows what happens when the shrinkage or volume assumption is wrong. If you would rather plug numbers in directly, the Erlang C calculator on this site runs the same model. The calculations below were worked out for this guide with the standard formulas, not copied from a vendor tool, so you can check them against any calculator you trust.

Step 1: Convert volume and handle time into Erlangs

Traffic intensity, measured in Erlangs, is the amount of work arriving per hour expressed as agent-hours. The formula is calls per hour multiplied by average handle time in minutes, divided by 60. Call Centre Helper's worked example uses the same approach, converting 100 calls per half hour at 180 seconds each into 10 Erlangs [Call Centre Helper, Erlang C formula worked example, checked 2026-09-24].

For our queue: 120 calls per hour x 6 minutes = 720 minutes of work per hour, or 12 Erlangs. That is the theoretical minimum, the number of agents who would be busy 100% of the time if calls arrived in a perfectly even stream. Real calls arrive in clumps, so you always need more than 12. The question is how many more.

Step 2: Find the agent count that hits your service level

Erlang C calculates the probability that a caller has to wait, and from that the share of calls answered inside your target time. The service level is 1 minus the wait probability times e raised to the power of minus the surplus agents (agents minus Erlangs) times target seconds over handle time seconds. The table shows how sharply the curve bends.

Fifteen agents miss the 80% target by seven points. Sixteen clears it with room to spare and about 20% of callers waiting at all. Each extra seat after that buys a shrinking gain in service level and costs a full agent salary, which is why the target itself is a business decision rather than a technical one. Occupancy is worth reading alongside it: sustained occupancy above 85% risks burning agents out, the same burnout warning Call Centre Helper attaches to its own worked example.

Step 3: Turn 16 seats into a schedule with shrinkage

Shrinkage is the share of paid time agents are not available to take calls. Call Centre Helper reports that most contact centre professionals see it land between 30% and 35%, and cites a Dimension Data benchmarking figure of 35% [Call Centre Helper, contact centre shrinkage, checked 2026-09-24]. The conversion is division: staff to schedule = agents required divided by (one minus shrinkage).

The trap is adding the percentage instead. Call Centre Helper's own warning uses 70 agents at 30% shrinkage: adding 30% gives 91 and leaves you short, while 70 / 0.7 gives the correct 100. The same mistake on our queue looks like this.

At 20% the two methods land within a person of each other (19.2 against 20 after rounding), which is exactly why the wrong one survives in spreadsheets. The gap opens as shrinkage climbs, and at 35% the shortcut leaves you three people short before a single call arrives.

What a wrong shrinkage guess does to service level

Suppose you plan on 20% shrinkage and schedule 20 people, because that number came from a template. Reality turns out to be 30%. Only 14 of your 20 are actually available, and the Erlang C service level for 14 agents against 12 Erlangs is about 57%. Occupancy jumps to 86%. If real shrinkage is 35%, 13 agents are available, the service level drops to about 33%, and occupancy hits 92%.

No report ever flags the shrinkage assumption as wrong. What the team sees is a queue that will not clear, agents who never get a break, and a manager asking why the calculator was off. The calculator did its job; the input was ten points optimistic. This is why measuring shrinkage from your own timesheets, split into breaks, training, meetings, absence and downtime, beats any industry default.

Volume forecast error hurts faster than you expect

Erlang C is also sensitive to the volume input. Holding the handle time at 6 minutes, a forecast that is 10% low (132 calls an hour, 13.2 Erlangs) needs 17 agents on the phones, one more than the baseline 16. A forecast that is 20% low (144 calls an hour, 14.4 Erlangs) needs 19. At 30% shrinkage, that 20% miss means 19 seats on the phones and 28 people on the schedule against the original 23: five more heads, for a forecast error most teams would call a rounding error.

Two habits help. Forecast by half-hour interval, not by day, because Erlang C assumes steady arrivals within the interval it is given. And keep a record of forecast error by hour so the buffer you add is based on how wrong you have actually been. Tools that automate this are covered in our guide to contact center scheduling software, and the metrics you would watch afterwards sit in the contact center analytics software comparison.

Where Erlang C stops being a safe answer

Erlang C assumes callers wait as long as it takes and that calls arrive in a statistically steady pattern. Soon's overview of the three common models describes Erlang C as a fast baseline for stable queues where customers wait until service, notes that Erlang A adds customer patience and abandonment, and says simulation is stronger when channels, routing and changing priorities interact [Soon, Erlang C vs Erlang A vs simulation, checked 2026-09-24].

In practice that means three warning signs. If a large share of callers hang up before an agent answers, the plain model is misreading your queue. If agents handle several chats at once, a single-queue voice model is a poor fit; Soon lists concurrency among the cases where simulation does better. If the same people cover phones, chat, email and back-office work, a single queue model misses how those tasks compete for the same hours. In any of those cases, treat the Erlang C number as a starting point to compare against real interval data, not as the answer.

Frequently asked questions