It takes time to confirm user input, so the first rule of confirmation is don't do it unless you must (Damper & Gladstone, 2007). Some of the situations in which you should confirm are:

• The consequence of misrecognition is moderate to high.
• There are enterprise business rules that require confirmation before executing a transaction.
• You have knowledge about special needs from the user population that indicate they would benefit from more than the standard amount of confirmation (e.g., this would make them more comfortable even though the procedure is less efficient.)
• There is evidence of low confidence from the recognition system.

There are a number of different ways in which applications deal with problematic user input (McInnes et al., 1999; McTear et al., 2005), for example:

• Simply accept the input and move on
• Reject the input and reprompt (also see: How to phrase reprompts for a given situation)
• Confirm the input

Confirmation can be either implicit or explicit. There are a number of different terms in the VUI literature that are analogous to “implicit” and “explicit”, and the terms “implicit” and “explicit” are not always used in the same ways. In this section, we use the definitions from Lewis (2011, p. 252):

• Implicit confirmation: Refers to confirmation presented in a prompt or message as information related to the input that does not require the caller to take an explicit action to move forward.
• Explicit confirmation: A specific confirmation step to which the caller must respond to move forward toward task completion.

To determine whether it is necessary to confirm, consider the consequences of misrecognition.

• If the consequence is very low, then don't confirm.
• If the consequence is moderate, provide implicit confirmation. If the content of a following prompt or message provides sufficient implicit confirmation, then provide no other confirmation.
• If the consequence of an error is potentially more severe, provide explicit confirmation.

Note that in natural language understanding systems that include dialog management, the dialog manager will make dynamic decisions regarding confirmation (Krahmer et al., 2001; Litman et al., 2006; McTear et al., 2005; Minker et al., 2007; Torres et al., 2005).

For most current IVRs, the decisions about confirmation are the responsibility of the VUI designer. Note that some designers choose to treat low confidence recognitions the same as No Match errors, rather than using separate confirmation-handling prompts.

Damper, R. I., & Gladstone, K. (2007). Experiences of usability evaluation of the IMAGINE speech-based interaction system. International Journal of Speech Technology, 9, 41–50.

Krahmer, E., Swerts, M., Theune, M., & Weegels, M. (2001). Error detection in spoken human-machine interaction. International Journal of Speech Technology, 4, 19–30.

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

Litman, D., Hirschberg, J., & Swerts, M. (2006). Characterizing and predicting corrections in spoken dialogue systems. Computational Linguistics, 32(3), 417–438.

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.

McTear, M., O’Neill, I., Hanna, P., & Liu, X. (2005). Handling errors and determining confirmation strategies—an object based approach. Speech Communication, 45, 249–269.

Minker, W., Pitterman, J., Pitterman, A., Strauß, P.-M., & Bühler, D. (2007). Challenges in speech-based human-computer interaction. International Journal of Speech Technology, 10, 109–119.

Torres, F., Hurtado, L. F., García, F., Sanchis, E., & Segarra, E. (2005). Error handling in a stochastic dialog system through confidence measures. Speech Communication, 45, 211–229.