If you have ever given demos of speech-enabled interactive voice response (IVR) applications, you know how stressful the experience can be. You have put on your best Sunday suit, 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!

Needless to say, your demo is only as good as its voice user interface (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 VUI, you insert silences long enough to let you speak your answers.)
   
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 the best-performing for demos is a desktop speaker phone and the worst is a cell phone speaker phone. Whatever you choose, just make sure that what worked when testing is what you use when during the demo.
   
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, i.e., what to press to return to the main flow after leaving a voice mail.
   
9. Make sure to tell everyone in the room and on the conference line to remain quiet while you demo.
10. Turn off or keep away all cell phones from the demo phone because they might create static that 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 doing the demo. Pick a path in the flow, make sure that it works, test it several times, and then  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 a cell phone speaker and speech was degraded as a result, tell them that the voice recognition does not perform well within such an environment. If a script that talked to a back end 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 care most about is to see technology work as promised. If you accomplish that, you win.

Ahmed Bouzid, Ph.D., is senior product manager at Angel.com, where he also heads the Partnerships Program. He has more than 15 years of experience in the speech and natural language processing industry. He can be reached at bouzid@angel.com.

Please note that the "Sounding Board" articles appearing on speechtechmag.com represent the viewpoints of their respective authors and not necessarily those of Speech Technology magazine or its editors. If you would like to submit a "Sounding Board" for consideration, please email lklie@infotoday.com.