Designing Multi-Org Workforce Planning Models for Global Follow-the-Sun Operations

How-To-Articles
1

Designing Multi-Org Workforce Planning Models for Global Follow-the-Sun Operations

What This Guide Covers

This masterclass details the architectural design and operational synchronization required to manage workforce planning across multiple Genesys Cloud organizations in a global “Follow-the-Sun” (FTS) model. By the end of this guide, you will be able to construct a unified capacity model that accounts for regional labor laws, timezone-shifted handoffs, and cross-org service level (SL) balancing, ensuring seamless customer experiences as interactions transition from one global theater to another.

Prerequisites, Roles & Licensing

Global WFM synchronization requires high-tier licensing and cross-org visibility.

  • Licensing: Genesys Cloud CX 3 or WFM Add-on for all participating organizations.
  • Permissions:
    • WFM > Forecast > View/Edit
    • WFM > Schedule > View/Edit
    • WFM > Planning Group > View/Edit
    • Directory > Division > View (for multi-division setups within a single org)
  • Infrastructure: Enterprise reporting tool (e.g., Genesys Cloud Global Analytics or a third-party BI tool) to aggregate data across the Org IDs.

The Implementation Deep-Dive

1. Defining the Multi-Org Data Aggregation Strategy

In a true FTS model, you often have separate Orgs for EMEA, AMER, and APAC due to data residency (GDPR) or historical growth. The challenge is that WFM is natively bounded by the Org ID.

Architectural Reasoning:
Do not attempt to use “Remote Agents” across Orgs for primary WFM. Instead, implement a Virtual Global Queue pattern. Each regional Org has its own local queues, but interactions are routed based on “Global Skill” availability using the Cloud-to-Cloud Interconnect or External Routing patterns.

The Trap:
Planning each Org in isolation. If EMEA finishes their day with a 2-hour backlog of emails and AMER starts their day with zero backlog, you lose the efficiency of the global pool.
The Solution: Implement a Global Backlog Mirroring Data Action. AMER’s WFM forecast must include the “Leftover Work” from EMEA as an immediate “Inflow” at the start of their shift.

2. Timezone-Shifted Handoff Protocols

FTS operations fail at the “seams” - the 2-hour windows where one region is winding down and another is spooling up.

Configuration Step:
In your WFM Planning Groups, create “Overlap Shifts.”

  • EMEA Late Shift: 2:00 PM - 10:00 PM CET
  • AMER Early Shift: 6:00 AM - 2:00 PM EST
    This 2-hour overlap (assuming 6 hours between London and New York) allows for “Live Handoffs” and prevents the catastrophic SL drop that occurs when a queue is completely emptied of agents for even 5 minutes.

3. Cross-Org Service Level (SL) Balancing

Different regions have different labor costs and performance targets. A 20-second SL might be standard in the US, while a 60-second SL is acceptable in certain European markets.

The Trap:
Enforcing a single, rigid Global SL across all Orgs without accounting for regional staffing constraints. This leads to “Queue Poaching” where the higher-performing region is constantly burdened with the overflow of the lower-performing region.
The Solution: Implement Tiered Overflow Thresholds.

  • Tier 1: Local Org handles its own traffic (0-30s EWT).
  • Tier 2: If EWT > 60s, “Overflow Agents” in the next FTS region become eligible.
  • Tier 3: If EWT > 180s, the “Primary Pool” in the next FTS region handles the traffic.

4. Global Forecast Normalization

Volume in APAC (e.g., Japan) has different seasonality and public holiday patterns than AMER. Your global WFM model must use a Normalized Interaction Volume (NIV).

WFM Logic:
When importing historical data into the AMER Org, you must “Time-Shift” the data to the local timezone but maintain the original “Interaction Intensity” (Interactions per Interval). Use the WFM API to batch-upload historical data that has been cleaned of regional anomalies.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Handoff Orphan” Interaction

  • The failure condition: A customer is chatting with an EMEA agent. The agent’s shift ends, they disconnect, and the customer is left in a “zombie” state because the AMER Org doesn’t see the active session.
  • The root cause: Lack of Cross-Org Session Persistence.
  • The solution: Use Genesys Cloud Web Messaging with “Authenticated Context.” This allows the session to persist in the cloud. When the EMEA agent leaves, the script should detect the disconnect and “Re-Route” the session to the AMER queue with the full conversation history preserved.

Edge Case 2: Divergent ACD Proficiencies

  • The failure condition: AMER agents are failing to solve EMEA technical issues, leading to high transfer rates and poor CSAT.
  • The root cause: “Skill Drift.” The “Technical Support” skill in EMEA requires Level 2 certification, but the AMER skill of the same name only requires Level 1.
  • The solution: Implement a Global Skill Proficiency Audit. A central WFM team must govern the skill names and proficiency requirements across all Orgs to ensure a “Technical Support” interaction is handled with the same level of expertise regardless of the sun’s position.

Official References