We are encountering a persistent data integrity issue within our Genesys Cloud Performance dashboards, specifically concerning the calculation of agent talk time for interactions initiated via the WebRTC softphone. The issue manifests when agents utilize Chrome-based browsers (Version 120+) on Windows 10 endpoints.
Our observation indicates a consistent 15-20 second variance between the ‘Talk Time’ metric reported in the standard Agent Performance view and the actual audio stream duration logged in the browser developer console. This discrepancy is not present in desktop client interactions, suggesting a potential latency or handshake timing issue specific to the WebRTC implementation.
The business impact is significant, as our quality assurance team relies on these metrics to calculate efficiency ratios. A consistent under-reporting of talk time skews our agent occupancy calculations and impacts incentive structures. We have verified that the Architect flow does not introduce any artificial delays or hold states during the conversation phase.
Could the community clarify if this variance is a known artifact of the WebRTC signaling process (specifically regarding the ICE candidate gathering phase) or if there is a configuration setting within the Engagement settings that we should adjust to align the dashboard metrics with actual media stream duration? We require a definitive explanation of how Genesys Cloud timestamps the start and end of the ‘Talk’ state for WebRTC sessions to ensure our reporting governance remains compliant.
Environment Details:
- Genesys Cloud Version: Latest Production Release
- Browser: Chrome 120.0.6099.130
- Endpoint: Windows 10 Enterprise
- Metric View: Agent Performance → Conversation Detail