Understanding Erlang C, Erlang A, and Simulation for Workforce Management

Most workforce teams do not have a staffing-model problem first. They have a decision problem.

They need to decide how many people they need, how much waiting is acceptable, and how much risk sits behind the plan. Erlang C, Erlang A, and simulation can all help with that, but they are useful in different situations.

The mistake is treating them like interchangeable levels of sophistication, as if Erlang C is the simple version, Erlang A is the better version, and simulation is the advanced version. That is not quite right. Each model makes different assumptions about how work arrives, how customers behave, and how closely the operation resembles a clean queue.

A better question is this: which model is accurate enough for the operational decision you are making?

If you are sizing a relatively clean voice queue, Erlang C may be enough. If abandonment meaningfully changes what happens in the queue, Erlang A is often more realistic. If the team is blended across chat, email, offline work, and changing priorities, simulation is usually the better fit.

This guide explains when each approach is useful, where each one breaks down, and how workforce teams should think about them in practice, especially when they are trying to improve forecasting and staffing decisions together.

The real question behind these models

At heart, this is not really a math question. It is a planning question. How much demand is coming in, how long work takes, how long customers are willing to wait, and how much complexity the operation adds to the answer.

A staffing model helps translate those inputs into something operationally useful: expected waiting, service level risk, occupancy pressure, and the tradeoff between cost and responsiveness.

Erlang C in plain English

Erlang C estimates the probability that a contact has to wait and the expected delay in a queue. It is widely used because it is simple, fast, and often good enough for first-pass staffing decisions.

Think of a relatively clean inbound phone queue where customers mostly stay on the line until someone answers. That is the kind of environment where Erlang C is most useful.

To use it well, you normally need forecasted workload, average handle time, a target service level, and the planning interval. With those inputs, Erlang C gives you a quick baseline for how many people you likely need.

When Erlang C is useful

• voice-heavy environments where customers usually stay in queue
• quick what-if staffing checks during planning cycles
• baseline staffing conversations before you layer in shrinkage, schedules, and exceptions
• teams that need a simple model they can explain to operators and finance

What Erlang C assumes

• one queue, one type of work, and a stable interval
• customers do not abandon the queue
• agents are continuously available to handle the work
• average handle time is a reasonable summary of the work mix

Where Erlang C starts to break down

Those assumptions are exactly why Erlang C is both useful and dangerous. It works best when the operation is relatively clean. It becomes less trustworthy when the day is messy, channel behavior differs, or customer patience materially changes outcomes.

• If abandonment is meaningful, Erlang C often overstates the staffing needed to hit a target.
• If work arrives in bursts inside the interval, averages can hide the actual coverage risk.
• If agents split time across chat, email, calls, and back-office work, a single queue model misses the interaction between tasks.
• If occupancy is already high, a mathematically "efficient" answer can still be operationally unhealthy.

What Erlang A changes

Erlang A is similar to Erlang C, but it includes abandonment. That matters because it acknowledges something planners already know: some customers hang up, leave chat, or give up if they wait too long.

Imagine a support queue where wait times directly affect whether customers stay in line. In that case, staffing decisions should account for customer patience, not just queue delay.

That makes Erlang A more realistic for teams where patience is finite and response-time tradeoffs affect both service level and customer experience.

When Erlang A is a better fit

• queues with measurable abandonment or timeout behavior
• operations that need to balance speed, cost, and customer patience
• teams comparing several staffing levels and wanting a more realistic delay estimate
• environments where service level alone is not enough to describe the impact of understaffing

Why simulation matters more in modern operations

Simulation is what you use when the system is too complex for a clean queueing formula. Instead of reducing the operation to a handful of assumptions, you model the flow of work over time and let the scenario play out.

Think of a blended support team handling chat, email, offline work, and shifting priorities through the day. A single queue formula will struggle to represent that operation honestly.

That usually makes simulation slower to build and harder to explain, but much closer to how the operation actually behaves.

What simulation can model that formulas struggle with

• multiple channels with different response expectations
• blended teams that switch between queue work and offline tasks
• interruptions, concurrency, and routing rules
• shift patterns, break placement, and intraday rebalancing
• demand spikes, long-tail handle times, and rare but costly edge cases

A simple way to choose between Erlang C, Erlang A, and simulation

1. Use Erlang C when you need a fast baseline for a relatively clean queue.
2. Use Erlang A when customer patience and abandonment materially change the answer.
3. Use simulation when channel mix, workflow complexity, or routing rules change the answer materially.
4. Use more than one when you want a fast planning view first and deeper validation for the highest-risk scenarios.

The bigger mistake teams make

Teams often spend too much time debating the model and not enough time challenging the inputs. A sophisticated staffing model cannot rescue a weak forecast or unrealistic assumptions.

• Weak forecasts produce weak staffing answers, regardless of model.
• One average handle time can hide major differences across work types, languages, or issue categories.
• Scheduled headcount is not the same as actually available staffing once breaks, shrinkage, and exceptions hit.
• Formula output is a planning input, not a final truth.

What better staffing decisions look like

Strong workforce teams usually combine methods. They use simpler formulas for fast planning, then validate higher-risk scenarios with richer analysis where it matters.

1. Forecast demand first. If the demand shape is wrong, the staffing answer will be wrong too.
2. Pick the least-wrong model for the operation you actually run.
3. Use the model output to compare staffing options, not to shut down judgment.
4. Compare the plan against reality and improve the assumptions over time.

This is why the real foundation is not just queue math. It is a planning loop that connects forecast quality, staffing assumptions, and what actually happened during the day.

The model matters, but fit matters more

Erlang C is still useful. Erlang A is often more realistic. Simulation is often the best reflection of a complex operation. But none of them is automatically the "best" answer outside the context of the operation and the decision in front of you.

If your team is moving from rough staffing guesses toward a more reliable planning process, start with clear forecasts, choose the model that fits the operation, and keep improving the assumptions as reality feeds back into the plan.

That is where Soon forecasting becomes useful. Better forecasts lead to better staffing assumptions, and better staffing assumptions lead to better decisions long before the day becomes a firefight.