The IVR Diaries
Is there a doctor in the house?
As a follow-up to the initial Interactive Voice Response (IVR) article, there is a growing interest in techniques to evaluate and fix existing systems.
The best starting point is to apply the WHY technique. Simply start by challenging the status quo with a few simple questions:
- Why do you still need an IVR?
- Does your customer still appreciate the IVR?
- Is Voice still relevant?
- Is the cost per interaction a good ROI?
When delving into the issues that plague large IVR systems it is best to have a systematic approach.
Chapter 1 — The statistics
Every IVR platform come with an array of reporting. Getting tons of pages of all kinds of data may feel productive, but you have to be able to drill down to the core data that drives your business. In fact, I normally start with the ‘napkin’ approach. Draw what you want to see on a piece of paper and then work backwards mapping the data sources required.
Most IVRs serve multiple languages and multiple services across complex workflows. The reporting structure should be able to allow a view of all these in a logical representation that suits your business.
I personally love Sankey diagrams to graph & visualize IVR/Call Traffic. If you are not used to it, it is worthwhile to consult your MIS specialist and let them put a few use cases into Sankey format to explore.
Once you have your data in such a rich visual format you can start picking up on trends and mapping them against your business priorities. It is important to set realistic expectations. Business drivers are sometimes set at a target like 80/20, but does it make sense for your business? Does 0% abandoned rate (ABD) really make sense or even technically possible? I have frequent examples of me starting a call when my doorbell ring and I simply hang up since I would like to call again when convenient.
Chapter 2 — Automation
Why are we automating? Is it because we are simplifying the journey for our customers or in most cases to save a lot of money?
The driving force towards automation sometimes gets slightly skewed along the way. Put clear objectives towards what you want to automate. Listen to customer feedback and be practical about the complexity and rate of change. IVRs can be an amazing source of cost savings and over the last decades we’ve exhausted every trick in the book, but that did not always resonate with the end customer.
The reality is that the contact center will always be a seesaw of events. If we overspend the CFO is unhappy; if we make it too complex the customers hate it. How do we reach the Goldilocks situation?
The key is in the customer journey. You have to ensure that each and every automation is fit for purpose. When a customer enters your IVR, do you really need to authenticate him with a complex array of numbers? Definitely stay away from alphanumeric input. Do role-playing using the different demographics and customer tiers. In many organizations, they tend to steer away from offering the high tier levels with too much automation.
Chapter 3 — Visualization
I love to visualize things and creating an IVR tree in an electronic form is still a battle. Maybe the Metaverse will create a platform rich with features to ‘see’ an IVR in 3D. (This may be tricky for Dynamic IVRs)
Definitely map out the IVR in a NON-TECHNICAL workflow. Too often I am presented with overcomplex wall-sized printouts which are impossible to digest. There are many tools to do this (another article to follow) but you can do it in Visio, PowerPoint or really any tool that allows for quick and easy workflows. Build an index of your recordings and map them to each node.
The most important part would be to have an internal process of change control. The last thing you want is to end up with an outdated IVR flow or make changes to the wrong version. Some vendors provide an IVR flow, but I still prefer to do it externally as it allows for brainstorming sessions and alternative visualizations.
As IVRs become more complex, they also become more difficult to change. Using the visual approach will immediately signal alerts of complexity. For each and every node you should challenge your teams with the ancient and proven WHY approach. Asking WHY you need it? WHY the customer will use it? WHY it cannot be automated? WHY other digital channels might not be better suited? WHY do I have to offer the customer the option to press # to end the call when they probably would just hang up anyway?
Example: Let’s say I am calling to check on my flight departure time. Pretty much all of the business logic exists for me to reach the contact center, enter my PIN and then read out simple (short) information about my upcoming flight. One can easily orchestrate alternative channels during this time to offload the interaction to WhatsApp or SMS (still a strong channel in many countries for short messages or sensitive information).
Chapter 4 — Take Action
Now that we have all the pieces of the puzzle one has to put it into motion. Here are some of the industry pitfalls to watch out for:
a) Deer in the Headlights — sometimes the sheer magnitude of change can cause paralysis. Ensure that you review all aspects of the execution and impact on all the building blocks. Cloud-based systems are much better suited at managing to scale up (or down) than on-premise (local server) solutions.
b) Customer Input — many frown upon this, but in any large customer base, there are the magnificent few that are willing to help you with your product. The ever-complaining customer might just be the same person that would love to provide input on your service for ‘pre-release’. Providing them with the opportunity to influence their own service can turn a detractor into a promotor with little or no investment. PLUS you might end up with the feedback that your own team could have missed.
c) Test, Test & Test — I cannot stress this enough. In too many projects I have seen testing being diluted to the bare basics due to simple issues, like testers not having a mobile number and not wanting to spend their own credit for testing specific services. Build a solid test plan — Don't leave it up to IT, this has to be driven by Business. Involve the security team early so that they can be part of the design & build. Sometimes the testing phase reveals some IT risks that could have been eliminated with early engagement. Also, test error scenarios to check what happens when things fall off the happy path. The rushing of testing due to the project already being late or my ultimate favourite — skipped altogether.
d) Review reports — Once you launch, be sure to keep an eye on the Reports as discussed earlier. Check which nodes are getting more or less traffic and whether that is in line with your expectation. If there are back-end systems that are not responding, be sure to have error messages in place that makes sense and get reported on. If back-end systems are going offline, would you know about it after 3 unsuccessful attempts or only at the end of the month?
Chapter 5 — To survey or Not to survey, that is the question, my dear Watson
Unless you have a government or compliance driver to survey after each and every service, go back to the WHY question. It is great to have a neat & slim service on the IVR, but not so great to get bombarded with a 3 or 4-level survey, especially if you select the unhappy option which then opens up another few layers of ‘interrogation’.
Surveys (and yes another title in the making) should be well-timed. I frequently shop at a large multinational retailer that uses e-receipts, which I love, but what I do not like so much is that even after a $2 purchase they send me a survey.
Chapter 6 — Count the $$$$$
It is not a very easy task to calculate cost interactions, since there are SO many factors to consider, but at least try to come up with a figure using some basic logic of technology + HR costs — and yes, even IVRs have HR-related costs. Between development, reporting and administration they do have albeit a small HR portion to the cost. Be sure you have an estimate of the effort required to deploy new services. Once the business units demand additional IVR services, you can start putting a business impact analysis together and work on the ROI. If you are not addressing any of the key business factors, again you will have to ask WHY.
Now you can transpose the costs on top of the total transactions and see whether certain use cases make financial sense or whether good old humans are better suited.
In conclusion, if you have been dealing with IVRs for some time, you will know that there is no ‘quick fix’ but rather a systematic approach to mapping your customer needs to that which will suit them best inside the complex world of IVR. Hopefully, this article allows you to keep your finger on the pulse and plan accordingly.
> Please press # to stop reading this article
