Standard Erlang C assumes something that's true for voice and false for chat: one agent handles one interaction at a time. Plug your chat volume and average session length straight into a voice-style Erlang C calculation without adjusting for concurrency, and the tool will confidently hand you a headcount number that is badly, sometimes dramatically, too high.
Why the single-session assumption breaks on chat
A voice agent on a call cannot start a second call at the same time. A chat agent regularly runs two, three, or more conversations simultaneously, reading one customer's message while another types their reply, switching attention across sessions the way a voice agent never can. Standard Erlang C has no concept of this. It treats every session as fully occupying one agent, which is exactly why running it unmodified on a chat queue produces a number with no relationship to how many agents you actually need.
The actual staffing difference
Take a chat queue: 200 chats in a 30 minute interval, 80% answered within 60 seconds. Per-session average handle time rises somewhat as agents run more concurrent conversations, since divided attention isn't free, but it doesn't rise anywhere near proportionally to the concurrency gained. Compare running standard Erlang C with no concurrency adjustment against the concurrency-adjusted calculation, at different concurrency levels:
| Concurrency | Per-session AHT | Naive Erlang C (no concurrency adjustment) | Correct, concurrency-adjusted staffing |
|---|---|---|---|
| 1x (voice-style) | 600s | 73 agents | 73 agents |
| 2x | 660s | 80 agents | 42 agents |
| 3x | 750s | 91 agents | 33 agents |
| 4x | 870s | 105 agents | 29 agents |
At 4x concurrency, the naive calculation actually goes up, not down, because it's reading the AHT inflation as more work per session without ever crediting the fact that one agent is now covering four of those sessions at once. The correct, concurrency-adjusted number drops sharply instead, from 73 down to 29 agents, because it accounts for what's actually happening: total agent capacity scaling with concurrency, offset only by the real but smaller AHT penalty concurrency introduces.
Why concurrency is not a clean multiplier
Notice the gap between concurrency and staffing reduction is not proportional. Doubling concurrency from 1x to 2x nearly halves headcount. Going from 3x to 4x barely moves the number, 33 down to 29. This is the AHT inflation catching up: past a certain point, running more simultaneous conversations slows each one down enough that the extra concurrency stops paying for itself, and pushing concurrency higher purely to cut headcount starts trading a real cost, slower resolutions, more customer-visible friction, lower quality, against a shrinking staffing benefit. Effective concurrency also isn't fixed across the board the way this simplified example treats it. It depends heavily on interaction complexity, a queue full of quick order-status questions supports higher concurrency comfortably; a queue full of complex technical troubleshooting does not, no matter what the platform's default multiplier assumes.
What this means for how you actually staff chat
Never run unmodified voice-style Erlang C on a chat or messaging queue and treat the output as usable. At minimum, divide your effective session volume by a realistic concurrency assumption before staffing, and adjust that concurrency assumption by intent or contact type rather than applying one flat number across a queue that includes both simple and complex interactions.
Measure your actual achieved concurrency and its effect on AHT from real data before locking in a staffing assumption. A concurrency target chosen from a vendor's marketing slide, rather than your own queue's actual complexity mix, is exactly how an operation ends up either badly overstaffed or, just as often, badly understaffed with agents quietly running fewer simultaneous chats than the staffing plan assumed.
Treat concurrency like any other staffing lever with a real cost, not a free efficiency gain. The point where AHT inflation catches up with concurrency gains is a genuine ceiling, not a target to push past for the sake of a lower headcount number on a report.
If you're staffing a voice queue, the Erlang C Staffing Calculator on this site runs the standard, single-session calculation correctly. For chat and digital channels, remember that the same calculator's output needs a concurrency adjustment applied on top before it reflects real staffing need, not a straight read of the number it returns.