What causes a retry?
Troubleshooting Scenario
When an attempted callback fails to connect to a customer or agent, a retry will be attempted after a configurable Retry Delay. Retries are triggered for specific reasons, and the reason for each retry can be identified on the Call Detail screen. Specific events on the Call Detail screen can indicate whether a callback was successful or a reattempt was scheduled.
This guide presents an overview of the Call Detail events that can indicate the need for a retry and walks through the process of identifying the relevant events.
The number of allowable retries and the delay between attempts can both be configured at Call Target > Callback Strategy.
How Do I Know When a Retry is Needed?
Call Detail events can reveal when Mindful Callback attempted to call a customer or your call center. After identifying the Calling<Party> events in the Connecting phase, you can then determine whether a callback was successful or a retry was needed.
The following examples highlight the important events during a successful callback for which no retry was needed. If one or more of these events are missing, a retry may have been needed.
1. Connecting to the customer: The PromptCustomer event indicates that the customer is on the line. The CustomerWaiting event shows that the customer has accepted the callback and is waiting to be connected with an agent.
2. Connecting to the agent: The CallingCompany event shows the system attempting to reach the Call Center Phone Number. The ConnectingAgent event indicates that the agent has accepted the call.
3. Connecting both parties together: The PartiesTalking event indicates a successful callback in which both parties are connected.
How Do I Identify a Retry?
When a callback attempt fails, and there are still retries available, the Connecting:Reattempt event will be logged. Connecting:Reattempt should be the final event logged for that attempt.
By default, exported Call Detail reports only include the final attempt for each callback. You must select the Include all attempts checkbox before exporting the report in order to see a Connecting:Reattempt event in the CSV file.
What Can Cause a Retry?
Consult the following table to see which Call Detail events can indicate that a retry was needed. Retries can be expected to follow each of the following events, as long as the number of retries allowed has not yet been reached. Common reasons are listed, but this is not a complete list of all possible reasons.
| Reason | Example | Related setting |
|---|---|---|
| The customer rescheduled the callback. | | Prompt Customer to Reschedule Callback |
| The customer did not answer the callback. | Note: If a customer's voicemail answers the call, you will see the Connecting:PromptCustomer:SystemHangup event instead. | Customer Dial Timeout |
| No response or invalid responses were provided during callback prompts. | | Customer Prompt Loops |
| The customer canceled the callback | | N/A |
| The call was not answered by the Call Center | | Custom Callback Failover |
| An Administrator manually launched a retry attempt | Call Detail events will look like a normal callback attempt, but you will see retry reason: admin forced included with the call data. | N/A |
