Architect Flow Timeout vs Performance Dashboard SLA Discrepancy

No idea why this is happening, the Performance Dashboard reports a 98% Service Level for our primary sales queue, while the actual Agent Experience shows a significant lag in call delivery times that correlates with specific Architect flow logic.

The environment is Genesys Cloud EU-West-1. We are running a standard IVR flow that routes calls based on skill-based routing. The flow includes a 30-second wait in a queue before attempting a second priority routing to a backup group.

When analyzing the Conversation Detail View for calls that exceed the 20-second SLA target, the system logs a QUEUE_TIMEOUT event at exactly 30 seconds. However, the Performance Dashboard aggregates this differently. It seems to count the call as answered within SLA if the agent picks up within the first 20 seconds, but if the call is retried or routed to the backup group and answered within the original 20-second window of the new attempt, the metric is skewed.

Specifically, we are seeing this behavior in the Queue Activity view:

{
 "queue_id": "sales-primary-eu",
 "service_level_percentage": 98.2,
 "target_seconds": 20,
 "total_calls": 1450,
 "answered_within_sl": 1425
}

Yet, the average speed of answer (ASA) is 14 seconds, which is healthy, but the 80th percentile wait time is 19.5 seconds. The issue arises when a call is transferred or re-routed by the Architect flow. The Performance Dashboard appears to reset the SLA timer upon the new queue entry, effectively double-counting the success metric.

Is there a way to configure the Performance Dashboard to track the original customer entry time rather than the current queue entry time for SLA calculations? We need the dashboard to reflect the true end-to-end customer experience, not just the final leg of the routing logic. The current metrics are misleading stakeholders regarding actual wait times.

This looks like a standard mismatch between how Genesys Cloud calculates Service Level (SLA) versus actual agent perception, especially if you’re coming from a Zendesk background where ticket status changes were the primary metric. In Zendesk, you might track “pending” time, but here, the SLA clock starts when the interaction enters the queue, not when the agent finally accepts it.

The 30-second wait in your Architect flow is likely the culprit. If the first priority group doesn’t answer within those 30 seconds, the flow moves to the backup group. However, the Performance Dashboard might be counting the initial entry into the first queue as the start time, while the agent experience reflects the total time including the retry logic.

To verify this, check the Queue Settings for your primary sales queue. Look at the Service Level Goal. Ensure it’s set to match your business expectation (e.g., 80% in 20 seconds). More importantly, review the Architect Flow steps. The Queue action has a Timeout setting. If this is set to 30 seconds, the interaction leaves the first queue and enters the second. The SLA calculation can get tricky here because the interaction technically “left” the first queue.

Try adding a Set Variable action before the first queue to log {{interaction.queueEntryTime}}. Then, compare this against the {{interaction.agentAnswerTime}} in the Interaction Log. This will show you the true elapsed time.

Also, check if your backup group has a different SLA goal. If the primary queue hits 98% but the backup group is slower, the aggregated view might skew. Focus on the Interaction Log for precise timestamps rather than just the dashboard aggregates.

Check your queue configuration settings in the WFM module, as this discrepancy often stems from how adherence metrics are calculated versus real-time flow logic. The suggestion above about the SLA clock starting at queue entry is spot on, but there is a configuration nuance that usually fixes the perception gap for scheduling teams.

1. Navigate to Admin > Routing > Queues and verify the “Service Level” definition. Ensure it matches the 30-second threshold used in your Architect flow’s secondary routing logic.
2. Review the WFM Schedule for that specific skill group. High adherence rates can mask capacity issues if agents are technically logged in but handling long average handle times.
3. Add a Queue Time Report to your Performance Dashboard. This visualizes the exact wait duration before the 30-second timeout triggers, helping align the dashboard data with agent experience.

This usually clears up the confusion between reported SLA and actual wait times.