Deploying Lousy IVRs

Here are 10 causes that contribute to the deployment of lousy IVRs.

1. Designing from the armchair, without discovery, without getting the key people involved in developing the requirements.

2. Treating the IVR deployment like an IT project and handing ownership of it to the Technology group.

3. Grossly under-financing the project (while spending an order of magnitude more on the web site).

4. Not hiring VUI experts; not hiring experienced project managers who have deployed IVR solutions. (A corollary is using internal employees to record prompts.)

5. Micromanaging the VUI designer and second-guessing them.

6. Letting legal have their way instead of battling them at every turn.

7. Not involving agents in the discovery phase, the design phase, or in the acceptance testing phase.

8. Not training agents on the IVR once deployed.

9. Altogether skipping the acceptance testing phase.

10. Not monitoring after deployment and not refining and adapting the solution to new findings.

The High Wire Act of Demoing Speech

If you have ever given demos of speech-enabled IVR applications, you know how stressful the experience can be. You have put on your best Sunday suite, have behaved yourself impeccably, have given a great PowerPoint presentation, have definitely impressed your prospect with your client list and the reference quotes, and have demonstrated full and sensitive understanding of your prospect's problems. But all that, you fear as you get ready to give the demo, could be wiped out -- or so it feels when it happens -- with a cruel, "I'm sorry, I didn't understand that!"

Here's a list of tips to maximize chances of success and minimize the agony when failure takes place. Needless to say, your demo is as good as its VUI – and a solid design is your starting point. But here are some pointers to make sure you don’t tragically crash and burn for a silly reason.

1. Remove all prompts that explicitly talk about failure, such as: "I'm sorry, I didn't understand that" or, "Sorry, I didn't hear you." Use a double beep, instead, which will cue you to speak again (and could be interpreted by your audience as a failure on your end rather than the technology's), or just re-prompt.

2. Know the DTMF fall-back to responses if voice recognition gives you a problem. If traversing the call flow is what the demo is about, keep the flow moving with DTMF.

3. Don’t speak over prompts. Instead, wait for a pause and speak your answer. (Obviously, make sure that when you design your demo’s Voice User Interface, you insert silences long enough to let you speak your answer.)

4. Make sure you don't have the application talk for more than 10 seconds without giving the turn back to you.

5. Test the application with the same equipment that you will use in the demo. I've found that best performing for demos is desktop speaker phone and worst cell phone speaker phone. Whatever you choose, just make sure that what worked when testing is what you use when demo-ing.

6. Test the application in the same room and environment where you will do the demo. Ambient acoustics can make a big difference, even if your ears can’t tell.

7. If you are conferencing in the IVR, make sure you know how to end the voice application – i.e., what to say or press to have it end without you needing to hang up.

8. Make sure you know how to pull back the application from voice mail: what to press to return to the main flow after leaving a voice mail.

9. Make sure to tell everyone in the room and the conference line to remain quiet while you demo.

10. Turn off or keep away all cell phones from the demo phone as static will interfere with speech recognition.

11. If doing a conference call, make sure you know how to conference the application in.

12. Know how to mute and un-mute your conference line.

13. Never improvise or show off while demo-ing. Pick a path in the flow, make sure that it works, test it several times, and then during the demo traverse it exactly as you had tested it.

14. If for whatever reason the application fails, be honest about why it failed. If you were forced to use speaker cell phone and speech was degraded as a result, tell them that the voice recognition does not perform well with in such an environment. If a script that talked to a backend failed, take the time to explain that to them. If you don’t know what happened, tell them that you don’t know. Chances are that your audience will sympathize with your plight.

15. If the application fails, have a plan B. A canned recording of the interaction would do. If possible, schedule a follow-up demo with someone in the group, and move on.

Remember, the purpose of the demo is to create a favorable impression. What your prospects cares most about is to see technology work as promised. If you accomplish that, you win.

Putting up with Bad Interfaces

A thought I want to jot down and elaborate on in future posts.

Why do people have such low tolerance for bad usability in the IVR but are (or have been) able to endure without a peep of complaint the DOS and UNIX prompt? I don't ever remember anyone saying, "stupid computer! Why can't you understand me when I type 'check disk' instead of stubbornly insisting on 'chkdsk'. " Instead, people usually curse their own "stupidity" and "carelessness," and exclaim how they are just bad with computers and how their 10 year old child was far better than them, and all that.

So, why is that?

One reason, I guess, is the perception that humans have that whatever a human can do, the brainy machine should be able to do faster and better. A human can understand speech and engage in conversations with almost no effort (or so we think), and if a computer can't do it, then clearly there is something wrong with that computer (or, in this case, the IVR technology).

The perception is exacerbated by the illusion well designed VUIs give of sounding and behaving like a human. Which results in a raising of intelligence expectations and a lowering of tolerance for mistakes.

Sometimes I wonder if a VUI that was designed like a DOS command would result in people complaining less than otherwise! Would a VUI that sounded like a robot (but was perfectly intelligible), that tolerated no variations, that sounded like the almighty Computer itself speaking, without a hint of negotiating, who was in complete and unshakable control, that didn't fret or apologize when it made a mistake, that accused the user of making errors when things failed, that responded with things like, "Your response is not recognized as an internal or external command" -- would such a VUI have the effect of having people blame themselves when things didn't work? An experiment worth conducting....

Closing the Dialog -- Part III

7. Never say, “Your call is important to us”

Another non-negotiable rule. The expression is overused and will only elicit snickers of derision from the user.

8. Don’t make the user repeat information they provided to the IVR

One of the biggest complaints that users have about IVR systems is the notorious practice of forcing users to repeat to agents information that they had just provided to the IVR. There are three ways to address this failure in usability: (1) Pass to the agent whatever information that was collected – whether by a screen pop or an audio whisper to the agent prior to connecting; (2) if the system can’t pass information to the agent, then don’t ask in the IVR for information that you know the agent will need; or (3) at the very least, have the agent apologize for making the caller repeat themselves, and have the agent ask only for the very minimum to accomplish the task.

In the case where no information is being passed from the IVR to the agent, at the very least, make sure that the agent is alerted that the call they are receiving is a call transferred from the IVR. The agent can then adjust their behavior accordingly (e.g., sympathize with the user if they know that usually users transferred from the IVR are frustrated or angry).

9. Avoid transferring users from one IVR system to another IVR system

Unless the VUIs of the two IVR systems are designed as units of a common whole (with identical personas, with information collected from the first system passed to the second, etc.), don’t transfer users from one system to the other.

10. Don’t play phone rings unless you are transferring directly to a human

The sound of phone rings after an interaction with an IVR is a signal to the user that they are about to speak to a human being. Never play phone rings and then present the user with yet another IVR system.

The Strategic First Step....

Eduardo Olvera, author of the VUIDesign Blog, sent me a very thoughtful response to my note about taking the first steps towards building a real IVR reform movement. Here is an excerpt from his note:

As you well pointed out, there was great resistance at the beginning, and I agree with some of the things that happened after that original resistance. But I think one of the biggest factors some people miss of that story - which is also directly related to your other points about advocates - is the huge role kids played on it.

That's right. If you remember, once the government enforced rules to require kids to use seat belts while riding on a car, the side-effect they didn't envision was what started to happen when kids started asking their parents why it was that they had to wear seat belts when their parents weren't, and guess what, I can't think of a better way to convert users than to have you realize as a parent that you teach by example, and therefore the parents started to use it too!

Going back to Gethuman, I think it would be great if we could find a similar legislation/kid combo which may on one hand start enforcing and monitoring change (e.g. CTI, hold-times, etc.), while on the other hand promote change from the inside... someone with enough power to make us question our current ways of doing things, and why not, ask us directly "and why aren't you wearing one?"

This is the kind of thinking we should be doing if we want to make headway in forcing companies to invest in quality!

I agree. The promotion of the rights and safety of the vulnerable in general and kids in particular has been key to the civilizational drive: labor laws also had their genesis in the protection of children, from which things like rights we take for granted today followed (sick days, 8-hour day, 5-day week); many food safety and air quality initiatives owe their existence for the concern of children also.

For us, then, we need to think carefully about what would be the vulnerable constituency that can enable us to make the qualitative leap in terms of forcing companies to invest in user-centric developments of phone automation systems. I want to think about this some more, but this is a great first step in the right direction.

New Blog by Speech Technology Magazine

A quick note: Speech Technology Magazine have launched their own blog. Looks like they plan to post at least once a day -- which is great. Let's hope they keep the energy level up.