Live chat staffing calculator
Chat agents handle more than one conversation at a time, which is why running chat volume through a voice Erlang calculator gives the wrong answer. This calculator treats each agent as a set of chat slots, runs Erlang C on the slots, converts back to agents, then applies your occupancy ceiling and shrinkage. It also shows the common handle-time shortcut so you can see where the two disagree.
Handling chats for the whole interval, before shrinkage.
- Chat slots needed
- 48
- Service level achieved
- 89.5%
- Slot occupancy
- 83.3%
- Handle-time shortcut says
- 24
- Agents to schedule
- 35
- Workload
- 40.0 erlangs
Handle time ÷ concurrency, one server per agent. Differs from the slot model for small teams.
After shrinkage.
Show the working
- Workload = 120 chats ÷ 30 min × 600 s ÷ 60 = 40.0 erlangs.
- Each agent is 2 chat slots. Erlang C on slots: 48 slots meet 80% within 30 s under the 85% occupancy ceiling.
- Agents = 48 ÷ 2 = 24.00, rounded up to 24, which staffs 48 slots at 89.5% service level and 83.3% occupancy.
- The shortcut instead treats each agent as one server with a handle time of 600 ÷ 2 = 300 s, which gives 24 agents.
- Shrinkage: 24 ÷ (1 − 0.30) rounds up to 35 to schedule.
Doing this for every interval of the week? Pebble WFM computes the requirement from your forecast and builds the roster. Free month, no card needed.
How chat staffing with concurrency is calculated
A chat occupies an agent's attention for its whole elapsed handle time, but only a share of it. If an agent sustains two chats at once, they are effectively two servers, each slower than a voice agent because the attention is split. So the calculator multiplies agents by concurrency to get slots, runs Erlang C on the slots with the elapsed handle time, and divides the required slots by concurrency, rounding up, to get agents.
The handle time you enter must be the elapsed time while the agent is multitasking, not the time a chat would take if it had the agent's full attention. Concurrency inflates it: a chat that needs four minutes of work takes ten minutes of elapsed time at concurrency two or three. Measure it from your chat platform rather than estimating it.
The common shortcut divides handle time by concurrency and runs voice Erlang C on the result. It is the same total capacity but modelled as fewer, faster servers. For small teams the two models disagree by an agent or two, and the slot model is the one that describes what actually happens on the floor. They converge at scale.
Read the full guide: How to staff live chat with concurrency
Frequently asked questions
- Do chat customers abandon like voice customers?
- No, and planning chat with voice patience is a real mistake. Where a caller's patience is measured in minutes, one study of live chat put average patience at over an hour. The bigger problem is silent abandonment: customers who stop replying without closing the window. Across seventeen companies it ranged from 3 to 70 per cent of conversations, and one firm's true abandonment was 17.7 per cent against the 5.1 per cent it believed. If your chat abandonment looks suspiciously low, it is probably being measured wrong rather than being good.
- Should handle time go up as concurrency goes up?
- Yes, and by more than most plans allow. Research on 600,000 messaging conversations found that a parallel conversation sitting idle cost almost nothing, but a genuinely active extra chat added around 60 per cent to handle time, and the effect grew with each further chat instead of levelling off. The odds of resolving a contact also fell sharply per extra concurrent chat. Either measure handle time at the concurrency you actually run, or use the slowdown input here.
- What concurrency should I plan with?
- The average your agents actually hold, not the maximum the tool allows. If agents are allowed three chats but average 1.8 because of gaps between conversations, plan with two and check the slot occupancy the calculator reports. Planning with the maximum silently assumes every agent is at the limit all interval.
- Does a higher concurrency always mean fewer agents?
- Only if handle time does not rise with it. In practice each extra concurrent chat lengthens every chat, because the agent is switching. Past three or four the total throughput per agent often stops improving and customer wait between messages gets worse.
- What does service level mean for chat?
- Usually the share of chats whose first response arrives within the target, from the moment the customer submits the chat. That is what the calculator models. Response time between messages inside a chat is a different measure and is governed by concurrency rather than staffing.
- Can I blend chat and voice agents?
- Blending is a scheduling and routing question rather than a calculation one. Size each channel separately, then decide how much of the chat requirement can be covered by voice agents in their idle time. Blended agents rarely sustain the same chat concurrency as dedicated ones.
Embed this calculator on your site
Paste this where you want the calculator. It stays free and ad-free, updates when we improve it, and the line under it credits the source.
Stop doing this one interval at a time
Pebble WFM forecasts your demand, computes the staffing requirement for every interval, builds the roster and publishes it, with self-service for agents and a copilot that can do what a planner can. Explore a sample organisation on day one.