Concurrency is the metric everyone over-trusts
Live chat's superpower is that one agent can handle several conversations at once, and the temptation is to push that number ever higher because it looks like free efficiency. But concurrency has a ceiling, and past it every extra chat degrades all the others. Measuring workload well means finding that ceiling for your team — not assuming it is infinite.
Count the real load, not just the chat count
Three simple “what are your hours” chats are lighter than one gnarly technical case, so raw concurrent-chat count understates and overstates load by turns. A truer picture combines how many chats are open, how complex they are, and how long they run. An agent at “only two chats” may be underwater if both are hard; one at five easy ones may be cruising.
Find the point where more chats hurt
Watch what happens to response time and satisfaction as concurrency climbs. There is a number — often lower than managers hope — past which reply times stretch, answers get sloppy, and customers feel the agent is distracted. That inflection point is your real capacity per agent. Staffing to it protects quality; ignoring it trades quality for a vanity efficiency number.
Balance the load, and protect the people
Workload measurement is not only about efficiency; it is about not burning out your team. If the same strong agent silently absorbs the overflow every day, you will lose them. Distribute chats so no one is permanently drowning, and read the workload data as a staffing signal — a queue that is always full means you need more hands, not more heroics.
How MyLiveChat helps
MyLiveChat's reporting shows chat volume, response times, and how work is distributed across agents, so you can see where load concentrates and when the peaks hit. Reading concurrency next to response time and satisfaction is what tells you the real ceiling — and whether today's staffing is under it or over it.
Concurrent chats is the number everyone uses and the one that misleads most
“How many chats can an agent handle at once?” is the standard workload question,
and the standard answer — three or four — is close to meaningless without knowing
what kind of chats they are. Three password resets is a quiet morning. Three billing disputes
running simultaneously, each requiring lookups and careful wording, is more than most people can
do well.
Concurrency measures how many conversations are open, not how much thinking is required. It is
worth tracking, but as one input among several rather than the definition of load.
Four things that together describe real load
- Concurrency, including its peak. The average is comfortable and the peak is what actually hurts. An agent averaging two chats but regularly spiking to six is having a bad week that the average conceals.
- Handle time by topic. Not as a target, but as a weighting. It tells you which conversations are expensive so you can compare workloads honestly.
- Active typing time versus open time. A chat open for twenty minutes while the customer is away costs far less than one demanding constant attention.
- Interruption load. How often an agent is switching between conversations. Frequent switching is more tiring than sustained work and is invisible in every standard report.
Together these describe effort. Any one alone describes activity.
The invisible work
A large part of an agent’s day does not appear in chat statistics at all: post-chat
notes, internal escalation, following up on promises made yesterday, updating knowledge articles,
answering colleagues, and training. A team measured only on chat volume will quietly stop doing
these, which degrades everything downstream — particularly the documentation that keeps
handle times low.
If you plan capacity assuming agents are available for chat every minute they are working, you
will be short-staffed permanently. A realistic figure allows a meaningful share of the shift for
non-chat work; treating that as slack to be eliminated is how teams end up with no documentation
and rising handle times.
Read the shape of the day, not the daily total
Daily and weekly totals hide the thing that actually determines whether a shift felt
manageable. Support volume is spiky, and the spikes are usually predictable — Monday
mornings, the hour after a marketing send, the evening in consumer businesses, the first days
after a release.
Look at load by hour across a few weeks. Two useful outputs: where the peaks reliably fall,
which is a rota question rather than a headcount one; and how long the peaks last, since a
30-minute surge is absorbed by asking people to defer breaks while a three-hour one needs more
people online.
Sustainable is not the same as maximum
The maximum an agent can handle in an emergency is not the level to plan around. Run a team
at its ceiling continuously and the costs arrive later as errors, curt replies, falling
satisfaction, and turnover — and replacing an experienced agent costs far more than the
capacity that was squeezed out of them.
Signals that a team is over its sustainable line, in roughly the order they appear: post-chat
notes get shorter or stop, canned responses are sent without adapting them, satisfaction slips
while volume holds steady, and then people leave. Watching for the first two is more useful than
waiting for the last.
Never use workload numbers as individual league tables
Ranking agents by chats handled reliably produces the wrong behaviour: rushing, cherry-picking
easy conversations, avoiding the complex cases that need the most experienced people, and closing
chats prematurely. The metrics stay healthy while the service gets worse.
Use workload data for capacity planning, rota design, and spotting individuals who are
struggling or overloaded so you can help them. Judge individual performance on quality —
read the conversations. Volume tells you how much a team needs; only reading tells you how well
it is being done.
Ticket counts and concurrency describe volume rather than cost. For the other half of the picture, logging the time your team spends on a ticket explains the append-only ledger behind the per-agent totals and how to read them honestly.