Limitations of Erlang-C

The Erlang-C formula is useful and widely used, especially for call-centre calculations, but users need to understand the limitations of Erlang-C.


Introduction

Erlang-C is a useful tool for estimating call-center performance. But like all mathematical models it contains simplifications. How good Erlang-C's estimates of performance will be depends on how closely the assumptions behind Erlang-C match the real situation.

Averaging

The average call rate for an interval can mask significant workload peaks.

Overload

Erlang-C simply does not work for overload situations.

Abandoned calls

Erlang-C cannot tell you anything about abandoned calls.

Over-staffing

Erlang-C usually recommends more agents than you really need.

Call-flow

Erlang-C doesn't deal with overflow or multiple queues.

Priorities

Erlang-C assumes a simple first-come, first-served queue.


Averaging

Erlang-C assumes that the call arrival rate is constant. This does not mean that calls arrive at regular intervals, it means the calls arrive randomly at a steady underlying rate. To properly define what this means requires some mathematical technicalities, but the general idea should be clear enough, the call rate is steady, not increasing or decreasing.

Call-center measurements and plans are typically based on half-hour intervals. So let's take a single half-hour interval and see what the effect could be of averaging the call=rate over a half-hour interval. We'll start with the case of a steady call rate of 300 calls per half-hour, an average call duration of 180 seconds, and a service level target of answering 80% of calls within 15 seconds. Erlang-C tells us we need 35 agents to achieve this, and that the actual service level with 35 agents will be 82%.

Now let's see what happens if the call rate is not a steady 300 calls per half-hour, but is increasing from 250 calls per half-hour to 350 calls per half-hour over the interval. The average call rate for the interval is still 300 calls per half-hour. If we use Erlang-C to analyze what happens minute by minute over the interval, we get the results shown in the graph below. Overall the service level is 69%, compared to the 82% that might have been expected.

Since call rate obviously does vary during a day, the averaging error described here is important. The error arises from using an average call rate over a time interval when the call rate is changing. This problem is not confined to Erlang-C, but will apply to any queueing formula we choose to use, or to simulation. The use of 15-minute reporting intervals for ACDs is one way of reducing the problem of averaging error, although this does not eliminate the problem.

back to top..

Overload

Erlang-C assumes that the workload does not exceed the capacity of the agents. If the workload exceeds the agents capacity, then the Erlang-C formula is meaningless, and may give you negative service levels or waiting times. This is something you need to specifically check in any program code or spreadsheet calculation you write. If overload does occur, then in the real world there has to be some sort of "safety valve" that removes some of the calls from the system. This "safety valve" can take several forms, and there are alternatives to Erlang-C that can be used to analyze some of them.

Limited Queue Size

There is a maximum number of calls that are allowed to be waiting. If a new call arrives to find the maximum allowed calls already waiting then the new call is not allowed to join the queue, and is lost. It's assumed that lost calls are not retried. (The Limited Queue Size model is available in PhoneCalc). the mathematical formulae for a limited queue size are not much more complicated than the Erlang-C formulae.

Limited Waiting Time

Here there is no limit on how many calls may be in the queue, but there is a maximum time that a call is allowed to wait. Any call not answered after waiting this maximum time is removed from the queue and lost. Again, lost calls are assumed not to be retried. (The Limited Waiting Time model is available in PhoneCalc).

Abandoned Calls

Callers are assumed to abandon after waiting a time. The time that each caller is willing to wait varies from caller to caller. (The Abandoned Calls model, also known as Mitan-C, is available in PhoneCalc).

back to top..


Abandoned Calls

As well as assuming that there is no overload, Erlang-C assumes that callers never abandon. This means that

Erlang-C can tell you NOTHING about abandon rates.

This needs to be emphasized, because it is completely misleading, and unnecessary, to try and use Erlang-C to understand abandon rate. There is an excellent method called Mitan-C available to understand how service levels and abandon rates interact.

back to top..


Over-staffing

Because in practice calls are abandoned, or a queue size limit is imposed, Erlang-C tends to underestimate the service-level that will be achieved, and to over-estimate the number of agents needed to achieve a target service level. This tendency to over-staff is a real effect that has been observed in call centers, and some call centers will no longer use Erlang-C as the basis for their planning.

back to top..


Call-Flow

Erlang-C assumes that there is one source of calls being dealt with by a single group of agents. In many call centers, there are multiple services being provided, and multiple agent groups with possibly complex rules for overflowing or sharing calls between the agent groups. In these situations Erlang-C does not apply, and it's usually necessary to use simulation to estimate performance. On the other hand, as long as each source of calls is dealt with primarily by one agent group, and call overflow happens in only fairly extreme situations, then Erlang-C can still be used as a very approximate guide to performance and staffing levels.

back to top..


Priorities

Erlang-C assumes that calls are handled first-come, first-served. Using some sort of priority scheme can, in fact, improve service levels markedly. Priority schemes can be hard to justify to callers, and simulation is usually needed to estimate performance.

back to top..