How many support agents do you need? Erlang C explained

The number of support agents you need depends on four things: how many contacts arrive in each hour, how long each one takes, how fast you want to answer, and how much of the working day people spend away from the queue. The Erlang C formula turns the first three into the agents you need on the queue in one hour. This guide goes further and builds a plan for a whole day, with every number worked out, so you can do the same with your own data.

Step 1: count contacts per hour, not per day

Contacts do not arrive evenly. A daily total hides the peak, and the peak is where customers wait. Export the contacts that arrived in each hour for the last four to eight weeks, and average each hour of each weekday separately, because one weekday can look very different from another.

Our example team answers a phone queue. It takes 345 contacts across five sample hours of a weekday. If you staff every hour for the average of 69 contacts, you schedule 7 agents on the queue. At the noon peak of 120 contacts, the work that arrives keeps 8 agents busy for the whole hour. With 7 agents, the queue grows all hour and the target is not met at all. The average looks fine on paper and fails at lunchtime.

Step 2: set handle time and the target

Average handle time (AHT) is talk or chat time plus hold time plus the wrap-up after the contact. Take it from your help desk for the same weeks, and by hour if you can, because handle time is often longer at busy times. Our team's AHT is 240 seconds (4 minutes).

The target says how fast you want to answer. Our team aims for 80% of contacts answered within 30 seconds. Choose a target your customers would notice if you missed it, and keep it the same for every hour, so the plan is comparable across the day.

Step 3: work out agents for each hour

Run Erlang C once for each hour. The Erlang C staffing calculator takes the contacts, the interval length, the AHT and the target, and finds the smallest team that meets it. For our five sample hours:

Traffic is contacts × AHT ÷ the interval length in seconds. At noon that is 120 × 240 ÷ 3,600 = 8 Erlangs: 8 agents busy for the full hour. Erlang C adds the agents needed so that contacts do not queue too long, which gives 11.

Step 4: add shrinkage

Agents on the schedule are not all on the queue. Breaks, meetings, training, holidays and sick days take a share of paid time, called shrinkage. Our team measured 35% from its own schedules and absence records. Agents to schedule = agents on the queue ÷ (1 − shrinkage), rounded up. At noon that is 11 ÷ 0.65, rounded up to 17. Measure your own shrinkage rather than copying a number from somewhere else, because it depends on your own breaks, training and absence.

Step 5: turn hours into shifts

The last column is a need per hour, not a roster. People work shifts of several hours, so you cover the curve with overlapping shifts:

• Start a small early shift for the first hours, sized to the morning need.
• Add a middle shift that starts before the late-morning rise and covers the peak.
• Let the early shift end, and a late shift start, as the afternoon falls.
• Schedule breaks, meetings and training in the quiet hours, never at the peak.

Count the people your shifts put in each hour and compare with the table. Where you are short, the service level drops for that hour. Where you have more than you need, use the time for training or help articles.

Why workload math alone is not enough

A common shortcut skips Erlang C: take the work in hours and divide by a planned occupancy. At noon the work is 8 agent-hours. At 85% occupancy the shortcut gives 8 ÷ 0.85 = 9.4, so 10 agents. Erlang C says that 10 agents answer 68.1% in time, well below the target, and that you need 11.

The shortcut assumes contacts arrive in a smooth line. They arrive at random, in small bunches, and the queue needs spare agents to absorb the bunches. Erlang C models that randomness, which is why it asks for more.

One queue or several?

Splitting a team into separate queues, by product, by language or by channel, costs agents. Here are 120 contacts in a 30-minute interval with an AHT of 5 minutes and a target of 80% answered within 20 seconds, handled as one queue or split evenly:

The work is the same in every row. Small queues need more spare capacity each, because a bunch of contacts in one queue cannot borrow an idle agent from another. Split queues only where you must, for example for a language that only some agents speak, and let agents with more than one skill take contacts from several queues.

What changes when fewer contacts reach the queue

The other way to need fewer agents is to need fewer contacts. As an example, and not a forecast, suppose 20% of the noon contacts are simple questions that customers answer for themselves from your help pages. That leaves 96 contacts. With the same AHT, the queue needs 9 agents instead of 11, and you schedule 14 instead of 17.

Be careful with that number. The contacts that are left are the harder ones, so AHT often rises. If AHT goes from 240 to 255 seconds, the queue needs 10 agents and you schedule 16. Run the calculator with both changes, and check your real AHT a few weeks later.

A support chatbot is one way to take those questions. Paperlink AI answers website visitors only from the documents you upload and the website pages you import. When that content does not answer a question, the bot says so and shows your support contact, so the question still reaches your team. The dashboard shows an Answered rate, the share of questions the bot answered, which you can compare with the drop in contacts before you change the schedule.

Small teams

With only two or three agents, Erlang C still works, but other limits matter more. Someone must cover lunch, and one sick day removes a third of the team. Set a minimum of people for every open hour, then use the calculator to check whether the peak needs more. Run the numbers for your own hours in the Erlang calculator.