The Erlang C inputs that matter are arrival rate, average handle time and your service level target, and a small error in any one of them moves your staffing by two or more agents on a typical desk. The formula is rarely the weak link. The numbers you feed it are.
If you haven’t read my posts on Erlang C scheduling for call centres and mind the gap, the short version is that Erlang C tells you how many agents need to be logged in during each half hour to hit a service level. I’ve come to treat it as a check on my inputs more than a scheduling tool. This post takes the three inputs one at a time, shows what each is worth in agents, and explains how to measure it from your phone system rather than guess.
One worked example does all the work below: 120 calls in a half hour, 300 seconds of handle time and a target of 80% answered in 20 seconds. That needs 25 agents. Every table that follows changes one input and leaves the other two alone, so you can see what each one is worth.
How is the example built, step by step?
Start with the workload, because everything else hangs off it. Traffic is measured in Erlangs, which is simply the hours of work arriving per hour. A half hour is 1,800 seconds, so 120 calls at 300 seconds each is 120 × 300 = 36,000 seconds of work, and 36,000 / 1,800 = 20 Erlangs. Put another way, 20 agents would be busy every single second and nobody would ever be free to answer the next call. That is why the answer is more than 20.
Next comes the chance that a caller has to wait at all. With 25 agents on 20 Erlangs, that probability works out to 0.2091, or about 21% of callers. The long version of that formula is in my Erlang C calculator in Excel post. The short version is a fraction. The top is the chance that all 25 agents are busy at once, weighted by how crowded the queue is. The bottom is that same number plus the chance that fewer than 25 are busy. Here the top is 0.2229 and the bottom is 0.8432 + 0.2229, so 0.2229 / 1.0661 = 0.2091.
The last step turns that waiting probability into a service level. Of the 21% who wait, most are answered quickly, and the fraction still waiting after 20 seconds is the factor e raised to the power of minus (agents minus Erlangs) × target seconds / handle time. That is e^-(25 – 20) × 20 / 300 = e^-0.3333 = 0.7165. So the share of callers who wait longer than 20 seconds is 0.2091 × 0.7165 = 0.1498, and the service level is 1 – 0.1498 = 0.8502, or 85.0%. That clears the 80% target. Try 24 agents and you get 77.2%, which doesn’t. Try 26 and you get 90.4%.
If you want this in Excel, use one row per half hour, and lay it out like this on a single sheet: column A holds the interval, B the offered calls, C the handle time in seconds, D the agents on the schedule, E the traffic and F the waiting probability. In E2, enter =B2*C2/1800. In F2, enter =POISSON(D2,E2,FALSE)*D2/(D2-E2)/(POISSON(D2-1,E2,TRUE)+POISSON(D2,E2,FALSE)*D2/(D2-E2)). POISSON with FALSE returns the chance of exactly D2 agents being busy. With TRUE it returns the chance of D2-1 or fewer. Column G, the service level, is =1-F2*EXP(-(D2-E2)*20/C2), where the 20 is your target answer time. Key in 120, 300 and 25 and the sheet should show 20, 0.2091 and 0.8502. If it doesn’t, the formula is wrong before the inputs are.
How much does the arrival rate change your staffing?
Arrival rate is simply how many calls arrive in an interval. It’s the input everyone argues about, because it’s a forecast, and forecasts are wrong. Here is what being wrong costs on the example, with handle time held at 300 seconds and the target at 80% in 20 seconds:
| Calls in the half hour | Agents needed | Service level at that staffing |
|---|---|---|
| 108 (10% fewer) | 23 | 86.3% |
| 120 (forecast) | 25 | 85.0% |
| 132 (10% more) | 27 | 83.8% |
| 144 (20% more) | 29 | 82.6% |
A 10% miss in either direction is two agents. That’s a manageable swing if you’ve got a flexible schedule and a painful one if you haven’t. But the more useful lesson is how the miss plays out when the staffing is already fixed. Roster 25 agents and let 132 calls arrive: the traffic becomes 132 × 300 / 1,800 = 22 Erlangs, and the service level drops from 85.0% to 64.5%. Let 144 arrive and the traffic is 24 Erlangs, with the service level at 27.2%. The queue doesn’t slide gently, it tips, because the model punishes being short far harder than it rewards being long.
To measure arrival rate properly, count offered calls, which means answered plus abandoned, by half hour, from your ACD or phone switch report. Use four to six weeks of the same weekday, because Monday morning has nothing in common with Thursday afternoon. Strip out one-off spikes such as an outage or a mailing, and keep a note of them so you can add the next one back in when you see it coming. A daily average is the classic mistake here. It hides the half hour that causes the damage.
Why is average handle time the input people get wrong?
Handle time is talk time plus hold plus after-call work. Teams often take talk time from the phone report and forget the wrap-up, which understates the work. The effect is the same size as the arrival rate, here with 120 calls and the same target:
| Average handle time | Agents needed |
|---|---|
| 270 seconds | 23 |
| 300 seconds | 25 |
| 330 seconds | 27 |
| 360 seconds | 29 |
Thirty seconds either way is two agents. Check the arithmetic against the first step: at 330 seconds the work is 120 × 330 / 1,800 = 22 Erlangs, two more than the 20 you started with, so you need roughly two more seats. That’s why handle time targets and staffing models belong in the same conversation. Asking the team to be 10% quicker is worth two seats in the example, and letting handle time drift up by 10% costs two. Hold the 25 agents fixed and a 330 second handle time takes the service level from 85.0% to 63.8%.
Handle time also isn’t flat through the day. The first calls of the morning and the last hour of the evening often run longer or shorter than the middle of the day, so use the figure for the interval you’re planning, not the weekly mean. Measure it from the same report as call volume, and check the definition. Some systems count hold time and some don’t, and some leave out wrap-up. If your definition doesn’t match what the agent actually does between one call and the next, the staffing will be short by exactly that difference. The agent doesn’t care what the report calls it.
What is the cost of a tighter service level target?
The service level target is the one input you choose rather than measure, which makes it the one that’s easiest to set carelessly. Here’s what different targets cost on the same 120 calls and 300 seconds:
| Target | Agents needed |
|---|---|
| 80% in 30 seconds | 24 |
| 80% in 20 seconds | 25 |
| 90% in 20 seconds | 26 |
| 95% in 20 seconds | 28 |
| 80% in 60 seconds | 24 |
Two things stand out. Moving from 80/20 to 90/20 costs one more agent, and going on to 95/20 costs three more. Each extra point of service level gets more expensive than the last. And the cheap option isn’t as cheap as it looks: stretching the answer time from 20 seconds to 60 saves one agent, not a handful, because the callers who wait at all mostly wait a short time. In the formula, only the 20 changes, and e^-(25 – 20) × 60 / 300 = e^-1 = 0.37 shrinks the share still waiting. The waiting probability, 0.2091, doesn’t move at all.
Before you pick a number, find out what the target is meant to protect. A promise written into a customer contract is a different thing from an internal goal, and the two need different numbers. My post on internal and external SLAs covers the chain between them, and the one on tiered service levels walks through how to match the target to what the customer is paying for. Also agree the definition before you agree the number. If the denominator includes abandoned calls, 80% is harder to hit than if it doesn’t. A target nobody can define is a target nobody can miss.
How do you stop a bad input reaching the schedule?
Run the formula backwards. Take last week’s actual calls and handle time for each interval, calculate the service level the formula predicts for the agents you really had, and compare it with what the ACD reported. In the sheet above, that means typing the real calls into B, the real handle time into C and the real logged-in agents into D, then comparing column G with the report. If they match, your inputs are sound. If the formula says 85% and the report says 70%, one of the three inputs is wrong, and the tables above tell you which. A gap of about 20 points is the size you’d see from a handle time that’s 30 seconds too low (85.0% against 63.8%) or a volume forecast that’s 10% light (85.0% against 64.5%).
I’d rather find that gap on a Tuesday afternoon spreadsheet than from an angry queue. Do it for a week of intervals and the pattern shows up fast. If the gap is always in the first hour, suspect handle time. If it’s always on the same weekday, suspect volume. If it’s everywhere, suspect the definition of service level itself, and go back to what the report counts as answered.
For a second reference on how the three inputs combine, TechTarget’s definition of Erlang C sets out the same relationship in a few lines, and ICMI publishes ongoing research on contact centre workforce management if you want to benchmark your own targets. The point to carry back to your own sheet is simple. Fix the measurement before you touch the formula.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
