Designing Bullseye Routing Expansion Strategies with Dynamic Skill Relaxation Timers

How-To-Articles
1

Designing Bullseye Routing Expansion Strategies with Dynamic Skill Relaxation Timers

What This Guide Covers

This guide details the architectural configuration of Genesys Cloud Bullseye routing with tiered skill expansion and time-based relaxation thresholds. You will configure a queue routing strategy that begins with a narrow skill match, expands to broader skill groups after defined wait intervals, and dynamically adjusts those intervals based on real-time queue metrics to balance first call resolution against abandon rates.

Prerequisites, Roles & Licensing

  • Licensing Tier: CX 1 minimum for Bullseye routing support. CX 2 or CX 3 recommended for advanced routing analytics and WEM integration.
  • Permission Strings: Routing > Queue > Edit, Routing > Skill Group > Edit, Routing > Routing Strategy > Edit, Routing > Queue > View
  • OAuth Scopes: routing:queue:write, routing:queue:read, routing:skill:read, routing:strategy:write
  • External Dependencies: Existing skill matrix aligned to business process tiers, agent groups mapped to shift patterns, and a middleware or orchestration layer capable of executing REST API calls at 30-second intervals.

The Implementation Deep-Dive

1. Architecting the Skill Hierarchy and Priority Weights

Bullseye routing evaluates expansion rules sequentially. The platform does not score skills holistically. It processes the first rule until the configured wait threshold expires, then moves to the next rule. This sequential evaluation requires a strictly ordered skill hierarchy that reflects business criticality rather than functional overlap.

You must design skills to represent discrete service tiers. A common pattern uses three tiers: exact specialization, cross-trained capability, and generalist fallback. Each tier requires a distinct skill identifier. You assign these skills to queues and agents with explicit priority weights. The priority weight determines agent selection within a tier when multiple agents match the same skill.

The Trap: Assigning overlapping skills to the same priority weight across multiple expansion rules. When two rules share the same skill at equal priority, the routing engine selects agents non-deterministically. This causes call distribution skew, where some agents receive disproportionate volume while others remain idle. The downstream effect is increased average handle time and degraded service level adherence.

Architectural Reasoning: We enforce a strict priority decay across expansion tiers. Tier 1 skills receive a priority weight of 10. Tier 2 skills receive a weight of 5. Tier 3 skills receive a weight of 1. This ensures that within any given expansion window, the engine always favors higher specialization. We also disable skill inheritance across unrelated business units to prevent unintended routing bleed during expansion.

Create the skill matrix using the Queue and Skill Group API. The following payload demonstrates a tiered skill assignment for a queue routing strategy:

PUT /api/v2/routing/queues/{queueId}
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "name": "Premium Support Queue",
  "routingStrategy": {
    "type": "BULLSEYE",
    "enabled": true,
    "skills": [
      {
        "skill": {
          "id": "skill-tier1-specialist",
          "name": "Tier1_Specialist",
          "type": "ROUTING"
        },
        "priority": 10
      },
      {
        "skill": {
          "id": "skill-tier2-crosstrained",
          "name": "Tier2_CrossTrained",
          "type": "ROUTING"
        },
        "priority": 5
      },
      {
        "skill": {
          "id": "skill-tier3-generalist",
          "name": "Tier3_Generalist",
          "type": "ROUTING"
        },
        "priority": 1
      }
    ],
    "expansionRules": [
      {
        "type": "skill",
        "skillId": "skill-tier1-specialist",
        "waitTime": 15000
      },
      {
        "type": "skill",
        "skillId": "skill-tier2-crosstrained",
        "waitTime": 30000
      },
      {
        "type": "skill",
        "skillId": "skill-tier3-generalist",
        "waitTime": 60000
      }
    ]
  }
}

The waitTime field represents the maximum duration the queue waits for a match within that specific tier before expanding to the next rule. These values are static at configuration time. We adjust them dynamically in subsequent steps.

2. Configuring Tiered Expansion Rules with Time Thresholds

Expansion rules dictate the routing boundary at each stage. Bullseye evaluates the first rule and holds calls in the queue until either an available agent matches the skill or the waitTime expires. Upon expiration, the engine adds the next skill to the matching pool. The routing strategy does not reset. Calls that entered during Tier 1 evaluation remain eligible for Tier 2 and Tier 3 expansion.

You must align thresholds with historical abandon curves. Calculate the 90th percentile wait time for each skill tier using queue analytics. Set the threshold slightly above that percentile to capture most specialized matches before expansion. This prevents premature relaxation that degrades first call resolution.

The Trap: Configuring identical or overlapping wait times across expansion tiers. If Tier 1 and Tier 2 both use 30 seconds, the routing engine evaluates both tiers simultaneously when the first threshold expires. This collapses the relaxation logic into a single burst. The downstream effect is a sudden spike in call distribution to lower-tier agents, causing queue congestion and increased callback rates.

Architectural Reasoning: We enforce a minimum 15-second differential between consecutive thresholds. This staggered approach allows the routing engine to process expansion sequentially. We also configure the longestIdleAgent routing strategy within each tier to distribute calls evenly across available agents. This prevents agent starvation during expansion transitions.

The expansion rule evaluation order is strictly top-down. The platform does not re-evaluate previously expired tiers. Once a call enters Tier 2, it never routes back to Tier 1, even if a Tier 1 agent becomes available. This design choice prevents routing loops and ensures predictable call progression. You must account for this behavior when designing fallback logic.

3. Implementing Real-Time Threshold Adjustment via API Orchestration

Static thresholds degrade under variable load. During peak hours, a 30-second Tier 1 threshold may cause excessive expansion. During off-peak hours, the same threshold may hold calls too long. Dynamic relaxation addresses this by adjusting thresholds based on real-time queue metrics.

You implement dynamic adjustment using an orchestration layer that polls queue metrics and updates the routing strategy via API. The layer reads current queue wait times, active agent counts, and service level breach probability. It calculates new thresholds using a weighted formula and pushes the updated configuration to the queue.

The Trap: Executing routing strategy updates at sub-10-second intervals. The Genesys Cloud API enforces rate limits on queue configuration endpoints. Frequent updates trigger throttling, which causes routing strategy thrashing. Thrashing results in inconsistent call distribution because the routing engine applies different configurations mid-evaluation. The downstream effect is call drops and unpredictable wait times.

Architectural Reasoning: We enforce a 30-second evaluation cycle for threshold updates. The orchestration layer aggregates metrics across the window, calculates a single threshold adjustment, and applies it atomically. We also implement delta validation. The layer only pushes an API request if the new threshold differs from the current value by more than 5 seconds. This reduces API call volume and maintains routing stability.

The following payload demonstrates a dynamic threshold update. The orchestration layer calculates new values based on current queue depth and agent availability:

PUT /api/v2/routing/queues/{queueId}
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "routingStrategy": {
    "type": "BULLSEYE",
    "enabled": true,
    "expansionRules": [
      {
        "type": "skill",
        "skillId": "skill-tier1-specialist",
        "waitTime": 12000
      },
      {
        "type": "skill",
        "skillId": "skill-tier2-crosstrained",
        "waitTime": 27000
      },
      {
        "type": "skill",
        "skillId": "skill-tier3-generalist",
        "waitTime": 54000
      }
    }
  }
}

The orchestration layer must preserve the skills array during updates. Omitting the skills array replaces the entire routing strategy, which clears agent skill assignments and breaks routing. Always include the complete skills configuration in every update payload.

4. Load Simulation and Expansion Verification

Configuration validation requires controlled load injection. You cannot verify expansion behavior with static agent availability. Bullseye only expands when the current tier cannot satisfy demand within the threshold. You must simulate tiered agent logins and inject calls at controlled intervals.

Use the Genesys Cloud Simulator or a synthetic call generation tool to inject calls into the queue. Configure agents to login sequentially across skill tiers. Monitor queue metrics using the Real-Time Monitoring API. Track call distribution per tier, wait time progression, and expansion trigger timestamps.

The Trap: Testing with all agents logged into the highest specialization tier. When all agents match Tier 1, the routing engine never triggers expansion. This masks threshold misconfigurations and relaxation failures. The downstream effect is deploying a routing strategy that appears stable in testing but fails under production load when specialist availability drops.

Architectural Reasoning: We simulate production shift patterns during testing. Tier 1 agents login at 60 percent capacity. Tier 2 agents login at 80 percent capacity. Tier 3 agents login at 100 percent capacity. We inject calls at a rate that exceeds Tier 1 capacity by 20 percent. This forces the routing engine to evaluate expansion thresholds. We capture expansion trigger events using the Queue Metrics API and verify that calls transition between tiers at the configured intervals.

The validation process requires correlating three data streams: call injection timestamps, agent availability changes, and routing strategy updates. You must verify that expansion occurs only after threshold expiration and that dynamic adjustments propagate without interrupting active call routing.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Threshold Collapsing During Agent Shift Transitions

  • The failure condition: Calls route to Tier 3 immediately after Tier 1 expiration, bypassing Tier 2 entirely.
  • The root cause: Agent shift transitions cause temporary availability gaps. When Tier 1 agents logout for break, the routing engine evaluates Tier 2. If Tier 2 agents are also transitioning, the engine perceives zero availability and fast-forwards to Tier 3. The dynamic threshold adjustment layer may also reduce thresholds aggressively during low-availability windows, accelerating the collapse.
  • The solution: Implement a minimum threshold floor in the orchestration layer. The layer must never reduce a threshold below 10 seconds. Configure agent group availability buffers using WEM scheduling to prevent simultaneous logout across tiers. Add a minimumAgents constraint to each expansion rule to ensure expansion only occurs when at least two agents match the target skill.

Edge Case 2: Expansion Rule Priority Inversion Under High Concurrency

  • The failure condition: Tier 2 agents receive higher call volume than Tier 1 agents during peak load, despite Tier 1 having higher priority weight.
  • The root cause: High concurrency saturates the Tier 1 matching pool. The routing engine evaluates Tier 1 agents but finds none available within the threshold. It expands to Tier 2. If Tier 2 agents have shorter average handle times, they become available faster and accumulate more calls. The priority weight only influences selection within a tier, not across tiers. Once expansion occurs, the engine treats all matching tiers as a single pool.
  • The solution: Enforce tier isolation using queue splitting. Create separate queues for each tier and route calls sequentially using Architect. Configure a wait condition that holds calls in Tier 1 until threshold expiration, then transfers to Tier 2. This preserves priority boundaries and prevents cross-tier volume inversion. Alternatively, adjust Tier 2 skill priority to 0 and use longestIdleAgent routing to prevent rapid reassignment.

Official References