Building Cascading Priority Overflow Routing Across Multiple Business Units

How-To-Articles
1

Building Cascading Priority Overflow Routing Across Multiple Business Units

Executive Summary & Architectural Context

In complex enterprise environments, the “One-Queue-to-One-Group” model inevitably fails during regional spikes, product launches, or staffing crises. A Principal Architect must design routing logic that doesn’t just “fail over” when a queue is full, but intelligently cascades across multiple business units based on priority, agent proficiency, and real-time wait thresholds.

The objective is to maximize resource utilization across the entire organization while protecting the Service Level (SL) of high-value interactions. This requires a multi-layered approach using Architect task loops, Bullseye routing, and dynamic priority adjustments.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 2 or 3 (Required for Bullseye Routing and advanced Architect logic).
  • Granular Permissions:
    • Routing > Queue > View, Search
    • Architect > Flow > Edit
    • Analytics > Queue Observation > View (for EWT checks)
  • Dependencies: Clearly defined Skill groups and Business Unit (BU) divisions.

The Implementation Deep-Dive

1. Layered Bullseye Routing Configuration

The first line of defense in an overflow strategy is Bullseye Routing. Instead of a binary “Queue A to Queue B” jump, Bullseye allows you to expand the agent pool within the same interaction context.

The Design Pattern:

  • Ring 1 (Target): Preferred agents with Skill: Technical Support and Proficiency >= 4.
  • Ring 2 (Expansion): Any agent with Skill: Technical Support (Proficiency 1-5).
  • Ring 3 (Overflow): Agents in a secondary Business Unit (e.g., Sales Support) who have a “Backup” proficiency in technical issues.

[!TIP]
Architectural Reasoning: Bullseye routing is superior to transferring between queues because the interaction maintains its original position in the virtual “Global Queue,” and all reporting metrics remain tied to the primary Intent.

2. The Task-Based Cascade Loop (The “Safety Valve”)

If Bullseye expansion fails to result in an answer within a specified time (e.g., 60 seconds), we move to a Cascading Task Loop in Architect.

Architect Logic Workflow:

  1. Initial Check: Before entering the queue, perform a Get Estimated Wait Time (EWT) check for the primary queue.
  2. Decision: If EWT > 300s, immediately boost the interaction’s Priority using the Update Data action.
  3. Looping Logic: Use a Loop or a series of Wait actions in the “In-Queue” flow.
  4. The Cascade Trigger: After X seconds of waiting, use the Transfer to ACD action to a different queue (e.g., Emergency_Global_Overflow).

[!WARNING]
The Trap: Naive admins often use the “Overflow” setting on the Queue configuration itself. The trap here is that the overflow queue might also be at capacity, creating a “ping-pong” effect where calls bounce between two overloaded queues, destroying the customer experience. Always use a Decision block to verify the health of the overflow destination (EWT or Agents On-Queue) before transferring.

3. Dynamic Priority Injection

To ensure that an overflowed call is handled with urgency in the second business unit, you must implement Priority Scaling.

Implementation Detail:
When the cascade logic determines that a call must move from BU_A to BU_B, do not just transfer it. Increase the Conversation.Priority attribute.

  • BU_A (Standard): Priority 10.
  • Cascade to BU_B: Priority 50.

This ensures that the “borrowed” agents in the second business unit see the overflowed call at the top of their list, ahead of their own lower-priority native tasks.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Drowning in Overflow” Scenario

The failure condition: Business Unit B is also underwater, and accepting overflow from Unit A causes Unit B’s service level to collapse.
The root cause: Lack of a “Circuit Breaker” in the overflow logic.
The solution: Implement a Global Variable or Data Table lookup that tracks the “Health” of Unit B. If Unit B’s SL is below 70%, Unit A’s flows should skip the cascade to Unit B and go straight to a voicemail or callback option.

Edge Case 2: Reporting “Double-Counting”

The failure condition: A single interaction appears as a “Disconnect/Abandoned” in Queue A and a “Handled” in Queue B.
The root cause: Transfer to ACD counts as a disconnect from the first queue.
The solution: Use the Analytics Conversation Detail record to track the segmentType: emit and segmentType: interact. Ensure your reporting team uses “Flow Outcome” or “External Tag” attributes (set via Update Data in Architect) to identify interactions that were successfully handled via cascade.

Official References