What is the correct way to reconcile Digital Channel Occupancy vs. Queue Wait Time in Performance Dashboard

What is the standard approach to interpret the discrepancy between the ‘Average Wait Time’ metric and the ‘Occupancy’ metric for digital channels in the Performance dashboard?

Our organization is running Genesys Cloud v2023-10. We have configured a standard digital queue with a maximum wait time of 60 seconds. In the Architect flow, we are using a ‘Wait for Agent’ block with a timeout set to 60 seconds.

The issue arises when analyzing the Performance dashboard reports. The ‘Average Wait Time’ for digital interactions consistently shows a value near zero, often less than 1 second. However, the ‘Occupancy’ metric for the same queue shows agents are at 85% capacity during peak hours (09:00-11:00 CET).

If agents are heavily occupied, one would expect a higher wait time. Yet, the dashboard indicates near-instantaneous connection. Is the ‘Wait Time’ metric excluding the time the customer spends in the ‘Queue’ block before being matched with an agent? Or is there a specific configuration in the Performance view that filters out digital wait times differently than voice channels?

We need to understand if the current dashboard settings are accurately reflecting the customer experience or if the metric definition for digital channels differs from voice. Any clarification on the calculation logic for digital occupancy versus wait time would be appreciated.

You need to look at the granularity of your reporting slices. The discrepancy usually stems from how Genesys Cloud handles digital interactions that exceed the queue timeout. When a contact times out after 60 seconds, it might still count towards occupancy if the agent picks it up later or if it stays in the “working” state due to asynchronous handling. Check your WFM schedule adherence settings to see if there is a mismatch in how digital channels are weighted against voice. Digital channels often have longer handle times, which skews occupancy metrics. Ensure your Architect flow explicitly clears the interaction state on timeout. Here is the corrected payload structure for the Data Action if you are syncing this data:

{
 "metrics": {
 "occupancy": "digital",
 "waitTime": "queue",
 "timeout": 60
 }
}

This ensures the metrics align with the actual agent availability rather than just the queue length.