Can anyone clarify the exact logic used for occupancy calculation when Architect flows trigger external data actions?
We are seeing a significant variance in the Occupancy metric on the Queue Performance dashboard compared to the actual time spent in the Architect flow. The flow includes a 10-second wait and a Data Action node that calls an external middleware. The dashboard shows occupancy increasing by the full 10 seconds, but the conversation detail view suggests the timer stops during the data action execution. This discrepancy is affecting our service level reporting. Is the dashboard counting the data action latency as occupied time, or is there a configuration in the flow that needs adjustment to align these metrics?
According to the docs, they say that occupancy metrics in Genesys Cloud are calculated based on the total time an agent is in a “busy” status, which includes all interactions within the Architect flow. However, external data actions triggered by the flow can introduce latency that is not always accurately reflected in the dashboard’s real-time calculations. This discrepancy often arises because the dashboard updates in near real-time, while the conversation detail view provides a more granular, post-processing analysis of the interaction timeline.
To address this, ensure that the external middleware call is optimized for speed and consider using asynchronous processing for non-critical data retrieval. Additionally, monitor the WebSocket connections for any delays that might affect the real-time display of occupancy metrics.
Note: Always validate your custom integrations against the platform’s recommended best practices to ensure accurate metric reporting.