7 Common Erlang Calculation Mistakes (and How to Fix Them)

> **Quick Answer:** The most damaging Erlang mistakes are (1) using average traffic instead of busy-hour traffic, (2) omitting after-call wrap-up from AHT, and (3) using Erlang B when you need Erlang C. All three lead to systematic understaffing or underprovisioning.


Erlang calculations seem straightforward — a few inputs, a formula, a result. But the inputs require careful measurement, and the formula makes assumptions that don't always match your environment. Here are the seven mistakes that consistently show up in capacity plans I've reviewed, along with the specific fix for each.

Mistake 1: Using Average Traffic Instead of Busy-Hour Traffic

**What happens:** You export a month of CDR data, calculate the average calls per hour, and feed that into your Erlang calculation. The result looks reasonable. But your busy hour carries 2–3× your average load, and your trunks or agent count is sized for the wrong scenario.

**The impact:** A call center running 15 Erlangs on average but 28 Erlangs at peak will have severe service level problems every morning between 10 and 11 AM. The Erlang calculation was technically correct — just applied to the wrong traffic number.

**The fix:** Always use your busy-hour traffic intensity. Pull CDRs grouped by hour, find the hour with the most calls, and use that as your input. If you have multiple weeks of data, use the average of your top 5 busy hours — not the absolute peak (which might be an outlier) but not the overall average either.

Mistake 2: Omitting After-Call Work (Wrap-Up) from AHT

**What happens:** Average Handle Time (AHT) is measured as talk time only — 3 minutes per call. Wrap-up (the time agents spend completing paperwork, updating CRM records, or processing the call after the customer hangs up) is not included. AHT gets reported to the Erlang calculator as 180 seconds when it should be 270 seconds.

**The impact:** A 50% underestimate of AHT produces a 50% underestimate of traffic intensity (Erlangs), which requires significantly fewer agents in the Erlang C formula. In practice, the contact center is always under-staffed.

Typical wrap-up time ranges from 30 seconds (simple transaction) to 5+ minutes (complex case requiring research and documentation). For most customer service environments, wrap-up adds 20–40% to talk time.

**The fix:** Measure AHT as: Average Talk Time + Average Hold Time + Average After-Call Work. Pull all three separately from your ACD (most systems report them separately) and add them. Use this composite number in your Erlang C calculation.

Mistake 3: Using Erlang B When You Need Erlang C (or Vice Versa)

**What happens:** An IT manager sizes a call center ACD queue using Erlang B because that's the formula they learned for trunk planning. The result: they calculate the number of agents needed to get blocking probability to 2%, which has nothing to do with what percentage of callers get answered within 20 seconds.

**The impact:** The agent count from Erlang B is usually too low for a call center environment, and the wrong KPI (blocking probability vs. service level) means there's no valid way to verify whether the staffing is correct.

**The fix:** If callers wait in a queue → Erlang C. If callers receive a busy signal and must redial → Erlang B. Our [Erlang B vs Erlang C guide](/blog/erlang-b-vs-erlang-c) covers the full distinction with examples.

Mistake 4: Ignoring the Occupancy Limit

**What happens:** The Erlang C formula outputs a minimum agent count for a service level target. Someone notices that adding 2 fewer agents still shows 79% service level (just under the 80% target), so they staff 2 fewer to save budget. Occupancy jumps from 82% to 86%.

**The impact:** At 86% occupancy, the system is near the exponential portion of the Erlang C curve. A 5% traffic increase causes a 15–20 percentage point service level drop. Any day with higher-than-normal call volume causes a crisis.

**The fix:** After running Erlang C, always check the resulting occupancy. Target 78–85% occupancy for stable operations. If your Erlang C result puts you above 85%, add more agents regardless of whether service level technically meets the target — you have no buffer for variation.

Mistake 5: Using a Single Traffic Measurement Point

**What happens:** Traffic data is pulled from one representative Tuesday and used to size the entire system. But call volumes vary by day of week, week of month, season, and the occurrence of campaigns or events.

**The impact:** The system is well-sized for that Tuesday but fails on Mondays (typically 20–30% higher call volume in most industries), after holidays, or during promotions.

**The fix:** Collect at least 30 days of hourly traffic data — ideally 90 days to capture seasonal patterns. Calculate Erlang separately for different day types (Monday, Tuesday–Thursday, Friday, weekend). Size each shift separately using its own traffic profile.

Mistake 6: Not Accounting for Shrinkage

**What happens:** The Erlang C calculation says 40 agents are needed. The staffing plan schedules 40 agents. But 40 scheduled agents doesn't mean 40 agents on the phone — they need breaks, training, attend meetings, and some call in sick.

**The impact:** At 25% shrinkage, 40 scheduled agents yields only 30 available agents on the phone. The operation runs chronically understaffed.

**The fix:** Apply shrinkage before writing the schedule. Scheduled agents = Agents needed on phones / (1 - Shrinkage rate). With 40 agents needed and 30% shrinkage: 40 / 0.70 = 57 agents to schedule. Track your actual shrinkage monthly and update the factor.

Mistake 7: Planning to Average Service Level Instead of a Minimum

**What happens:** The team runs Erlang C and staffs to exactly achieve 80% service level on average. But service level is measured in 30-minute intervals, and traffic varies around the average. Some intervals will be under 80% (too few calls for the staffing), others over 80%.

A staffing plan that averages 80% service level across intervals will actually be below 80% in more intervals than you'd expect — because intervals with above-average traffic tend to fall below 80% more dramatically than intervals with below-average traffic exceed it.

**The impact:** Consistent service level misses even though the average looks acceptable.

**The fix:** If your target is 80% service level, staff to achieve 83–85% under your forecast traffic. The buffer absorbs variation and keeps your service level above 80% in most intervals. Check your actual service level distribution — if you're hitting 90% in quiet periods and 65% during peaks, you have a staffing distribution problem, not just a headcount problem.

---

All seven mistakes share a common cause: treating Erlang calculations as a black box where any inputs will do. The math is precise; the inputs must be equally precise. Run your [Erlang calculation](/erlang-calculator) with accurate busy-hour traffic, full AHT, and the right formula — and verify occupancy before finalizing the output.