Beyond interactive voice response

I like to say that human beings are the exception handlers for all automated workflows. But, as those of us who endure automated customer service know only too well, human exception handlers are getting harder and harder to find. So a couple of months ago, when my wife forwarded me a link to a list of IVR (interactive voice response) cheats -- that is, ways to short-circuit voice menus and get directly to human agents -- I had a hunch this idea would sprout legs.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

Sure enough, Paul English 's IVR Cheat Sheet hit the big time in November, garnering a flurry of mainstream media coverage. The most delightful of these stories is the radio spot in which English shows NPR’s Steve Inskeep how to breach Apple’s IVR fortress in slightly more than a minute. As I can ruefully attest, that is a huge optimization.

English’s hope, he tells Inskeep in the interview, is that companies will admit how infuriating their systems often are and will take steps to improve them. This week a vendor of hosted IVR solutions, Angel.com, pointed me to its response to English’s resentment-fueled notoriety: a list of 10 dos and don'ts for friendlier IVR. Among other sins, it castigates the practice of automatically collecting customers’ account numbers, and then making those customers repeat the numbers to an agent when they finally connect to one -- my top IVR gripe:

“If you want callers to believe that the IVR can help them resolve a problem,” says Tip No. 4, “respect the time they put into the IVR and don’t ask for the same answers twice.”

Amen, brother.

Angel’s recommendations are all good, and I endorse them, but best practices alone cannot solve two fundamental problems. One is that we’ve hardly begun to figure out graceful ways to integrate people into automated workflows, whether those occur in voice or data networks. The other is that we’ve hardly begun to integrate those two kinds of networks.

These problems are more closely related than you might think. Consider, for example, the dilemma of a phone-based customer service agent who, in the course of helping you, must refer you to a procedure on the company’s Web site. Because URLs are notoriously hard to speak, an awkward and inefficient verbal exchange ensues, or else the agent ends the call with a promise to e-mail you a URL. Then you pick up the message, try the procedure, and are left with no interactive support when you hit a snag or discover that you really need to do something entirely different.

Voice calls must be able to recruit data channels, and vice versa. That way, an agent could attach an IM session to your voice call and push you the URL in real-time chat. It might even be appropriate to extend the data session with screen sharing, so the agent can watch and assist. If things still don’t work out and the whole matter must be referred to someone else, you’d like to be able to initiate voice or data communication -- or both -- in a context-preserving way.

I’ve yet to run into a company that uses Skype or iChat AV in this way, but growing numbers of customers have access to these technologies and would love to see them put to such use. IVR needn’t be as awful as it frequently is, but better IVR will only be a baby step in the right direction.