When callers know what to say, applications using open-ended prompts can be very efficient and conversational. It is often the case, however, that new or infrequent users of applications using this prompting style have trouble figuring out what to say in response (McInnes et al., 1999; Walker et al., 1998).

For this reason, it is a leading practice to support open-ended prompts with example prompts (Balentine & Morgan, 2001; Enterprise Integration Group, 2000; Knott, Bushey, & Martin, 2004; Sheeder & Balogh, 2003; Suhm et al., 2002; Williams & Witt, 2004).

Coming up with a specific plan for example prompting requires a number of design decisions:

• How many examples to provide
• Exactly what example(s) to use
• Where to place the example(s) – before, directly after, or following a pause after the open-ended prompt
• If after a pause, how long to wait before playing the example(s)

Lewis (2011) provides a summary of the published research on example prompting and five key recommendations based on that research (see pp. 223-229).

Support open-ended prompting with one or two naturally-phrased example prompts
To avoid the appearance of a menu, some designers have recommended playing just one example (Barkin, 2009; Joe, 2007). Two sometimes works. Three pushes you over the brink into “sounds like a menu.” A key consideration is to be sure that each additional example has value to callers. If using multiple examples, write them in a way that does not imply that the examples are an exhaustive list of options (e.g., “For example, you might say something like, 'I can't start my car', or 'I need to make a payment'”).

Place examples after the open-ended prompt, with no pause in between
Ask the open ended question, then give the examples. A pause in between, rather than giving confident or experienced users time to speak without having to listen to the examples, tends to send the caller and IVR into turn taking issues.

Don't give any examples if the caller returns to the open ended prompt
If they make it through the SLM successfully, finish a task, and come back to the SLM to attempt a second task. Don't give them the examples on the initial prompt. Save examples and any other instructions for the reprompts.

Choose example prompts that map onto functions callers are likely to request, and use wording known to have high recognition accuracy
There's no point in offering examples that have low relevance to callers or that are hard for the system to recognize. Some designers have found that medium-frequency examples work better than high-frequency, since the latter may make callers feel they should parrot that back more than the former does.

Consider specifically asking the caller to be concise (“briefly”, “in a few words”) if a more typical but less imperative version (e.g., “How may I help you”) isn't working well
Some researchers have claimed that this approach leads callers to provide inputs that are more likely for the recognizer to understand (Boyce, 2008; Suhm et al., 2002), but the published evidence is weak and this type of prompting is more verbose and less service-oriented than a standard open-ended prompt.

Monitor your open-ended prompt and change as necessary
Whatever you choose, you must monitor what people are saying and see if the prompt is working as designed. Are many callers saying exactly what's in the examples? If so, is that really what they should be saying? You may need to change the number of examples or the specific examples you've given.

Balentine, B., & Morgan, D. P. (2001). How to build a speech recognition application: A style guide for telephony dialogues, 2nd edition. San Ramon, CA: EIG Press.

Barkin, E. (2009). But is it natural? Speech Technology, 14(2), 21–24.

Boyce, S. J. (2008). User interface design for natural language systems: From research to reality. In D. Gardner-Bonneau & H. E. Blanchard (Eds.), Human factors and voice interactive systems (2nd ed.) (pp. 43–80). New York, NY: Springer.

Enterprise Integration Group. (2000). Speech Recognition 1999 R&D Program: User interface design recommendations final report. San Ramon, CA: Author.

Joe, R. (2007). The elements of style. Speech Technology, 12(8), 20–24.

Knott, B. A., Bushey, R. R., & Martin, J. M. (2004). Natural language prompts for an automated call router: Examples increase the clarity of user responses. In Proceedings of the Human Factors and Ergonomics Society 48th annual meeting (pp. 736–739). Santa Monica, CA: Human Factors and Ergonomics Society.

Lewis, J. R. (2011). Practical speech user interface design. Boca Raton, FL: CRC Press, Taylor & Francis Group.

McInnes, F. R., Nairn, I. A., Attwater, D. J., Edgington, M. D., & Jack, M. A. (1999). A comparison of confirmation strategies for fluent telephone dialogues. Edinburgh, UK: Centre for Communication Interface Research.

Sheeder, T., & Balogh, J. (2003). Say it like you mean it: Priming for structure in caller responses to a spoken dialog system. International Journal of Speech Technology, 6, 103–111.

Suhm, B., Bers, J., McCarthy, D., Freeman, B., Getty, D., Godfrey, K., & Peterson, P. (2002). A comparative study of speech in the call center: Natural language call routing vs. touch-tone menus. In Proceedings of CHI 2002 (pp. 283–290). Minneapolis, MN: ACM.

Walker, M. A., Fromer, J., Di Fabbrizio, G., Mestel, C., & Hindle, D. (1998). What can I say?: Evaluating a spoken language interface to email. In Proceedings of CHI 1998 (pp. 582–589). Los Angeles, CA: ACM.

Williams, J. D., & Witt, S. M. (2004). A comparison of dialog strategies for call routing. International Journal of Speech Technology, 7, 9–24.