Looking for advice on a discrepancy in Service Level calculations. The Performance Dashboard reports 85% SLA for the ‘Priority_Support’ queue, yet the underlying raw data export shows only 78%. This gap impacts our executive reporting.
SLA calculation variance exceeds 5% threshold for queue ID: 4a2b1c9d-8877-6655-4433-221100998877
Are there known caching delays in the European data centers, or is this a metric aggregation logic error within the dashboard configuration?
The discrepancy stems from how the Performance Dashboard aggregates real-time state versus the historical data export. The dashboard calculates SLA based on the answerTime relative to the serviceLevel threshold at the moment of closure, often excluding calls that were transferred or abandoned after the initial answer. The raw export, however, includes every leg and may double-count wait times for transferred interactions.
To align the metrics, filter the data export to exclude transfer and abandon disposition types post-answer. Additionally, verify that the serviceLevel configuration in the queue matches the dashboard view. If the dashboard uses a 20-second threshold but the export calculates based on a 15-second business rule, the variance will persist. Check the queue settings in Genesys Cloud under Routing > Queues > Service Levels. Ensure the “Include transferred calls in SLA” option is toggled consistently between the dashboard view and your reporting logic. This usually resolves the 5-7% gap seen in EU data centers due to asynchronous metric processing.
Oh, this is a known issue when migrating from Zendesk to Genesys Cloud. The suggestion above correctly identifies the aggregation difference. In Zendesk, SLA was often a static field on the ticket, calculated once upon creation. Genesys Cloud, however, uses real-time stream processing for the Performance Dashboard. The answerTime is compared against the serviceLevel threshold dynamically.
The raw export includes every interaction leg, including transfers. This means waitTime can be summed multiple times if a ticket is transferred between queues. The dashboard, by contrast, usually looks at the initial answerTime relative to the original serviceLevel. To fix this in your reports, ensure you are filtering by firstAnsweredTime rather than closedTime in your SQL queries. Also, check if your serviceLevel definition in Architect matches the queue settings exactly. Mismatches here cause the 5% variance you see. It’s a steep learning curve coming from Zendesk’s simpler model, but the real-time accuracy is worth the effort once aligned.