Every WFM team I've worked with has an Erlang C calculator. It lives in a spreadsheet somewhere. It was probably built by someone who left the company two years ago. And it is almost certainly giving you the wrong number.
Not catastrophically wrong. Not "you need 200 agents and it says 50" wrong. It's wrong in the way that's actually more dangerous: it's wrong by 8–15%, consistently, in one direction. Enough to overstaff by tens of thousands of dollars a quarter, or understaff enough that your SLA slowly degrades and nobody can figure out why.
The Erlang C formula itself is fine. It's been around since 1917 and the math is sound. The problem is never the formula. The problem is what you're feeding it.
In the past 17 years of optimizing contact center operations — at Stripe, AWS, Boeing, T-Mobile, and a range of mid-market shops — I've audited dozens of Erlang models. The same three mistakes show up in nearly every one.
The three mistakes
Your shrinkage calculation is backwards
This one is so common that I check for it first in every engagement. It's a simple arithmetic error that compounds across the entire model.
When you calculate how many agents you need to schedule to have enough people actually on the phones, you need to account for shrinkage — the percentage of paid time agents spend on non-productive activities (breaks, training, coaching, PTO, sick time, system downtime, meetings).
Here's where it goes wrong. Say your Erlang model tells you that you need 70 agents on the phones to hit your service level. Your shrinkage is 30%. Most calculators I audit do this:
70 × 1.30 = 91 agents scheduled
That's wrong. The correct calculation is:
70 ÷ (1 − 0.30) = 100 agents scheduled
The difference? Nine agents. In a single interval. Scale that across a day, a week, a year, and you're looking at a staffing model that's structurally under-planned. Your SLA misses aren't a scheduling problem — they're an arithmetic problem baked into the model nobody checks.
And here's the thing: if your shrinkage is under 20%, the gap between these two approaches is small enough to be invisible. But the moment your shrinkage climbs above 25% — which it does in most operations once you actually measure it — the error becomes material.
Your AHT is calculated from the wrong data set
Average Handle Time is one of the most important inputs to any Erlang calculation. Get it wrong by even 15 seconds and the downstream staffing number shifts meaningfully.
The problem I see most often: AHT is calculated from a data set that includes calls that shouldn't be in there. Abandoned calls that connected briefly. Internal transfers counted as separate interactions. Outbound callbacks that have a completely different handle time profile than inbound contacts. Test calls from the QA team. Calls that hit the IVR and bounced back as zero-second "handled" contacts.
Your ACD is recording all of this faithfully. But nobody has cleaned the data set before feeding it to the Erlang calculator.
The result is an AHT that is artificially depressed — dragged down by all those near-zero-duration records. Your model thinks contacts are shorter than they actually are. So it tells you that you need fewer agents than you do. And you wonder why your SLA keeps slipping even though the headcount "should" be right.
The fix isn't complicated — but it requires knowing exactly which records to exclude and how your ACD categorizes different interaction types. That varies by platform (NICE and Verint handle this differently than Genesys or Five9), and it's the kind of thing that gets set up once, assumed to be correct, and never validated again.
You're using Erlang C for work it was never designed to handle
Erlang C was invented in 1917 to calculate how many telephone switchboard operators were needed for a single queue of voice calls. It assumes one channel, one skill, and callers who never hang up.
That is not your contact center.
If you're running a multi-channel operation — voice, chat, email, social — and using a single Erlang C calculator to staff it, the math is fundamentally wrong. Chat allows concurrency (one agent handling 2–3 conversations simultaneously), which Erlang C cannot model. Email is asynchronous with backlog dynamics, not real-time queuing. And if your agents are multi-skilled, calculating each queue independently and adding them up overstates your requirements because it double-counts shared agents.
Erlang C is still the right tool for single-queue inbound voice. It is not the right tool for omnichannel capacity planning, and using it that way produces a staffing number that's reliably wrong — but in a way that's difficult to detect because there's no single, obvious error. The model just quietly over- or under-plans by a margin that everyone attributes to "normal variance."
The solution isn't to abandon Erlang C. It's to know where it applies, where it doesn't, and what modeling approach to use for the work it can't handle. That might be simulation modeling, multi-skill optimization, or channel-specific calculations with a blended scheduling layer on top. The right answer depends on your operation's complexity.
The compounding problem
These three mistakes don't exist in isolation. They compound. A shrinkage math error plus a contaminated AHT data set plus an Erlang model applied to multi-channel work means your staffing plan is wrong in three different directions simultaneously. Some errors push you toward overstaffing, others toward understaffing, and the net effect is impossible to diagnose by looking at any single input.
This is why WFM teams end up in a frustrating loop: the model says one thing, reality says another, and the response is to adjust the output (hire more people, cut shifts) instead of fixing the inputs. It's like recalibrating your speedometer by driving faster — you're addressing the symptom, not the problem.
In one engagement, I found that a BPO's Erlang model had all three mistakes. The shrinkage calculation was additive instead of divisive. The AHT included transferred calls counted twice. And they were using a single-queue Erlang model for a blended voice+chat operation. The combined effect: the model was underestimating required headcount by 12% on weekdays and overestimating by 18% on weekends. They were simultaneously burning out agents Monday through Friday and paying for idle time on Saturdays. The correction saved tens of thousands of dollars in weekend staffing costs alone — without impacting service levels.
Why this doesn't get caught
If these mistakes are so common, why doesn't somebody notice?
Three reasons. First, Erlang calculators are treated as black boxes. Someone built the spreadsheet. It produces a number. That number gets used. Nobody opens the hood to check whether the formulas are correct, whether the data inputs are clean, or whether the model's assumptions match the operation's reality.
Second, the errors are in the "plausible" range. An Erlang model that's off by 10% doesn't produce absurd results. It produces results that are close enough to seem right, but far enough off to cost real money over time. You'd catch a 50% error immediately. A 10% error just looks like business as usual.
Third, the people who built the calculator often aren't around anymore. WFM teams turn over. Institutional knowledge walks out the door. The spreadsheet stays, but the documentation of what it assumes and why doesn't. Two years later, nobody remembers what data source feeds the AHT cell, what the shrinkage formula is doing, or why there's a hard-coded 0.85 occupancy cap that may or may not still make sense.
What to do about it
I'm not going to give you a corrected Erlang template — because a template without validated inputs is just a cleaner version of the same problem. The model is only as good as what you feed it, and the feeding is the hard part.
What I will tell you is where to start looking:
Audit your shrinkage formula. Open your spreadsheet. Find the cell that converts required agents to scheduled agents. Is it multiplying or dividing? If it's multiplying by (1 + shrinkage), it's wrong. If your shrinkage is above 25%, the error is costing you real headcount.
Pull your raw AHT data and look at the distribution. If you see a spike at or near zero seconds, you have contaminated data. Those records are dragging your average down and making your model think contacts are shorter than they are.
Ask yourself whether Erlang C is the right model for your channel mix. If more than 20% of your volume is non-voice, a single Erlang C model is not sufficient. You need a different approach for each channel, with a blended scheduling model on top.
If any of those checks reveal problems — and in my experience, at least one of them will — the question becomes: how much is it costing you, and is it worth fixing properly?
Not sure if your Erlang model is right?
The WFM Health Check includes a full audit of your staffing calculations — inputs, formulas, assumptions, and output validation against actuals. In one week, you'll know exactly where the math is breaking and what it's costing you.
