I’m currently working on an ETL project to migrate five years of historical IVR data from an Avaya Aura system to Genesys Cloud. In the Avaya world, every node had a specific ‘Exit Reason’ (e.g., ‘Timeout’, ‘Invalid Input’, ‘Hangup during menu’).
In Architect, when we look at the Analytics ‘Flow’ segments, it seems the exitReason is only populated for the very last step of the flow. If a customer hangs up while in a sub-menu, the analytics just show a generic ‘Disconnect’ and we lose the context of where they were.
How can I replicate the granular ‘Exit Path’ reporting from Avaya in Architect so our historical trend reports don’t have a massive gap in data quality?
The way Genesys Cloud handles ‘Flow’ segments is fundamentally different from Avaya’s node-based reporting. To get that level of granularity, you need to use ‘Flow Outcomes’.
Create an Outcome for every major path in your flow. Just before any menu or input block, initialize the outcome as ‘Started’. If the customer successfully navigates, set it to ‘Success’. If they hang up, the outcome will stay as ‘Started’ or ‘Failed’, and you can see exactly which outcome was active at the time of the disconnect. This gives you the ‘Context’ you’re missing from the raw flow segments.
I’m working on our Teams integration and we had a similar issue with reporting ‘Ghost Calls’.
Another approach is to use the ‘Set Participant Data’ block at every major milestone in your flow. We use a variable called IVR_Last_Breadcrumb. By updating this variable at every menu, you can see exactly where the customer was in the Analytics detail record, even if the flow segment itself is truncated. It’s very helpful for our ‘Customer Journey’ dashboards!
As a telecom engineer, I’ll add that you should also check the disconnectType in the SIP signaling. If you see peer, it was a customer hangup. If you see endpoint, it might have been an error in the Architect flow itself.
If you’re doing an ETL for historical data, you’ll likely need to ‘Synthesize’ these exit reasons by looking at the last successful flow segment and the IVR_Last_Breadcrumb data together. It’s a bit of work in the transformation layer, but it’s the only way to get true parity with Avaya’s reporting model.