Architect Flow Timeout Causing Performance Dashboard Misalignment

The system returns a 408 Request Timeout when the Architect flow exceeds the 30-second threshold for complex IVR navigation. This occurs specifically within the ‘Customer Service’ queue in the EU-West region. The performance dashboard registers the interaction as ‘Abandoned’ rather than ‘Handled,’ despite the agent eventually taking the call after the timeout resolution. This discrepancy skews the Average Handle Time (AHT) metrics and distorts the agent performance reports for the Paris shift. The business impact is significant, as these metrics drive the weekly operational reviews. The flow structure involves multiple nested sub-flows and data fetches, which contribute to the processing delay. The issue appears intermittent, affecting approximately 15% of high-volume inbound calls during peak hours. The expectation is that the dashboard should reflect the actual disposition of the call once it is connected to an agent, regardless of the initial timeout event. The current behavior suggests a gap in how the platform correlates the timeout event with the subsequent successful transfer.

• Verified the flow execution logs via the Conversation Detail View to confirm the agent interaction was successfully logged.
• Reviewed the queue configuration settings to ensure the ‘Wrap-up Time’ and ‘Max Hold Time’ parameters are not inadvertently triggering the abandonment status.

This looks like a dashboard caching issue rather than a recording gap. Check if the interaction_type metadata in the bulk export aligns with the agent wrap-up codes, as the dashboard often lags on status updates for long-running IVR sessions.

Have you tried isolating the timeout using the /api/v2/architect/flows export API? The dashboard often misclassifies interactions that cross state boundaries during latency spikes.

The raw data reveals the actual disposition before the UI applies its heuristic rules. This approach bypasses the caching layer entirely, providing a clear view of whether the flow actually terminated or merely stalled during the IVR handoff.

This has the hallmarks of a classic case of Zendesk’s static ticket states clashing with Genesys Cloud’s real-time interaction lifecycle. The dashboard isn’t broken; it’s just interpreting the 408 as a hard drop before the state change propagates.

Check the flow’s timeout settings in Architect. If the IVR exceeds the threshold, add a ‘Transfer to Queue’ block with a retry policy. This forces the system to re-evaluate the disposition instead of letting the heuristic rules misclassify it as abandoned.