No idea why this is happening, the Service Level Percentage displayed on the Queue Performance dashboard for our inbound messaging channels does not align with the actual conversation timestamps recorded in the Conversation Detail view. We are operating in the Europe/Paris timezone and have configured our SLA threshold to 60 seconds for first response. The dashboard consistently reports a 95% adherence rate, yet manual audits of the last 50 interactions reveal that approximately 15% of these conversations exceeded the 60-second mark significantly. This variance is causing issues with our internal compliance reporting and makes it difficult to justify resource allocation to the wider enterprise team.
The environment involves a standard Architect flow designed for digital engagement, utilizing the Web Chat and SMS connectors. No complex routing logic or predictive scoring is applied to these specific queues; they are simple priority-based queues with a static agent allocation. The issue persists across different time windows, including peak hours between 09:00 and 11:00 CET. We have verified that the agents are logging into the correct application versions and that their presence status is correctly set to ‘Available’. The discrepancy appears to be strictly within the metric calculation layer rather than the routing or agent availability layer, as the conversations are being delivered to agents without delay.
Has anyone encountered similar inconsistencies between the high-level dashboard metrics and the granular conversation logs for digital channels? We are using the standard Genesys Cloud performance views and have not implemented any custom attribute calculations that would override the default SLA logic. We need to understand if there is a known latency in the data aggregation pipeline for messaging channels or if there is a specific configuration setting within the queue definition that affects how the ‘first response’ timestamp is captured. Any insights into how the dashboard derives this percentage compared to the raw event data would be appreciated.