Concurrency controls how many calls can be active at the same time across your organization. Every plan comes with a concurrency limit — for example, 20 concurrent calls on Standard or 100 on Enterprise.
Location: Left Sidebar → Concurrency
Your organization has a concurrency pool — a fixed number of slots that represent how many calls can run simultaneously. When a call starts, it takes a slot. When it ends, the slot is freed for the next call.
If all slots are full, new calls are queued and wait until a slot opens up.
The concurrency limit applies across all call types — webcall, chat, telephony outbound, and telephony inbound all share the same pool.
By default, all your concurrency slots are shared — any agent can use any available slot, first-come first-served. This works well when you have a single agent or when all agents have equal priority.
But when you have multiple agents with different priorities, you can reserve slots for specific agents. This guarantees that important agents always have capacity, even during peak traffic.
With no reservations configured, all slots are shared:
Example: Your org has 20 slots. Agent A is handling 15 calls and Agent B wants to make 10 calls. Agent B can only get 5 slots (20 - 15 = 5 available). The remaining 5 calls from Agent B will be queued.
When you reserve slots for an agent, those slots are guaranteed — no other agent can use them. This is useful when an agent handles critical calls that should never be queued.
Here’s the key rule: reserved slots are guaranteed, and agents can also use shared slots when they need more capacity.
Let’s walk through a scenario:
Agent A receives 3 more calls → reserved slots are full, so it takes 3 slots from the shared pool. Shared pool is now empty.
Reserved slots for one agent cannot be used by another agent, even if they’re sitting idle. If Agent A has 12 reserved slots but is only using 4, those 8 empty reserved slots are not available to Agent B — they’re held for Agent A.
Scenario 1: Agent within its reservation
Agent A has 10 reserved, currently running 7 calls → using 7 reserved slots, 0 shared.
Scenario 2: Agent exceeding its reservation
Agent A has 10 reserved, currently running 14 calls → using 10 reserved + 4 shared.
Scenario 3: Shared pool is full
Shared pool has 5 slots, all in use. Agent B has 8 reserved and is running 6 calls → Agent B gets its 6 calls through reserved slots, no shared needed.
Scenario 4: Agent with no reservations
Agent C has 0 reserved. It can only use the shared pool. If the shared pool is full, Agent C’s calls are queued.
Navigate to Concurrency in the sidebar. You’ll see:
Click the … menu next to any agent in the table, then select Edit reservations to change the values.
Click the … menu and select Remove agent to set all reservations to 0. The freed slots return to the shared pool immediately.
Changes take effect immediately. If you reduce an agent’s reservation while it has active calls, those calls continue running — no calls are ever dropped. The new limits apply to the next call that needs a slot.
If you’re just getting started or have a single agent, you don’t need reservations. The shared pool works perfectly for simple setups.
Only reserve slots for agents that handle critical workflows — like customer support or payment processing. Let lower-priority agents share the remaining pool.
If you reserve all your slots, the shared pool becomes 0. Agents can still work, but they can’t exceed their reservations even if other agents are idle. Leave some shared capacity for flexibility.
Watch the Concurrency page during high traffic. If agents are consistently queuing, consider upgrading your plan or adjusting reservations.
New calls are queued and wait for a slot to free up. Calls are dispatched in order as slots become available. No calls are dropped — they just wait.
No. The total reserved across all agents cannot exceed your org’s concurrency limit.
Reservations are set per call type (webcall, chat, outbound, inbound), but they all draw from the same org-level pool. An agent’s total reservation is the sum across all types.
Everything works as a shared pool — all agents compete equally for slots. This is the default behavior and works well for most use cases.
Yes. Changes apply immediately to new calls. Active calls are never interrupted — they continue until they end naturally.
Your concurrency limit is determined by your plan. Contact sales or upgrade your plan to increase it.