Architecting High-Fidelity Agent Utilization Models via Occupancy Rate and Idle Time Analytics
What This Guide Covers
This guide details the configuration of a robust utilization model within Genesys Cloud Workforce Engagement Management (WEM). You will configure occupancy thresholds and idle time exclusions to balance service level agreements against agent burnout risks. The end result is a validated Optimization Model that accurately forecasts required staffing based on productive work time rather than scheduled headcount.
Prerequisites, Roles & Licensing
To execute this configuration successfully, the following prerequisites must be met:
- Licensing Tier: Genesys Cloud CX Workforce Engagement Management (WEM) license with the Optimization add-on. Basic CCaaS licenses do not expose the Optimization Model API endpoints required for custom utilization logic.
- Granular Permissions: The executing user requires
Workforce Management > Schedules > EditandWorkforce Management > Utilization > View. For API-driven model deployment, the OAuth scopeoptimization:writeis mandatory. - Data Readiness: Historical data must contain at least 12 weeks of accurate schedule and activity logs. Inaccurate wrap time configurations will skew the baseline calculation immediately.
- External Dependencies: Ensure your telephony provider has pushed disposition codes correctly to the
Wrap Timemetric in Genesys Cloud. If wrap time is nullified, occupancy calculations will fail.
The Implementation Deep-Dive
1. Defining the Occupancy Baseline and Math Model
The foundation of any utilization model is the mathematical definition of “Occupancy”. In Genesys Cloud, this is not a static number but a calculated metric derived from the ratio of productive time to available time. You must define this explicitly within the Optimization Model configuration before assigning it to any schedule.
Configuration Steps:
Navigate to Workforce Management > Optimization > Models. Create a new model or edit an existing one named Occupancy_Baseline_v1. Within the Metrics tab, locate the definition for Agent Occupancy.
The system default calculates occupancy as:
Occupancy = (Total Talk Time + Total Wrap Time) / Total Scheduled Time
However, to ensure high fidelity, you must adjust the denominator. The standard calculation often includes “Unavailable” time in the denominator, which artificially deflates occupancy rates for agents who are on approved breaks or training. For a true utilization optimization model, exclude non-work intervals from the denominator.
The Trap:
A common misconfiguration occurs when administrators treat Scheduled Time as synonymous with Available Time. If an agent is scheduled for 8 hours but takes a 1-hour unpaid lunch break that is not marked as “Work Type” in Genesys, the system calculates occupancy over 8 hours. This results in a reported occupancy of 75% when it is actually 93%.
Architectural Reasoning:
We exclude non-work intervals to prevent the Optimization Engine from under-staffing. If the model believes an agent is only 75% utilized, it will schedule more agents than necessary to meet service levels because it assumes capacity exists in the current headcount that is not being used. By adjusting the metric calculation to Total Scheduled Time - Non-Work Intervals, you force the system to recognize the true productive capacity of your workforce.
API Payload for Custom Metric Definition:
To enforce this logic programmatically or via bulk import, use the following JSON payload structure when calling the Optimization Model API. This ensures consistency across environments (Dev, QA, Prod).
{
"id": "string-uuid-occupancy-model",
"name": "Occupancy_Baseline_v1_Produced",
"metricDefinitions": [
{
"metricName": "agentOccupancy",
"calculationType": "CUSTOM",
"expression": "(SUM(talkTime) + SUM(wrapTime)) / (SUM(scheduledTime) - SUM(nonWorkIntervals))"
}
],
"targetValues": {
"min": 0.60,
"max": 0.85,
"ideal": 0.75
},
"timeUnit": "MINUTE",
"reportingGranularity": "15_MINUTE"
}
This payload defines a custom calculation where non-work intervals are subtracted from the total scheduled time before division. The targetValues define the boundaries for the optimization algorithm to respect during schedule generation.
2. Configuring Idle Time Exclusions and Thresholds
Once the baseline is established, you must configure how the system treats idle time. Idle time is the period an agent is logged in but has no interaction waiting. In legacy systems, this was often conflated with utilization loss. In Genesys Cloud Optimization, idle time is a critical variable for burnout prevention but must not be counted as productive work.
Configuration Steps:
Within the Occupancy Thresholds section of the Optimization Model, set the Max Allowed Occupancy. This value should generally not exceed 85%. If you set this to 90%, the system will prioritize service levels over agent well-being, leading to schedule compression where agents have no recovery time between interactions.
Set the Min Allowed Occupancy to 60%. This ensures that during low-volume periods, agents are not scheduled unnecessarily if they cannot maintain a minimum level of activity.
The Trap:
The most frequent failure mode in this stage is failing to account for “System Idle” vs “Agent Idle”. Genesys Cloud distinguishes between an agent waiting for a call (System Idle) and an agent logged in but doing nothing (Agent Idle). If you configure the model to penalize low occupancy, the Optimization Engine may fill the schedule with agents who are technically “available” but effectively idle.
Architectural Reasoning:
We enforce a hard cap on occupancy to prevent cognitive fatigue. High utilization correlates directly with increased Average Handle Time (AHT) due to agent stress and reduced accuracy in data entry or call handling. By capping the model at 85%, you allow for the inherent variability of contact center traffic without burning out staff. This creates a “cushion” where agents can absorb spikes without violating service level agreements immediately.
Additionally, configure the Idle Time Sensitivity parameter. Set this to HIGH. This tells the Optimization Engine that idle time is a cost factor. If an agent is scheduled for 8 hours but only handles calls for 4 hours, the system should flag this as a scheduling inefficiency rather than acceptable utilization.
3. Integration with Real-Time Analytics and API
To ensure the model remains accurate over time, you must integrate it with real-time analytics via the REST API. Static configurations drift as business needs change. You cannot rely solely on manual UI updates for occupancy tuning.
Implementation Steps:
- Authenticate using OAuth 2.0 with the
optimization:readandanalytics:reporting:queryscopes. - Query the current utilization metrics from the
/api/v2/analytics/agents/dataendpoint to validate model performance against actuals. - Update the Optimization Model parameters if the variance exceeds a defined threshold (e.g., +/- 5%).
API Endpoint for Validation:
Use the following GET request to retrieve historical occupancy data for comparison against your model targets:
GET /api/v2/analytics/agents/data?dateGranularity=DAY&agentIds=[AGENT_ID]&metricNames=agentOccupancy,agentIdleTime,totalTalkTime
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json
Response Handling:
Parse the JSON response to extract agentOccupancy. If the value consistently exceeds 90% during peak hours, adjust the Max Allowed Occupancy in your model definition via a PUT request to /api/v2/optimization/models/{modelId}. This creates a feedback loop where the configuration adapts to traffic patterns rather than remaining static.
The Trap:
Do not use the Optimization Model API to update schedules directly without validating the data first. A common error is updating the model while the current schedule is locked for publishing. If you push a new threshold while a schedule is in “Published” status, the system will reject the change or create a conflict that requires manual intervention to resolve. Always ensure the target schedule period is in Draft status before applying API-driven metric updates.
Validation, Edge Cases & Troubleshooting
Edge Case 1: Schedule vs. Actual Utilization Drift
The Failure Condition:
You publish a schedule based on an 80% occupancy model. After two weeks, the reported actual occupancy is 95%, yet service levels are slipping. The optimization engine predicted availability that does not exist in reality.
The Root Cause:
This drift typically occurs due to “Schedule Leakage”. Agents may be logged into the system but marked as “Unavailable” for non-work reasons (e.g., waiting for IT support, personal calls) without a corresponding time-off code. The Optimization Model calculated occupancy based on Scheduled Time, but the actual productive time was lower because of unrecorded downtime.
The Solution:
Audit the Agent Status logs for the specific agents involved. Check for periods where status is Available but no interaction events are logged. Implement a rule in your WEM data ingestion pipeline that flags any Available status duration exceeding 30 minutes without activity as a potential data integrity issue. Update the Optimization Model to include a Status Availability Weighting factor of 0.95 to account for expected system latency and micro-interruptions.
Edge Case 2: Multi-Channel Impact on Occupancy Calculations
The Failure Condition:
Your team handles both Voice and Digital (Chat/Email). The model is calibrated for Voice, resulting in a predicted occupancy of 80%. Actuals show 50% utilization. Agents are complaining of boredom and low engagement.
The Root Cause:
Voice and Digital interactions have different dwell times. A voice call might take 5 minutes, while an email interaction takes 15 minutes but counts as only one interaction event. The standard Occupancy metric sums Talk Time and Wrap Time. If your model does not account for the longer handling time of digital channels within the same occupancy window, the agent appears underutilized because they are spending more time per interaction than the Voice-based model anticipates.
The Solution:
You must define channel-specific metrics in the Optimization Model. Create separate metric definitions for VoiceOccupancy and DigitalOccupancy. Map these to the respective contact types in the Interaction Routing configuration. When generating the schedule, set the Channel Mix Weighting parameter to reflect the expected ratio of Voice to Digital interactions (e.g., 70% Voice, 30% Digital). This ensures the model allocates time for longer digital interactions without falsely flagging agents as underutilized.
Edge Case 3: Peak Hour Compression
The Failure Condition:
During peak hours, occupancy spikes above the 85% threshold, causing service levels to drop. The system attempts to add more agents but cannot find them in the roster.
The Root Cause:
The Optimization Model is likely constrained by hard skill requirements or labor law restrictions that prevent the scheduling of additional staff during specific windows. The model calculates utilization based on available FTEs, not theoretical maximums.
The Solution:
Review the Hard Constraints section of the Optimization Model. Ensure there are no unnecessary constraints blocking agent availability during peak hours. Additionally, implement a “Soft Constraint” for overtime or split shifts that allows agents to work beyond standard 8-hour blocks if occupancy exceeds 85% for more than 30 minutes. This provides the necessary flexibility to absorb demand spikes without permanently altering the workforce size.