What is agent concurrency?
Agent concurrency is the number of customer conversations a single support agent is handling at the same time. On WhatsApp, an agent with a concurrency of 4 has four open chats in their queue and switches between them as customers reply. Teams set a concurrency cap — the maximum number of open conversations the routing engine will give one agent — so work is spread evenly and nobody drowns.
Concurrency exists because messaging is asynchronous. A customer typing from a bus in Pune may take two minutes to answer a question, and in that gap the agent can reply to someone else. That is the big operational difference from voice support, where an agent is locked to one caller. It is also why chat teams can serve more customers per agent hour, as long as the cap is set with care.
The cap is a setting in your shared team inbox or routing layer, not a WhatsApp rule: the Cloud API delivers messages to your number and knows nothing about agents. Auto-assignment reads the cap when it decides who gets the next chat, so an agent at their limit is skipped until a conversation closes or goes quiet.
Agent concurrency is often confused with average handle time (AHT). Concurrency is how many chats run in parallel; AHT is how much agent time each chat consumes. They pull against each other: pushing concurrency up usually stretches each conversation, because the agent is context-switching more often.
Key takeaways
- Agent concurrency is the number of conversations one agent has open and is actively working at the same moment.
- Chat allows concurrency above 1 because customers reply in bursts; a phone call is always one at a time.
- The cap is set in your inbox or routing tool; the WhatsApp Cloud API has no concept of agents or concurrency.
- Raise the cap only while first response time and CSAT hold; when either slips, the cap is too high.
- Concurrency and average handle time interact: more parallel chats usually stretch the handle time of each one.
Why the difference matters
Why does agent concurrency matter?
Concurrency is the biggest lever on support staffing cost for a chat team. Too low and agents sit idle between replies while customers wait in the queue; too high and replies get slower, shorter and more error-prone, CSAT drops and conversations reopen. Because service replies on WhatsApp have been charged per message in India since 1 October 2026, sloppy replies that need a second or third message also cost more than they used to.
How does agent concurrency work?
- Step 1
Measure what agents actually juggle
Pull a few weeks of inbox data and look at how many conversations each agent had open at once, alongside first response time and CSAT for each level.
- Step 2
Pick a starting cap per queue
Simple order-status chats tolerate more parallel work than refunds, KYC checks or complaints. Set a separate cap per team or skill rather than one number for everyone.
- Step 3
Let routing enforce it
Configure auto-assignment to skip agents who are at their cap, so new chats wait in the team queue instead of piling onto one person.
- Step 4
Decide what counts as open
Exclude conversations waiting on the customer for a long time (snoozed or pending) from the count, or a few silent chats will block an agent from new work.
- Step 5
Review weekly and adjust
Raise the cap by one when response times and quality are comfortably inside target; lower it when either slips, or during sale peaks with complex queries.
Example: A sale weekend in Jaipur
A Jaipur home-decor brand runs four agents on WhatsApp with a cap of 5. During a festive sale, first response time doubles and CSAT falls, even though every agent is at 5. The inbox shows why: most new chats are about delivery slots and need a courier lookup each time. The team splits the queue: delivery-slot chats get a cap of 6 with canned responses and a lookup shortcut, while return and damage claims get a cap of 3. Response times recover within a day without hiring.
Common mix-ups
Common mistakes with agent concurrency
One cap for every kind of chat
A complaint with photos and a refund calculation needs far more attention than a tracking request. Set caps per queue or skill, and review them separately.
Counting dormant chats as load
If conversations waiting on the customer stay in the count, agents hit their cap while doing nothing. Move them to a pending state that frees a slot, and pull them back when the customer replies.
Reading high concurrency as high productivity
More open chats can mean agents are slower to close them, not faster. Judge concurrency together with resolution time and first contact resolution, never on its own.
Ignoring the 24-hour window
An overloaded agent who leaves a chat untouched for a day lets the 24-hour customer service window close, and a template is then needed to reach the customer. Alert on chats approaching that limit.
Agent concurrency: key facts and limits
- Unit
- Open conversations per agent at one moment
- Where it is set
- Inbox or routing tool, per agent, team or skill
- Voice equivalent
- Always 1 (one call at a time)
- WhatsApp API limit
- None — the Cloud API has no agent concept
- Signals the cap is too high
- Rising first response time, falling CSAT, more reopens
Rules of thumb
Best practices for agent concurrency
- Start new agents on a lower cap and raise it as they learn the canned responses and tools.
- Show each agent their current load in the inbox so they can ask for help before they hit the cap.
- Lower caps temporarily during outages, when every chat is long and emotional.
- Track concurrency by hour: the right cap at 11 a.m. may be wrong at 9 p.m.