How to staff live chat with concurrency
Why voice Erlang gives the wrong answer for chat, how to model an agent handling several chats at once as slots, and where the common handle-time shortcut goes wrong.
Published
A voice agent handles one call at a time. A chat agent handles two, three or more, and that one fact breaks every voice staffing model applied to chat. This guide explains the model that works, the shortcut most spreadsheets use instead, and the handle time trap that catches both.
Slots, not agents
Think of an agent who sustains three chats at once as three chat slots. A new chat takes a free slot and holds it for its whole elapsed handle time; when it closes the slot is free again. Whether the slot belongs to agent A or agent B does not matter to the customer waiting for one.
That is exactly an Erlang C queue where the servers are slots. So:
- Calculate the workload in erlangs from chat volume and elapsed handle time, as for voice.
- Run Erlang C to find the slots needed for the service level target, and raise it for the occupancy ceiling.
- Divide slots by concurrency, round up, to get agents.
- Gross up for shrinkage.
Worked example
120 chats arrive in a 30-minute interval. Each takes 600 seconds of elapsed time at the agents’ normal concurrency. The target is 80 per cent first response within 30 seconds, with an 85 per cent occupancy ceiling and 30 per cent shrinkage.
Workload: 120 ÷ 30 × 10 = 40 erlangs. Erlang C needs 48 slots to meet the target under the ceiling, giving 89.5 per cent service level at 83.3 per cent slot occupancy.
| Concurrency | Slots needed | Agents | Agents to schedule |
|---|---|---|---|
| 1 | 48 | 48 | 69 |
| 2 | 48 | 24 | 35 |
| 3 | 48 | 16 | 23 |
The slot count does not change with concurrency; only how many agents it takes to provide it. Going from one chat at a time to two halves the requirement, which is the whole business case for chat, provided the handle time does not rise.
The shortcut and where it goes wrong
The common alternative divides handle time by concurrency and runs voice Erlang C on the result: 600 seconds at concurrency two becomes 300 seconds, and each agent is one server. It has the same total capacity as the slot model, but it models fewer, faster servers instead of more, slower ones, and queues do not behave the same way.
For the 120-chat example the two agree at concurrency two (24 agents) and differ by one at concurrency three (17 against 16). For a small team they diverge more: 30 chats in the same interval at concurrency two needs 14 slots and 7 agents in the slot model, while the shortcut says 8. The slot model pools better, because 14 slow servers absorb random arrivals better than 7 fast ones do. The shortcut is not dangerous, but it is not the model of what happens on the floor, and the chat calculator reports both so you can see the gap for your own numbers.
The handle time trap
Concurrency does not come free. A chat that needs four minutes of an agent’s attention takes ten minutes of elapsed time when the agent is handling two others, because the customer waits between replies while the agent is typing to somebody else. The handle time to use is that elapsed figure, measured at the concurrency you plan with. Use the focused-attention time and you will understaff by roughly the concurrency factor, which is the most common way a chat staffing model fails.
The corollary is that raising concurrency past the point where handle time stops rising in proportion adds nothing. If going from three to four chats lengthens every chat by a third, throughput per agent is unchanged and every customer waits longer between messages. Most operations find the ceiling somewhere between two and four, depending on the complexity of the work.
Try it with your own numbers
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.
Common mistakes
- Planning with the maximum concurrency the tool allows rather than the average agents sustain.
- Using focused handle time instead of elapsed time. See above.
- Applying a voice occupancy ceiling to slots. 85 per cent slot occupancy is a good ceiling; 85 per cent agent occupancy at concurrency three means every agent is at the limit all interval.
- Forgetting first response versus reply time. The service level target is usually about the first response. Reply time inside a chat is governed by concurrency, not staffing.
Where next
- How to calculate Erlang C staffing: the model that runs on the slots.
- How to staff an email queue with a turnaround time: the other channel where voice Erlang gives the wrong answer.
Frequently asked questions
- Should I divide volume by concurrency or handle time by concurrency?
- Neither is quite right, and they give the same answer: both reduce the workload by the concurrency factor and treat each agent as one server. The slot model in this guide keeps the workload as it is and multiplies the servers, which is what actually happens. The shortcut is acceptable for large teams, where the models converge.
- What handle time should I use for chat?
- The elapsed time from the customer's first message to the chat closing, measured while agents are working at their normal concurrency. This is longer than the time a chat would take with the agent's full attention, and it is the figure your chat platform reports. Using the focused-attention time understates the requirement badly.
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.