Context:
The current environment is a Genesys Cloud instance (v24.8) operating within the EU-West region, specifically aligned with CEST timezone requirements. The primary function of this deployment is high-volume inbound transaction processing via a complex IVR structure. Recent audits of the Performance dashboard reveal a discrepancy in the ‘Abandoned Calls’ metric versus the actual flow termination logs. Specifically, calls originating from a specific carrier are dropping immediately upon entering the main menu node, yet the dashboard registers them as successful interactions with zero handle time, rather than abandonments or errors.
The Architect flow in question utilizes a standard Greeting node followed immediately by a Queue node with a configured ‘Max Wait Time’ of 120 seconds. The ‘Play Music While Waiting’ setting is enabled, pointing to a standard hold music file. However, the critical configuration involves the ‘Flow Termination’ behavior when the queue is full or unavailable. The setting is currently configured to ‘End Call’ without a specific outbound message. This appears to conflict with the carrier’s SIP INVITE handling, resulting in a 487 Request Terminated response that Genesys Cloud does not log as a failure in the standard Conversation Detail view.
Question:
Why does this setting cause silent flow terminations in Architect that bypass the Performance dashboard abandonment metrics? Is there a specific configuration within the Queue node’s ‘On Queue Full’ or ‘On No Available Agent’ branches that must be explicitly defined to ensure proper metric aggregation? The business requirement is strict: any call not connected to an agent must be accurately reflected in the ‘Abandoned’ or ‘Failed’ categories for SLA compliance reporting. Currently, these calls are vanishing from the view, skewing the Service Level Percentage calculation.
Additionally, does the ‘Play Music While Waiting’ feature interfere with the timeout logic when the queue depth exceeds the threshold? The logs indicate the call enters the queue, waits for 200ms, and then terminates. This latency suggests a provisioning issue rather than a logic error. What is the recommended pattern for handling carrier-side disconnects in Architect to prevent metric leakage? The goal is to ensure data integrity in the Performance dashboard without requiring custom API integrations to patch the reporting gaps.