Architecting Follow-the-Sun Routing with Automatic Timezone-Aware Queue Selection

How-To-Articles
1

Architecting Follow-the-Sun Routing with Automatic Timezone-Aware Queue Selection

What This Guide Covers

This guide details the implementation of a global call distribution strategy where incoming traffic is automatically routed to the regional support team currently active during business hours. The end result is a seamless caller experience where users in Asia connect to APAC agents, while callers from Europe connect to EMEA agents, without manual intervention or complex IVR menus. Upon completion, you will have a production-ready routing architecture that respects local time zones and maximizes agent utilization through automatic load balancing across global regions.

Prerequisites, Roles & Licensing

To implement this architecture, the following environment constraints must be satisfied before configuration begins.

Licensing Requirements

  • Platform: Genesys Cloud CX (Cloud Contact Center).
  • License Tier: Genesys Cloud CX Premium or Enterprise. Basic licenses do not support advanced Time Zone routing logic within Routing Strategies.
  • Add-ons: Skills-Based Routing and Advanced Queue Configuration must be enabled in the organization settings.

Granular Permissions
The engineer performing this configuration requires specific granular permission strings assigned to their User Profile. Do not rely on default administrator roles as they may lack audit trails for specific routing changes.

  • routing:queues:edit: Required to modify queue properties and business hour definitions.
  • routing:strategies:edit: Required to create and modify the Routing Strategy logic.
  • users:read and users:write: Required to update User Profile Time Zones for agents.
  • telephony:trunks:read: Required to inspect incoming SIP headers for caller identification data.

OAuth Scopes (For API-Driven Enrichment)
If utilizing the API enrichment method described in Step 1, the service account must hold the following OAuth scopes:

  • routing:queues:write
  • flow:read and flow:write
  • users:read

External Dependencies

  • CRM System: A backend system (Salesforce, ServiceNow, or custom database) capable of storing user time zone preferences via API.
  • Carrier SIP Headers: The Session Initiation Protocol (SIP) provider must support passing caller location data in headers such as P-Asserted-Identity or a custom header like X-Caller-Timezone.

The Implementation Deep-Dive

1. Caller Timezone Detection Architecture

The foundational requirement for Follow-the-Sun routing is the accurate identification of the caller’s local time zone. You cannot rely on the system clock of the SIP trunk endpoint as it often reflects UTC or the carrier’s central location. The architecture must dynamically determine the timezone at the moment of call initiation.

Architectural Decision: API Enrichment vs. IVR Collection
A common novice approach involves an Interactive Voice Response (IVR) asking the caller to select their region. This creates high friction and increases Average Handle Time (AHT). The superior architectural decision is to enrich the call context using a synchronous REST API call within the initial flow logic before routing decisions are made.

We perform this enrichment by querying a Customer Relationship Management (CRM) system or an internal lookup table based on the caller’s phone number (ANI) immediately after the call enters the Flow. This ensures the time zone is known before the Routing Strategy executes.

Implementation Steps:

  1. Create a Flow specifically for inbound call processing.
  2. Add a Set Data node to capture the ANI (Automatic Number Identification).
  3. Use an API Action node to query your external database or CRM using the ANI as the key.
  4. The API response must return a valid IANA Time Zone string (e.g., America/New_York, Asia/Tokyo).

Production-Ready API Payload Example:
When configuring the API Action node in Genesys Cloud, use the following payload structure to ensure compatibility with the Flow context.

{
  "method": "GET",
  "url": "https://api.crm-system.com/v1/timezone/lookup?phone={Contact.ANI}",
  "headers": {
    "Authorization": "Bearer {{OAuth.Token.AccessToken}}",
    "Content-Type": "application/json"
  },
  "body": null,
  "responseMapping": {
    "timezoneId": "$.data.timezone_id",
    "regionCode": "$.data.region_code"
  }
}

The Trap:
The most common failure in this step is assuming the API response is instantaneous. Network latency between Genesys Cloud and your CRM can introduce delays of 200 to 500 milliseconds. If you place a Connect node immediately after the API Action without buffering or error handling, callers may experience silence or premature disconnection during high-load periods.

Mitigation:
Always implement a timeout threshold in the API Action configuration set to 3 seconds. If the CRM does not respond within this window, the Flow must fall back to a default region (e.g., US East) rather than failing the call. This ensures continuity over perfection. Furthermore, ensure the responseMapping keys match exactly what your subsequent Routing Strategy conditions expect. Mismatched keys result in null values which break conditional logic.

2. Queue and User Profile Configuration

Once caller time zones are available as data attributes within the Flow context, you must configure the destination queues to handle these requests based on business hours.

Step 1: Define Regional Queues
Create distinct queues for each region (e.g., US-Support, EMEA-Support, APAC-Support). Do not use a single global queue with split logic, as this creates a single point of failure and complicates reporting.

For each regional queue, configure the Business Hours definition to match the local working hours of that region.

  • Queue Name: Global-US-Queue
  • Time Zone: America/New_York
  • Hours: Monday-Friday, 09:00 - 18:00 (Local Time)

Step 2: Configure User Profiles
Every agent assigned to a queue must have their User Profile Time Zone set correctly. This is critical for the system to calculate overlap availability accurately.

  • Navigate to Admin > Users.
  • Select an agent.
  • Edit the Time Zone field to match the region they support (e.g., Asia/Tokyo for an agent in Singapore).

Architectural Reasoning:
We separate Queue Business Hours from User Profile Time Zones because of load balancing requirements. A queue might operate 24 hours a day by routing to different regions, but individual agents only work specific shifts. The Routing Strategy evaluates the Queue availability against the Caller time zone. If the Queue is set to 24/7, the system will always attempt to route if any regional sub-queue has capacity.

Step 3: Configure Overflow Logic
Each regional queue must have an overflow configuration pointing to a fallback mechanism.

  • Overflow Type: Queue or Voicemail.
  • Destination: A generic After-Hours-Queue that handles calls when no region is open.

The Trap:
A frequent misconfiguration occurs when the Queue Time Zone does not match the Agent Profile Time Zone. For example, if a Queue is set to America/New_York but an agent in that queue has their profile set to America/Los_Angeles, the system may calculate the agent as unavailable during peak US-East hours because it interprets the local shift time incorrectly relative to the Queue definition.

Resolution:
Always align the Queue Time Zone with the majority of agents in that queue or the region being served. If the team is distributed, set the Queue Time Zone to UTC and define specific Business Hours windows for each agent individually, though this reduces reporting granularity. For Follow-the-Sun, aligning the Queue Time Zone to the region’s standard time is the preferred pattern.

3. Routing Strategy Logic

The core intelligence resides in the Routing Strategy. This component evaluates the caller context against queue availability and directs the call flow accordingly.

Strategy Configuration:

  1. Navigate to Admin > Routing.
  2. Create a new Routing Strategy named Follow-the-Sun-Global.
  3. Set the Default Route to Voicemail or Hold Queue (for outages).

Conditional Logic Implementation:
The Routing Strategy must evaluate the Caller Time Zone attribute passed from the Flow API enrichment in Step 1. You will create conditions based on this attribute to direct traffic to specific queues.

Logic Structure:

  • Condition A: If Flow.Data.timezoneId contains America/ (US or Canada) AND Current Local Time is within Business Hours → Route to Global-US-Queue.
  • Condition B: If Flow.Data.timezoneId contains Europe/ OR Asia/London → Route to Global-EMEA-Queue.
  • Condition C: If Flow.Data.timezoneId contains Asia/ (excluding Japan) OR Australia/ → Route to Global-APAC-Queue.

Implementation via Flow Condition:
While Routing Strategies handle the initial distribution, complex logic often requires a custom Flow. Use the following JSON structure for a Condition node in your inbound Flow before connecting to the Routing Strategy. This allows you to make the decision dynamically based on real-time time calculations rather than static mappings.

{
  "condition": {
    "operator": "contains",
    "operand1": "{{Flow.Data.timezoneId}}",
    "operand2": "America/New_York"
  },
  "result": true,
  "target": "Connect.US.Queue",
  "fallback": {
    "condition": {
      "operator": "contains",
      "operand1": "{{Flow.Data.timezoneId}}",
      "operand2": "Europe/"
    },
    "result": true,
    "target": "Connect.EMEA.Queue"
  }
}

Architectural Reasoning:
We prefer Flow-based conditions over pure Routing Strategy conditions for this use case because the Flow allows us to perform time zone arithmetic on the fly. The system can check now() in the context of the Caller Time Zone to determine if it is business hours, rather than relying solely on the Queue Business Hours configuration. This decouples the decision logic from the queue availability settings.

The Trap:
Engineers often attempt to use the system’s current time (UTC) for all comparisons without conversion. If you write a condition that checks Current Time < 18:00, this time is in UTC by default in many Genesys configurations. A call coming from Japan at 02:00 UTC (which is 11:00 AM Tokyo time) will be routed incorrectly if the logic assumes it is night time globally.

Resolution:
Ensure your Flow Data includes a normalized timestamp in the caller’s local time zone. You must use the Convert Time Zone function within the Flow API Action or a dedicated Set Variable node to convert the system UTC timestamp to the Caller Time Zone string before evaluating business hours logic. Never assume the platform default is local time for conditional routing.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Daylight Saving Time (DST) Transitions

The most volatile period for global routing occurs during Spring Forward and Fall Back transitions. Different regions observe DST on different dates (e.g., the US in March, Europe in late March, Australia in October).

Failure Condition:
Calls from a region that has not yet switched to DST are routed to agents who have already switched, or vice versa. This results in calls routing to queues with zero active agents because the system time calculation is desynchronized.

Root Cause:
The Queue Business Hours definition was updated to reflect the new DST time zone shift, but the Routing Strategy logic relied on a cached time zone value that had not refreshed. Additionally, if the caller’s phone number (ANI) does not return a valid IANA Time Zone string during the transition window, the Flow defaults to a static UTC comparison which fails.

Solution:
Implement a fallback mechanism in the API enrichment step. If the CRM returns a null or invalid time zone ID during the DST transition window, trigger a secondary lookup using the caller’s geographic IP address or carrier prefix (NPA-NXX) to approximate the region. Ensure all Queue Business Hours definitions are set to “Automatic DST Adjustment” if available in your platform settings, rather than hard-coded dates.

Edge Case 2: Caller Spoofing Time Zone Data

Insecure implementations that rely on SIP headers for time zone data can be manipulated by callers using softphone applications or VoIP clients that allow custom header injection.

Failure Condition:
A caller from a region with no support capacity (e.g., Antarctica) spoofs their time zone to match a region with high capacity (e.g., US-East). The system routes the call to US agents, causing load imbalance and potential agent burnout.

Root Cause:
The Routing Strategy trusts the X-Caller-Timezone header provided by the carrier without validation against a trusted source of truth.

Solution:
Do not trust SIP headers for critical routing decisions. Always prioritize data from a CRM lookup or internal database associated with the caller’s phone number (ANI). The API enrichment method described in Step 1 is immune to this spoofing because it relies on a persistent record of customer data, not transient network metadata.

Edge Case 3: High Load During Handover Periods

During the transition from one region’s business hours to another (e.g., US closing and APAC opening), call volume spikes as callers wait for local teams to open.

Failure Condition:
The system routes all overflow traffic to the next available region, overwhelming that team immediately. This leads to high abandonment rates in both regions.

Root Cause:
The Routing Strategy lacks a throttling mechanism or priority weighting between regions.

Solution:
Implement Time-Based Load Balancing. Configure the Routing Strategy to check for queue wait times before routing. If Queue.WaitTime > 60 seconds, do not route to the next region; instead, play an automated message indicating “We will return your call” or place the caller in a global hold queue. This prevents cascading load failures across time zones.

Official References