Why Do IVR Applications Need Analytics?

I am always amazed at how many organizations deploy new IVR applications without any thought on collecting metrics to verify the success of the implementation. The philosophy seems to be that once the voice application is designed, tested and deployed the project is completed. And as long as the application is “taking calls” no further attention is required. Probably the only indication that the voice application is frustrating and not easy to use by the customers is repeated complaints to the call center when they finally get transferred by the IVR. That is if they get transferred before hanging up in frustration or are not held in IVR jail with no way out. Frustrated customers and excessive transferred calls to the call center cost organizations money. Potentially more than the IVR systems and applications cost.

Even when organizations collect some metrics on the IVR applications it usually is not enough to determine where the issues are. The following chart shows how many organizations view IVR metrics. Either the caller was contained within the IVR or they were not.

The term containment usually means that the user went into the IVR application and never went to the call center. But why did the customer not go to the call center? Was it because they hung up in frustration? Did the IVR not allow the customer to transfer to the call center? Below is a more useful view on what is going on in the IVR.




Now we can tell how many hung up while in the IVR (Abandoned). And if they transferred to the call center was it because of excessive error and timeouts, or did they just voluntarily select to speak to an agent because they could not figure out how to get the information they needed. Transfers because of errors and selecting to speak to an agent are good indicators of areas that may need improvement in the IVR application. It could be as simple as changing a recorded prompt to provide more guidance to the user.

Required transfers are when the IVR provides a menu option to the user to get to an agent because the IVR does not currently support the task they want to perform. An example of this could be that your IVR application only supports touch-tone or DTMF input and the user wants to provide a change of address. The task of providing information on an address change is not possible with touch-tone input, but it is feasible with speech recognition. If you are collecting metrics on this and you know how many customers want to perform this task, now you can easily do a return-on-investment analysis to see if and when the investment into adding this self service feature to your IVR will pay off. Without these metrics it is a shot in the dark.

These basic metrics just provide a dashboard that provides indicators on the general health of your IVR applications. Good analytics will allow you to drill down to find the real problem areas. Watch this blog as we dive into more metrics that are useful intelligence into how well your IVR is performing and saving you money.