We get this question a lot. People wondering if they should replace their IVR because it is old. I generally ask a series of questions to find out how old it is and why they need a new IVR. So let’s run through the discovery and talk about what the answers mean.
How old is your IVR?
This in and of itself isn’t a great question, but it helps put the conversation into perspective. A better question: “Is there a compelling business driver for replacing your IVR?” Many times we see that the Operating System (OS) needs to be upgraded as it is End of Life (EoL) meaning the vendor for the OS isn’t supporting that version with Security patches aor other updates. In a few instances, the original vendor for the IVR software has been acquired and that version of software is EoL. And in some other instances, the IVR software just hasn’t been upgraded during the operational cycle for a myriad of reasons: OS won’t support the new version, the maintenance was dropped, the new version requires a significant infrastructure upgrade, new version of the IVR won’t support the current ACD platform, new version of the IVR is SIP only and we aren’t SIP enabled yet, and so on. All valid reasons.
Is there a feature you want?
The next question we ask: “Is there a business requirement that your current IVR cannot support?” This is really trying to understand if the current IVR cannot do something they want it to do. For example, “The business wants caller data to screen pop on each leg of a call.” This equates to a feature of, Pass data from the IVR in the SIP header for screen-pop and have the desktop update it at every stop as the call is transferred. “We implemented a new backend” can equate to, the IVR needs to handle REST web service calls. “We want Natural Language” can really mean, The IVR must integrate with the latest version of Lumenvox Speech Recognition. In many instances the answer is “Yes, the IVR can do that, we just didn’t buy that function.” Or “We never implemented that feature.”
Do you know what is happening in your IVR?
One of the frequently problematic questions we ask during discovery is: “Do you know what is happening in your IVR?” The reason this is problematic is that it gets into reporting of the calls. A lot of companies rely on statistics out of the ACD. In many cases the numbers for the ACD, don’t accurately reflect what is happening in the IVR. It just represents how many calls were routed to the IVR. Just because 300 calls were routed form the ACD (or SBC) to the IVR, doesn’t mean 300 people used the IVR. What happened to those callers once they entered the IVR? It isn’t enough to know what is happening generally in the IVR (300 calls entered, 100 transferred to an agent.) In your main menu, if 300 calls enter, what do they do? In this example, what do the other 200 people do? How many hang up? How many just Zero out to an agent? A lot of companies think “Well, if we get a new IVR, we will get enhanced reporting and it will solve our problems.” The erroneous client assumption is equating a new IVR platform with getting a new custom application design. The reality is that if the custom application design does not have reporting baked into it, it becomes the desert request at the end of the meal when they’ve dropped off the check. “Oh! You wanted reporting with that?”
What to do next?
How do we make the determination for which option a client should take? If the IVR can in fact handle the business requirements or at least be upgraded to handle the business requirements and there isn’t a serious business driver like End of Life OS or software, then we suggest that we look at the application to tune it. If there is inadequate reporting for the IVR, then let’s add in reporting. If it isn’t supporting the Natural Language, let’s change the application to use it. or Let’s execute a well-planned tune of your existing call flows and speech environment. Every choice that doesn’t involve wholesale replacement of the technology will be dramatically less expensive than doing a thorough redesign of your applications.