Improved Callback Reporting and Functionality for Early Caller Disconnects
In the current RingCX callback flow, if a caller disconnects before the system successfully queues the callback, the interaction is categorized as “Inbound ACD Callback Incomplete” in Analytics reporting. This occurs even in cases where the caller has already expressed intent to receive a callback.
Problem:
This classification does not accurately reflect customer intent or agent workload. From a business perspective, these interactions often represent valid callback requests that were interrupted due to timing or user behavior, rather than true failures. As a result:
1) Callback demand may be underreported
2) Metrics may not align with actual customer experience
3) Reporting lacks visibility intended/successful callbacks
Requested Enhancement:
Introduce improved reporting granularity for callback flows where the caller disconnects before queue confirmation. Specifically:
1) Add a new disposition or category (e.g., “Callback Requested – Caller Disconnected Before Queue”)
2) Alternatively, provide a configurable reporting option to classify these interactions separately from true incomplete callbacks
3) Ensure these events are trackable in Analytics dashboards and exports
[Deleted User]
shared this idea
-
Bridget
commented
We don’t just want the reporting to more accurately reflect what happened, we want the system to call the member back even if they don’t press 1 a second time to confirm and hang up prematurely. We want your system to call the member back if they press 1 the first time, regardless of if they press it the second time and wait for the call to disconnect. We want your system to queue the callback as soon as the member presses 1 stating they want the callback and for them to not have to press 1 a second time and wait for the call to disconnect, it is not an intuitive or member friendly experience the way it currently works.
-
Bridget
commented
I would like to add this as well: don't require the member to confirm a second time, if they hang up after they press 1 to receive a callback, we want the system to assume they want the callback even if they've hung up before doing the second confirmation.