Overflow routing is a practical contact center mechanism used when the primary queue cannot handle a call under acceptable conditions. Instead of leaving the caller waiting in the same queue, the flow can evaluate queue statistics and route the call to another queue when this gives the customer a better chance of being handled.
In our demo flow, the primary queue is DVB_99_Sales_Queue and the overflow queue is DVB_99_Expert_Queue. Let's demonstrate how to build the logic of the Webex CC flow for the business rule shown below:
If the primary queue has no logged-in agents,
and the overflow queue has logged-in agents,
and the expected wait time in the primary queue is greater than 30 seconds
or cannot be calculated,
then send the call to the overflow queue.
Otherwise, keep the call in the primary queue.
Why overflow routing is useful
In real contact center operations, overflow routing helps reduce unnecessary waiting when the primary queue is not in a good state. Typical examples include:
- no agents are logged in to the primary queue;
- the estimated wait time is too high;
- another team can handle the same type of customer request;
- the business wants to protect service levels during peak periods.
In this scenario, the flow checks the state of both queues before making the routing decision. This makes the overflow logic controlled, instead of simply sending calls to another queue without verifying that it can actually handle them.
Flow logic
The demo flow uses this sequence:
Start Flow
→ Play Welcome Message
→ AdvancedQueueInfo_OVF
→ GetQueueInfo_Main
→ Condition_For_OVF
True → QueueContact_OVF
False → QueueContact_Main
The important design point is that the flow checks both queues before placing the contact into a queue.
AdvancedQueueInfo_OVF activity checks the overflow queue DVB_99_Expert_Queue and gets its statistics, while GetQueueInfo_Main checks the primary queue DVB_99_Sales_Queue.
In this demo, both activities are used intentionally.
Technically, both Advanced Queue Information and Get Queue Info can return the number of logged-in agents for a selected queue. For example, both activities provide the LoggedOnAgentsAll output variable, which represents the total number of agents logged in across all Call Distribution Groups for the selected queue.
However, I use Advanced Queue Information for the overflow queue on purpose. The goal is not only to check whether agents are logged in to the overflow queue, but also to demonstrate how this activity can be used in a real routing scenario.
The main difference is in the type of queue information each activity is designed to provide.
Advanced Queue Information is typically used in scenarios where skills are part of the routing logic. It provides real-time queue and agent information, but it does not return EWT.
Get Queue Info is used when the flow needs PIQ and EWT for a selected queue. However, EWT does not work correctly for skills-based routing scenarios, where it returns -1.
Therefore, in this demo flow, AdvancedQueueInfo_OVF is used to check whether the overflow queue has logged-in agents, while GetQueueInfo_Main is used to retrieve EWT for the primary queue and make the overflow decision.
Below you can find examples of the configuration for those activities.
EWT Loopback defines the historical period from which queue statistics are taken to calculate Estimated Wait Time (EWT), which is the approximate waiting time before the call is connected to an agent.
In our example:
EWT Lookback = 5
means that the system takes statistics for this queue from the last 5 minutes and uses them to calculate the estimated wait time.
Condition expression
The Condition activity uses this expression:
{{GetQueueInfo_Main.LoggedOnAgentsAll <= 0 and
AdvancedQueueInfo_OVF.LoggedOnAgentsAll > 0 and
(GetQueueInfo_Main.EWT > 30000 or GetQueueInfo_Main.EWT == -1)}}
This condition means:
Primary queue has no logged-in agents
AND
Overflow queue has at least one logged-in agent
AND
Primary queue EWT is greater than 30 seconds OR EWT is unknown
The parentheses are critical:
(GetQueueInfo_Main.EWT > 30000 or GetQueueInfo_Main.EWT == -1)
Without these parentheses, the final or GetQueueInfo_Main.EWT == -1 could be evaluated independently from the overflow-agent check. That would allow the call to go to overflow even when the overflow queue has no logged-in agents. Pebble documentation states that and and or are used to join boolean expressions and that parentheses can be used to group expressions to ensure the desired precedence.
Handling EWT = -1
The expression includes this part:
GetQueueInfo_Main.EWT == -1
This is intentional.
Cisco documents that the Insufficient Information Flow branch of Get Queue Info is triggered when PIQ is valid and EWT has the value -1. In that case, PIQ can still be retrieved, but EWT cannot be calculated because of insufficient data.
In this demo, EWT == -1 is treated as a reason to overflow only when the other two checks are also true:
GetQueueInfo_Main.LoggedOnAgentsAll <= 0
AdvancedQueueInfo_OVF.LoggedOnAgentsAll > 0
So the call does not overflow just because EWT is unknown. It overflows only if the primary queue has no logged-in agents and the overflow queue has logged-in agents.
True and False outcomes
If the condition evaluates to True, the call is sent to QueueContact_OVF node (this queues the call to DVB_99_Expert_Queue)
If the condition evaluates to False, the call is sent to QueueContact_Main node (DVB_99_Sales_Queue, which is the main queue in our demo)
Final result
This test flow demonstrates a controlled overflow decision in Webex Contact Center:
Check overflow queue capacity
→ Check primary queue EWT and logged-in agents
→ Evaluate the condition
→ Queue the call to the best available target queue
The main benefit is operational control. The caller is not blindly sent to the primary queue when there are no logged-in agents and another suitable queue has logged-in agents. At the same time, the flow avoids sending calls to the overflow queue when nobody is logged in there.
No comments:
Post a Comment