How do I correctly to configure timeout handling within a complex IVR flow to ensure accurate metric reporting in the Performance Dashboard?
Our organization operates within the EU-West BYOC environment. We have recently restructured our primary inbound voice flow to include a series of conditional data lookups via Custom Data actions. The intent is to personalize the IVR menu based on customer tenure and recent interaction history. However, when the downstream data service exceeds the default timeout threshold, the Architect flow behaves unpredictably regarding queue placement and metric attribution.
The specific issue manifests as follows:
- The Custom Data action is configured with a 5-second timeout.
- Upon timeout, the flow is directed to a ‘Fallback Queue’ using a Queue Prompt element.
- The Performance Dashboard reports these interactions as ‘Abandoned’ rather than ‘Queued’ or ‘Answered’.
- The Conversation Detail view shows the session status as ‘Ended’ with a reason code of ‘Timeout’, yet the agent queue logs show no entry for these specific calls.
This discrepancy creates a significant gap in our service level calculations. From a business perspective, we need to know if these calls should be counted against our abandonment rate or if they should be treated as failed routing attempts that require no agent resource. The current behavior suggests the call leg is being terminated by the platform before the queue prompt can even initiate, which contradicts the visual logic in the Architect canvas.
We have verified that the data service is indeed responding slowly during peak hours, confirming the timeout trigger. The question is not about fixing the data service latency, but rather about the correct architectural pattern to handle this failure state within Genesys Cloud. Should we be using a different element to catch the timeout, or is there a specific configuration in the Queue Prompt or Flow Settings that dictates how ‘Timeout’ events are mapped to the Performance metrics?
Any guidance on aligning the flow logic with the dashboard reporting requirements would be appreciated. We require a solution that ensures these interactions are visible in the queue activity views for workforce management analysis.