Erlang C Staffing Calculator

Calculator overview

Inputs and outputs

This summary comes from the calculator's published input and output contract.

Inputs

Shrinkage: About this input

The share of paid time agents are not available to take calls, in percent, covering breaks, training, meetings and absence. It inflates the on-phone requirement into a rostered headcount.

Unit % Default 30 Range 0 to 100
Target Answer Time: About this input

The time within which calls should be answered, in seconds, for example 20 seconds. Together with the target service level it forms the service goal.

Unit seconds Default 20 Range At least 0
Target Service Level: About this input

The share of calls that should be answered within the target answer time, in percent, for example 80 percent. This is the goal the number of agents is sized to meet, not the same as agent occupancy.

Unit % Default 80 Range 0 to 100
Average Handling Time: About this input

The average time an agent spends on a call, in seconds, including talk time and after-call work. It sets how much agent time each call consumes.

Unit seconds Default 180 Range At least 0
Calls In The Period: About this input

The number of calls arriving during the measurement period, in calls. Combined with the period length it gives the call arrival rate.

Unit calls Default 100 Range At least 0
Period Length: About this input

The length of the measurement period, in minutes, over which the calls arrive. A half-hour interval is common for staffing.

Unit minutes Default 60 Range At least 0

Outputs

Rostered Requirement With Shrinkage: About this output

The full-time-equivalent roster needed so that the required agents are actually on the phones after shrinkage (breaks, training, absence). A fraction is meaningful here: it is FTE to roster, not a count of people, and real rosters round it up.

Unit FTE
Probability Of Waiting: About this output

The chance that an arriving call has to wait at all before an agent is free, in percent, from the Erlang C formula.

Unit %
Offered Load: About this output

The workload offered to the group, in erlangs, equal to the call arrival rate times average handling time. One erlang is one call-hour of work per hour and sets the minimum agents needed.

Unit erlangs
Service Level With One Agent More: About this output

The service level, in percent, if one more agent than required were staffed. It shows the diminishing gain from over-staffing.

Unit %
Service Level With One Agent Fewer: About this output

The service level, in percent, if one fewer agent than required were staffed. It shows how sharply service falls when short-staffed.

Unit %
Service Level Achieved: About this output

The share of calls answered within the target answer time at the required number of agents, in percent. It meets or exceeds the target.

Unit %
Calls Per Hour: About this output

The call arrival rate expressed per hour, in calls per hour, from the calls and period length.

Unit calls/h
Average Speed Of Answer: About this output

The average wait before a call is answered, in seconds, across all calls including those answered immediately.

Unit seconds
Agents Required: About this output

The smallest number of agents that meets the service-level target, searched over a modelled range of 1 to 200 agents. A load needing more than 200 agents refuses with its own NOT VALID rather than answering; split such an operation into skill groups before sizing it here.

Unit agents
Occupancy: About this output

The share of agents' on-phone time spent handling calls rather than waiting, in percent. It is not the service level, and pushing it above about 85 percent tends to burn agents out.

Unit %
Model Status: About this output

The overall check on your entries, shown above the results. It reads OK when the inputs are usable, NOT VALID with a reason when an entry makes the model meaningless, or CHECK with a reason when a result is valid but worth a second look. Read it before you trust the numbers below.

No unit declared
Minimum Agents To Be Stable: About this output

The smallest agent count with a stable queue, strictly more than the offered load in erlangs: with agents equal to the load the queue grows without bound. This is a floor for existence, not a staffing recommendation; the recommended figure is Agents_Required.

Unit agents

What it is

The Erlang C Staffing Calculator works out how many agents a contact centre needs to hit a service-level target. You give it the call volume over a period, the average handling time, the service level you want and the time you want to answer within, and it returns the agents required, the service level they would actually achieve, the chance a caller waits at all, the average speed of answer, and the occupancy those agents would run at.

It also converts agents on the phone into a rostered requirement using your shrinkage figure, and shows what one more and one fewer agent would do.

Times are in seconds, the period in minutes, and service level and shrinkage in percent.

Use it for interval-by-interval workforce planning. Erlang C assumes callers wait rather than hang up, which makes it conservative; see below.

Methodology

Purpose and model boundary

This model sizes a single call-handling group with the Erlang C queueing method. It finds the smallest on-phone agent count that reaches a target service level, then applies shrinkage to produce a rostered full-time-equivalent requirement. It also reports waiting probability, average speed of answer, occupancy, and the service-level effect of adding or removing one agent.

The model is a queueing approximation, not a shift scheduler. It does not assign named employees, build breaks, forecast interval arrivals, or model abandonment and retrials.

Inputs and units

Input	Meaning and unit
Calls in the period, `C`	Arriving calls during the measurement interval.
Period length, `T`	Minutes in the interval.
Average handling time, `h`	Seconds per call, including after-call work.
Target service level, `q`	Percent of calls to answer within the target time.
Target answer time, `t`	Seconds used by the service-level test.
Shrinkage, `s`	Percent of paid time unavailable for calls.

Governing relationships

The workbook converts the interval to an hourly arrival rate and offered load:

lambda = C × 60 / T calls per hour

A = lambda × h / 3600 erlangs

For each candidate agent count n from 1 through 200, it builds Erlang B recursively:

B_1 = A / (1 + A)

B_n = A × B_(n-1) / (n + A × B_(n-1))

For a stable candidate (n > A), the Erlang C probability that an arrival waits is:

C_n = B_n / (1 - (A / n) × (1 - B_n))

The service level achieved within t seconds is clamped between zero and one:

SL_n = 1 - C_n × exp(-(n - A) × t / h)

Candidates at or below the offered load are treated as unstable and receive zero service level. The required count n* is the first candidate whose service level is at least q / 100.

For the selected count:

occupancy: A / n*;
average speed of answer: C_n × h / (n* - A) seconds;
rostered requirement: n* / (1 - s / 100) FTE;
minimum stable agents: floor(A) + 1.

Calculation sequence

Convert calls and interval length to calls per hour and offered erlangs.
Evaluate the unrolled 1-to-200 candidate table using the Erlang recursion.
Mark the first stable row that meets the target service level.
Return that row's agent count, wait probability, average wait, occupancy, and achieved service level.
Read the adjacent rows for the one-agent-fewer and one-agent-more comparisons.
Apply shrinkage only after the on-phone requirement has been found.
Evaluate Model_Status in the order below.

Outputs and interpretation

Agents_Required is an integer on-phone requirement and is the decision result. Rostered_Requirement_With_Shrinkage is an FTE planning value; an operational roster generally rounds it up and then adds interval and schedule constraints. Minimum_Agents_To_Be_Stable is only a mathematical floor, not a service recommendation. Service level and occupancy are different measures and should not be interchanged.

Validation and status logic

Condition	Returned status
Calls in the period is less than or equal to zero	`NOT VALID: enter a positive number of calls`
Period length is less than or equal to zero	`NOT VALID: period length must be greater than zero`
Average handling time is less than or equal to zero	`NOT VALID: handling time must be greater than zero`
Shrinkage is at least 100%	`NOT VALID: shrinkage must be below 100 percent`
No candidate from 1 through 200 meets the target	`NOT VALID: the target cannot be met within the modelled agent range`
Occupancy at the selected count is greater than 85%	`CHECK: occupancy above 85% is not sustainable; add an agent`
Shrinkage is at least 50%	`CHECK: shrinkage of 50% or more is unusually high`
None of the preceding conditions applies	`OK`

Earlier rows take precedence. For example, an impossible shrinkage value returns NOT VALID before an occupancy warning can be considered.

Assumptions and limitations

Arrivals are assumed to follow a stationary Poisson process during the interval; handling times are assumed independent and exponentially distributed.
Agents are treated as identical members of one skill group, and calls are handled first-come, first-served.
The model has no abandonment, busy signal, callback, retry, priority, transfer, multi-skill routing, time-varying arrival pattern, or finite queue.
Interval averages can hide peaks. Use short planning intervals and an external forecast rather than an all-day average.
Shrinkage is a simple final divisor. It does not produce an executable shift plan or account for indivisible people, overlapping intervals, breaks, or labor rules.
A target answer time of zero and a target service level of zero are accepted by the workbook; users should confirm that such targets are intentional.

Restrictions and non-computing states

This calculator rejects values below its declared minima and constrains target service level and shrinkage to 0 through 100 percent. The workbook requires positive calls, period length, and handling time, refuses shrinkage of 100 percent, and searches only integer agent counts 1 through 200. If no row in that fixed search range meets the target, it returns the exact NOT VALID status above rather than extrapolating a larger roster. Zero target answer time and zero target service level are accepted, not treated as errors.

Errors and warnings

Entries outside the published limits can be rejected before calculation. Workbook NOT VALID messages identify a non-computable queue or an exhausted 200-agent search. CHECK messages retain the calculated result but flag occupancy or shrinkage assumptions. A network or calculation-service failure is not an Erlang conclusion and should be retried separately.

References

The workbook derives its relations rather than reproducing any table, chart or figure from a standard or publication. The Erlang C probability is computed recursively over an agent table and the service level, average speed of answer and occupancy follow from it.

Wikipedia. Erlang (unit) and the Erlang C formula. https://en.wikipedia.org/wiki/Erlang_(unit)
Wikipedia. M/M/c queue, the queueing model Erlang C describes. https://en.wikipedia.org/wiki/M/M/c_queue
Wikipedia. Queueing theory, for the assumptions and where they break. https://en.wikipedia.org/wiki/Queueing_theory

Erlang A, which extends the model with caller abandonment, is the closer fit for most modern contact centres and is not implemented here. Shrinkage figures and service-level targets are yours to set and carry no authority from this tool.

Additional source notes migrated from Methodology

The model implements the standard Erlang C delay probability and service-level relationship. The delivered reviewer packet identifies the Erlang.com calculator and Call Centre Helper Erlang calculator as independent comparison sources. Agent counts should be compared with shrinkage set consistently.

Frequently asked questions

Why do I need more agents than the offered load?

Because a queue is only stable when agents strictly exceed the offered load. Staffing exactly the load implies 100 percent occupancy, and since calls arrive randomly rather than evenly, the queue grows without bound and waiting time goes to infinity. The tool reports the minimum stable count as `INT(offered load) + 1`. At exactly 5 erlangs that is 6 agents, not 5. Integer loads are where this trap is most tempting.

Why can I not hit my service-level target exactly?

Because agents are whole people. Each additional agent moves the service level by a discrete jump, and your target almost never lands on a rung. In the shipped example 7 agents give 74 percent and 8 give 88 percent against an 80 percent target; there is no staffing level that produces 80. The tool shows one more and one fewer so you can see the size of the step rather than only the answer.

Is 62.5 percent occupancy too low?

No, and treating occupancy as a productivity target is the most common way to wreck a contact centre. Idle time is what absorbs the randomness of arrivals; without it, queues explode. Waiting time rises sharply and non-linearly as occupancy approaches 100 percent, so a centre running in the nineties has no resilience to a spike or an absence. Occupancy is a diagnostic, not a goal.

Does this account for callers hanging up?

No, and it is the model's biggest simplification. Erlang C assumes infinite patience: every caller waits as long as it takes. Real callers abandon, and abandoned calls are work that never has to be done, so Erlang C overestimates required staffing, mildly when queues are short and substantially when they are long. The Erlang A model adds an abandonment rate and is the better fit for most modern centres. This is not it.

What is the difference between agents required and the rostered requirement?

Agents required is how many must be on the phones during the interval. The rostered requirement is how many people you need on the schedule to produce that, after shrinkage: breaks, training, meetings, absence, anything paid for but not spent handling calls. At 30 percent shrinkage, 8 agents on the phones needs 11.43 full-time equivalents rostered.

Can I use one calculation for a whole day?

No. Erlang C sizes a single interval in steady state, and call volume varies enormously across a day. Planning is done interval by interval, typically in fifteen- or thirty-minute blocks, and each interval is sized separately. Averaging a day into one calculation will understaff the peaks and overstaff the troughs, and the peaks are where service level is lost.

Found a problem, or have an idea?

Tell us if a result looks wrong, a label is unclear, or something is missing. We read every message.

This page is provided by LogicCommons for informational purposes only. Results are analysis outputs computed from the inputs you supply and are not engineering advice, a design, or a substitute for review by a licensed professional under the codes adopted where the work is built. Verify all inputs and results independently.

LogicCommons is in beta. If a result, label, or reference looks wrong, tell us here; we read every message.