Deploying Courtesy Callback the Correct Way

//Deploying Courtesy Callback the Correct Way

Deploying Courtesy Callback the Correct Way

No Contact Center customer likes long hold times. In order to shorten the time that the caller stays on hold in the queue, Cisco has developed a new CVP feature called Courtesy Callback (sometimes referred to as Virtual Hold). With Courtesy Callback, the caller can choose to receive a call back from the contact center without losing their place in the queue.

The Courtesy Callback feature in CVP has a number of advantages; however, there are also a few potential drawbacks. These issues can be mitigated with some specific changes to the deployment. If Courtesy Callback is installed correctly, it can provide a better Caller Experience and Workforce Experience while improving Business Intelligence and IT Operations.

Below are some recommendations that will optimize the implementation Courtesy Callback and provide a significant added value to the feature.

Note: These are general recommendations, and may need to be adjusted based on the specific business requirements.

Use a more robust Estimated Wait Time (EWT) algorithm than the default algorithm
The Courtesy Callback application depends on an accurate prediction of when a call can expect to get answered. This will prevent offering callbacks to callers who can reasonably be expected to get to an agent before the service level expires. This will prevent callers from having to wait without being given the opportunity to have a callback. CtiPath has developed an Estimated Wait Time algorithm that provides a more accurate prediction than standard algorithms.

Offer the callback option to a certain percentage (25%-50%) of callers whose Estimated Wait Time is above the Service Level when they are queued
The estimated wait time algorithm will be affected by the number of calls queued, and if a large number of the calls queued opt in for callback in the same widow of time, it will skew the estimate. This results in too many callers being offered callback.

Offer callback to 50%-75% of callers who remain in queue longer than the configured Service Level
Once a caller has been in queue for longer than the configured service level, their place in queue can be reconsidered. This allows callers who may not have received an offer, or who did not opt in to the initial offer, to take advantage of the feature. However, once a caller has declined to opt in for two callback offers, they should not be asked again, as they are more likely to consider it as a nuisance.

Prepare custom reports that clarify the difference between callers who opt into the callback feature and those who wait in the queue
The stock reports do not know the difference between the calls that were offloaded to Courtesy Callback and those that were handled within the queue. A custom report will allow the data to be properly weighted to provide a real Average Speed to Answer (ASA) and Abandon rate for calls that were not handled by Courtesy Callback.

Use an adjustable callback threshold to allow callbacks to be pushed back until a lower call volume is available
Most properly staffed call centers will only be outside of service level on any given skill during certain peak times. Adjusting the threshold of the callback offer will allow the spike in calls to be leveled off dynamically, and the calls can be offloaded to the application until the spike returns to normal.

Capture unanswered callbacks and schedule outbound dialer campaigns to provide better service
Not all callbacks are successful, and a number of factors can impact the result of a callback. To provide the best customer experience, it is wise to capture the callback number and add the unsuccessful entries to an outbound campaign to attempt contact them at a later time.

Conclusion
By considering these recommendations, Courtesy Callback can be successfully implemented in a way to improve Caller Experience, Workforce Experience, Business Intelligence, and IT Operations.

By | 2017-02-27T15:44:41+00:00 November 2nd, 2015|Customer Experience|

About the Author:

Josh is a Applications Solution Architect and a Developer for CtiPath. He has been part of the CtiPath team for over 3 years.