Anyone who leads a customer service team of five to fifteen people usually schedules by feel and last week. That works until it does not: a campaign, a delivery disruption or a wave of colds, and the queue grows while everyone works as hard as they can. I have built staffing plans for both small teams and large contact centres, and the method is the same in both. This article shows how to calculate the need per hour and channel, without tools that cost more than the team.
Why is an average not enough for staffing?
Because tickets do not arrive evenly, and queues form in the peaks no matter how good the average looks. A team taking 300 tickets a week has on average 7.5 tickets an hour during office hours. But on Monday at 9 there are 25, and on Thursday at 15 there are 3. Whoever staffs for 7.5 has a queue on Monday morning and idle time on Thursday afternoon, and the customer only remembers Monday.
The first step is therefore to pull the inflow per hour and weekday, per channel, for at least four weeks back. It exists in every customer service tool, often as a report nobody has looked at. The curve that emerges is the basis for everything else, and it looks different for different businesses: e-commerce peaks on Sunday evenings and Mondays, service companies around invoice dates, SaaS companies after releases. What customers expect in response time per channel, which staffing should be calculated against, is covered in the article on response times.
How do you calculate for phone and chat, where the customer waits in real time?
With queue mathematics, because response time in real-time channels depends on how many people are free at the moment the customer gets in touch, not on how much the team gets through in a day. The formula used in contact centres for a hundred years is called Erlang C. According to a review from East Carolina University, contact centres are modelled as a queueing system where contacts arrive, wait in a queue and are served by an agent, and Erlang C calculates the probability that a customer has to wait given the load and the number of agents. The load is the number of contacts per hour times the handling time.
You do not need to calculate the formula by hand; there are calculators, and most scheduling tools have it built in. What you need to understand are three things it shows:
- Small teams are punished hardest. With two people and ten calls an hour at six minutes each, the load is one person, but for eight out of ten to be answered within a minute you need three. The reserve is large relative to the load when the team is small, and that is why small teams experience queues more often than large ones at the same occupancy.
- The response time target drives the cost. Going from "answer within two minutes" to "answer within 30 seconds" can require one more person in a small group. The target should be chosen deliberately, not inherited.
- The formula assumes infinite patience. The same review points out that Erlang C assumes nobody hangs up, and can therefore predict very long waits at high load, while real customers give up. So calculate on the shorter queues, and read the abandonment rate as a metric of its own.
For chat there is also concurrency: an agent can keep two or three chats going, but the handling time per chat gets longer and quality drops above three. Count on the concurrency you actually measure, not the one the supplier promises. Gartner reports that live chat, self-service portals and knowledge systems are set to overtake phone and email as the technologies customer service leaders value most by 2027, so chat will take a larger share of staffing, and it should be planned as a real-time channel.
How do you calculate for email and forms?
With throughput against a response time target, because the customer is not waiting in real time and tickets can queue without anyone hanging up. The calculation is simpler:
| Step | Calculate | Example |
|---|---|---|
| Inflow per day | Tickets per day, per weekday | 60 emails on a Monday |
| Handling time | Minutes per ticket, including lookups and reply | 8 minutes |
| Work per day | Inflow times handling time | 480 minutes, that is 8 hours |
| Capacity per person | Productive hours per day after shrinkage | 5.5 hours |
| Need | Work divided by capacity | 1.5 people on the Monday |
The response time target decides how much may carry over to the next day. With a target of a reply within four hours, the day's inflow must largely be handled the same day, and then the hourly curve applies to email too. With a next-business-day target, Monday's peak can be spread over Tuesday, and staffing evens out. That is also why email and forms are the right channel for tickets that require supporting material: they can be planned. Which tickets belong in which channel is described in the article on channel choice.
What is shrinkage, and why is the schedule wrong without it?
Shrinkage is the part of paid time in which the agent cannot take tickets: breaks, meetings, training, system trouble, sick leave and holiday. A person scheduled for eight hours does not take tickets for eight hours, and a schedule that assumes so is understaffed every day without anyone understanding why.
Measure your own shrinkage instead of guessing: add up per week the time that went to things other than tickets, and divide by the scheduled time. Split it into planned shrinkage, such as breaks and meetings, and unplanned, such as sick leave. The planned part you can schedule around, for example by not holding the team meeting on Monday at 9. The unplanned part must sit as a margin in the staffing, and it is larger in small teams, where one sick person is a fifth of the capacity.
How do self-service and AI affect staffing?
They remove the simple contacts from the inflow, so that the staffing you calculate applies to the tickets that actually need a person. But only if self-service works: according to a Gartner survey only 14 percent of customer service issues are fully resolved in self-service, and a customer who fails there ends up in the queue anyway. So do not subtract the tickets self-service ought to take; subtract the ones you have measured that it takes, per ticket type.
Two effects deserve their own line in the calculation. The first is that the remaining inflow gets harder: when order status and return terms have gone, what remains is exceptions, complaints and unhappy customers, with longer handling time. Staffing falls less than the ticket count. The second is that customers' expectations of availability do not follow your opening hours; according to Zendesk 74 percent of consumers expect support around the clock. That is an argument for self-service and a chat that answers from reviewed knowledge in the evenings and at weekends, not for staffing them. How to measure the share self-service takes, and the other metrics staffing is read against, is in the article on metrics.
What to do
- Pull the inflow per hour, weekday and channel for the past four weeks. Draw the curve, or ask the tool to do it.
- Measure handling time per ticket type in each channel, including lookups and after-call work. Use the median, not the mean, if some tickets are extremely long.
- Calculate the real-time channels with an Erlang calculator and a response time target you have chosen deliberately. Test what a stricter and a milder target costs in people.
- Calculate email and forms as throughput against the response time target, day by day.
- Measure your shrinkage for a month and add it on. Schedule the planned part outside the peaks.
- Subtract what self-service and AI measurably take per ticket type, and count on longer handling time for what remains. In Supportifier you see per ticket type how many are resolved without a person, which is the number that goes into the calculation.
- Lay the schedule to the curve, with breaks and meetings in the troughs, and follow up response time and abandonment rate per hour every week.
Common questions
How many tickets can an agent handle per day?
It depends on channel and ticket type, and it should be measured at your end, not taken from a table. Count backwards: productive hours per day after shrinkage, divided by handling time per ticket. An agent with five and a half productive hours and eight minutes' handling time manages just over 40 emails a day. The same person manages fewer calls if they are longer, and more chats if they can keep two going.
Does a small team really need to calculate with Erlang?
Yes, and small teams benefit most from it, because queue mathematics hits hardest there. With two or three people on phone or chat, a single person's break decides whether the customer has to wait. A calculator shows what the response time target actually costs in people, and makes it possible to choose: staff for the target, lower the target, or move tickets to email and self-service where the queue is not visible in real time.
Should we staff evenings and weekends?
Only if you have measured that tickets requiring a person arrive then in sufficient volume. Customers' expectation of round-the-clock availability is usually better met with self-service and a chat that answers from reviewed knowledge, with handover to the next morning. Calculate what evening staffing costs against what those tickets are worth, and test in one channel before you build shift work. Many online retailers find that Sunday evening's questions can wait until Monday if the answer about delivery time is already in the help centre.
How often should staffing be recalculated?
Every quarter, and ahead of every known peak. The inflow changes with season, campaigns and range, and the share self-service takes grows as the knowledge base improves. Read the hourly curve once a quarter, compare with the previous quarter, and recalculate. Ahead of the Christmas season a separate calculation is made for the peak days, as we describe in the article on preparing for the Christmas season.
Sources
- Evaluating the Erlang C and Erlang A Models for Call Center Modeling — Robbins et al., East Carolina University, read 2026
- Gartner Survey Finds Self-Service and Live Chat Will Surpass Traditional Channels as Top Customer Service Technologies By 2027 — Gartner, 2025
- Gartner Survey Finds Only 14% of Customer Service Issues Are Fully Resolved in Self-Service — Gartner, 2024
- Contextual Intelligence Becomes the New Standard for Exceptional Customer Experience in 2026 (CX Trends 2026) — Zendesk, 2025
Rickard Collander