Sometimes, I’m just thinking out loud here, in a world of smartphones and devices and the Internet of Things, we begin to look at IVR as another telegraph or typewriter—something so yesterday, so antiquated, so powerless—at least in comparison.

 
But it’s just not true: certainly not today, and it will be even less so in a few years down the road. It’s not your father’s IVR. In fact, an IVR can—and routinely does for business around the world—almost anything you can do on a browser or device . . . and just as well, if not better. The reason is simple: they all use the same data, in the same way, from the same source. The only difference is the presentation medium.

Download the white paper “How To Make Customers Fall In Love With Your IVR”
I’ll think of a few out loud here.
Personalization
Browser personalization is done with cookies. Smartphone apps are personalized by definition: they exist on your personal phone. And IVR personalization is done with ANI—recognizing the caller ID. In all three cases, once recognized, the identification can be used to present very personalized initial greetings. It’s no more difficult to have your IVR begin the call with “Hello Mr. Williams, welcome back” than it would be for your browser to display the same thing.

 
Separating Authentication from Identification
Here we take a lesson from devices. An app instantly identifies you because it’s running on your phone. It’s yours. You don’t log on to a server: you execute your application. That provides a partial authentication. With that you can see very basic information, such as account balance or available bonus rewards. The IVR can do pretty much the same thing. With a simple authentication (the last four digits of your rewards card or your ATM pin for instance) you can present the same basic information. Just as on your device, to transact with the IVR (redeem rewards or make a payment), you would fully authenticate.

 
Targeted Menus
Here’s one example where the IVR is better than a browser. Online it’s difficult and expensive to create a web site that presents itself differently to each user. It’s doable, but the extra development cost, substantial QA, and the delay (especially for heavily trafficked sites) makes it impractical. Here’s an example. I don’t have any investments with my bank. Yet, there on the menu is an option for investments. The IVR doesn’t have any of those hurdles to overcome. It’s simple to set up the system so that if there aren’t any investments to deal with, there’s no menu item presented in the tree.

 
Targeted Messages
Browsers and devices have their own version of “on hold”: the wait while data is retrieved or a page loads. Online or mobile you have to wait and watch the spinner until lag and latency resolve and the page loads. IVRs make you wait too—sometimes for too long. (I’m not mentioning callback capabilities here but they’re very valuable features.) The IVR version of the spinner is, well, music of a certain style. But here, we can do a lot better. Instead of playing music, or generic sales pitches, you can use the data about the user’s account to summarize their account status (recent payment, payment due, available rewards), make targeted product pitches based on their credit, purchase history and more, and so on.

 
After all, wouldn’t you rather listen to information about your own account than “Shadow of Your Smile” played on the pan pipe?