Architecting Multi-Site Schedule Coordination for Follow-the-Sun Operational Coverage

What This Guide Covers

This guide details the architectural configuration required to implement seamless Follow-the-Sun (FTS) operational coverage across multiple geographic sites within a unified Genesys Cloud CX or NICE CXone environment. You will configure time-zone-aware scheduling, cross-site queue routing logic, and skill-based capacity balancing to ensure continuous service level adherence without manual intervention.

Prerequisites, Roles & Licensing

Licensing Requirements

• Genesys Cloud:
  • CX 1, 2, or 3 Licenses: For agents participating in the FTS rotation.
  • WEM (Workforce Engagement Management) Add-on: Mandatory for advanced scheduling, adherence monitoring, and real-time adherence (RTA) dashboards. Basic WFM is insufficient for complex multi-site logic.
  • Admin License: For configuring Architect flows and Queue settings.
• NICE CXone:
  • Standard or Premium Agent Licenses: For all participating agents.
  • WFM Add-on: Required for schedule optimization and adherence tracking.
  • IVR/Studio License: For configuring the multi-site routing logic.

Required Permissions (Genesys Cloud)

• Telephony > Queue > Edit
• Telephony > Queue > View
• Workforce Management > Schedule > Edit
• Workforce Management > Forecast > Edit
• Architect > Flow > Edit

External Dependencies

• Unified Directory Structure: Agents from all sites must reside in the same Organization or be federated via Directory Integration if using separate Orgs with a unified routing view.
• Time Zone Consistency: All agent profiles must have accurate timezone attributes set. Incorrect timezone metadata is the primary cause of FTS failures.
• Carrier/Trunk Redundancy: Each site must have independent telephony trunks or SIP trunks to prevent single-point-of-failure network outages from collapsing the entire FTS operation.

The Implementation Deep-Dive

1. Establishing Time-Zone-Aware Queue Routing

The foundation of FTS is not the schedule itself, but the routing logic that directs traffic to the active site. A common architectural error is relying solely on Agent Availability within a single global queue. This approach fails because it does not account for local business hours, shift changeovers, or site-specific capacity constraints. Instead, you must implement a Site-First, Skill-Second routing strategy.

The Architectural Pattern

Create a dedicated Queue for each geographic site (e.g., Queue_US_East, Queue_EU_West, Queue_APAC_Singapore). These queues share a common Skill set (e.g., Support_Level_1) but operate independently regarding capacity and service level objectives (SLOs).

In your top-level IVR (Genesys Architect or CXone Studio), implement a Routing Decision Block that evaluates the current UTC time against the business hours of each site.

Genesys Cloud Architect Configuration

Use the Set Variable block to determine the active region.

1. Set Variable: Current_UTC_Hour
   • Expression: {{now().hour}}
2. Set Variable: Active_Region
   • Use a Switch/Case block or If/Else logic.

Example Logic (Pseudocode for Architect Expression):

// Define business hours in UTC
// US East: 13:00 UTC to 21:00 UTC (09:00 EST to 17:00 EST)
// EU West: 08:00 UTC to 16:00 UTC (09:00 CET to 17:00 CET)

if (current_utc_hour >= 13 && current_utc_hour < 21) {
    return "US_EAST";
} else if (current_utc_hour >= 8 && current_utc_hour < 16) {
    return "EU_WEST";
} else {
    return "APAC_SINGAPORE";
}

3. Route to Queue:
   • Use a Route to Queue block.
   • Condition: If Active_Region equals US_EAST, route to Queue_US_East.
   • Else If Active_Region equals EU_WEST, route to Queue_EU_West.

The Trap: Overlapping Shifts and Transition Gaps

The Misconfiguration: Defining rigid time boundaries without accounting for shift overlap. If US East ends at 21:00 UTC and EU West starts at 08:00 UTC, there is a massive gap. However, in a true FTS model, the handoff is often gradual.

The Catastrophic Downstream Effect: During the handoff window (e.g., 15:00 - 16:00 UTC), if you route exclusively to the outgoing site, wait times spike as that site’s capacity drains. If you route exclusively to the incoming site, you may overwhelm them before their shift fully stabilizes.

The Solution: Implement Weighted Routing during transition windows.
In Genesys Architect, use a Set Variable to calculate a weighting percentage based on the time of day.

// Transition Window: 14:00 UTC to 16:00 UTC
// Linearly shift weight from US_East to EU_West

if (current_utc_hour >= 14 && current_utc_hour < 16) {
    // Calculate weight for US_East (100% at 14:00, 0% at 16:00)
    us_weight = 100 - ((current_utc_hour - 14) * 50);
    eu_weight = 100 - us_weight;
    // Use 'us_weight' as the probability or capacity multiplier in the routing decision
}

In CXone Studio, use the Dynamic Queue Assignment feature with Weighted Round Robin or Least Work logic, adjusting the weights via a Script Snippet that outputs the target queue ID based on the current timestamp.

2. Configuring Cross-Site Skill Balancing

While the IVR directs traffic to the primary site, you must ensure that if the primary site is overloaded or unavailable, traffic seamlessly fails over to the secondary site without breaking the customer experience. This requires Queue Cascading or Shared Skill Pools.

Approach A: Queue Cascading (Recommended for Strict SLA Isolation)

Configure the primary queue to cascade to the secondary queue when specific thresholds are met.

Genesys Cloud Queue Configuration:

1. Navigate to Admin > Telephony > Queues.
2. Edit Queue_US_East.
3. Go to Routing Rules.
4. Enable Cascading.
5. Set Cascade Thresholds:
   • Condition: Wait Time > 30 seconds OR Service Level < 80%.
   • Target Queue: Queue_EU_West (if active) or Queue_APAC_Singapore.
   • Important: Ensure the target queue is not in a “closed” state for its local agents. You must use Queue Hours or Architect Logic to ensure the target queue is actually accepting calls. If the target queue is outside its local business hours, cascading will result in immediate abandonment or voicemail.

The Trap: Cascading to a Closed Queue
The Misconfiguration: Setting up cascading rules that point to a queue whose associated agents are offline or whose queue hours are closed.
The Effect: Calls are routed to the secondary queue, but no agents are available to accept them. The call either abandons or falls back to voicemail, creating a false sense of coverage.
The Solution: Use Architect Pre-Validation. Before routing to the secondary queue, check the status of the secondary queue.

// Check if EU_West queue is active
if (get_queue("Queue_EU_West").status == "OPEN") {
    route_to("Queue_EU_West");
} else {
    route_to("Queue_APAC_Singapore");
}

Approach B: Shared Global Queue with Skill-Based Routing

Alternatively, place all agents from all sites into a single Global Queue (Queue_Global_Support). Assign them the same Skill (Support_L1). Use Routing Rules within the queue to prioritize agents based on their local business hours.

Genesys Cloud Routing Rule:

1. Create a Rule: Priority_Local_Agents.
2. Condition: Agent.Timezone == "America/New_York" AND Current_Time_In_Timezone(Agent.Timezone) is between 09:00 and 17:00.
3. Priority: 1.
4. Create a Rule: Priority_Secondary_Agents.
5. Condition: Agent.Timezone == "Europe/London" AND Current_Time_In_Timezone(Agent.Timezone) is between 09:00 and 17:00.
6. Priority: 2.

The Trap: Skill Imbalance
The Misconfiguration: Assuming all agents have identical skills. If US agents have English_US and EU agents have English_UK, the routing engine will not see them as interchangeable unless you map these skills to a common parent skill.
The Solution: Implement a Skill Hierarchy. Create a parent skill Support_Global and assign English_US and English_UK as child skills. Route to Support_Global. This ensures that any agent with any regional dialect can handle the call if the primary pool is exhausted.

3. WFM Schedule Optimization for FTS

Scheduling in an FTS environment is not about filling seats; it is about Capacity Handoff. The goal is to maintain a consistent service level across the 24-hour cycle.

Genesys Cloud WEM Configuration

1. Forecasting:

   • Run forecasts for each site independently.
   • Export forecast data to a centralized view.
   • Identify the Handoff Peaks. These are the periods where one site is ramping down and the other is ramping up.

2. Scheduling:

   • Use the Optimize feature in WEM.
   • Define Shift Patterns that span across time zones. For example, a “Late US” shift might overlap with the “Early EU” shift.
   • Critical Step: Enable Cross-Site Balancing in the optimization settings. This allows the scheduler to suggest moving capacity from a low-volume site to a high-volume site if agents are eligible (e.g., bilingual agents who can work across regions).

3. Adherence Monitoring:

   • Configure Real-Time Adherence (RTA) dashboards for each site.
   • Set up Alerts for “Capacity Deviation.” If the US site falls below 80% capacity during its peak, trigger an alert to the EU site manager to consider extending shifts or pulling from break banks.

The Trap: Ignoring Local Break Laws and Union Rules

The Misconfiguration: Creating a purely mathematical schedule that optimizes for coverage but violates local labor laws (e.g., mandatory rest breaks in the EU, overtime rules in the US).
The Effect: Legal non-compliance, agent burnout, and high turnover, which ultimately destroys the FTS model.
The Solution: Integrate Local Compliance Rules into the WFM constraints. In Genesys WEM, use Schedule Rules to enforce local labor laws. For example, add a rule: EU_Agents > Max_Consecutive_Hours = 10. This ensures the optimizer does not propose illegal shifts.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Daylight Saving Time (DST) Discrepancies

The Failure Condition:
In March or October, when the US and EU switch clocks at different times, the “active” window shifts by one hour. If your routing logic uses static UTC hours, you will route calls to the wrong site for one week per year.

The Root Cause:
Static UTC thresholds (e.g., 13:00 UTC) do not account for the dynamic nature of local business hours. When the US springs forward, 09:00 EST becomes 14:00 UTC, but your logic still routes at 13:00 UTC, sending calls to the US site while it is still technically 08:00 local time (before open).

The Solution:
Never hardcode UTC hours. Use Timezone-Aware Expressions.
In Genesys Architect:

// Get current local time for US East
us_local_time = now().tz("America/New_York");

// Check if US is open
if (us_local_time.hour >= 9 && us_local_time.hour < 17) {
    route_to("Queue_US_East");
}

This expression automatically adjusts for DST because the tz() function pulls the current offset from the IANA timezone database.

Edge Case 2: Site-Wide Outage Failover

The Failure Condition:
The US East site experiences a total network outage. The IVR still routes to Queue_US_East because the time logic indicates it is 10:00 AM local time. Calls queue up and abandon because no agents can log in.

The Root Cause:
The routing logic relies on Time as the primary decision factor, not Site Health.

The Solution:
Implement Health Check Variables.

1. Create a Set Variable block that queries the status of the US East site. This can be done via an Integration that polls a health endpoint or by checking the Queue Status of a “heartbeat” queue at that site.
2. Modify the routing logic:

if (us_site_health == "HEALTHY" && us_local_time.hour >= 9 && us_local_time.hour < 17) {
    route_to("Queue_US_East");
} else {
    // Failover to next best site
    route_to("Queue_EU_West");
}

In CXone, use the Queue Status object in Studio to check if the queue is Active and Not Paused. If the primary queue is inactive, bypass the time check and route to the secondary.

Edge Case 3: Agent Login Latency During Handoff

The Failure Condition:
During the handoff window, the outgoing site’s agents are logging off, and the incoming site’s agents are logging on. For a brief period, there are zero available agents in the target queue.

The Root Cause:
The routing logic assumes instantaneous capacity. It does not account for the Login Lag (time between shift start and agent ready status).

The Solution:
Implement Pre-Login Routing.

1. Configure the incoming site’s agents to log in 15 minutes before their shift start.
2. In the routing logic, add a Buffer Window.

// Start routing to EU 15 minutes before their official start time
if (eu_local_time.hour >= 8 && eu_local_time.minute >= 45) {
    route_to("Queue_EU_West");
}

Alternatively, use Capacity-Based Routing. Instead of time-based routing, route to the queue with the Lowest Average Wait Time or Highest Available Capacity. This naturally balances the load during the transition as agents come online.

Official References

• Genesys Cloud: Configure Queue Routing Rules
• Genesys Cloud: Architect Time Functions
• NICE CXone: Studio Routing Logic
• NICE CXone: Workforce Management Scheduling