Definitions

• 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.

When and how to use implicit confirmation
The most common use of implicit confirmation is when:

• Recognition confidence is high
• The potential consequence of misrecognition is low – but not low enough to skip confirmation completely

A common style of implicit confirmation is to feed key information forward into the next prompt (Balentine & Morgan, 2001), for example:

• System: Checking or savings?

• Caller: Checking.

• System: OK, checking. Are you making a deposit or a withdrawal?

The specific technique used above is called “landmarking” or “feed-forward” – the system repeats the choice the caller just made. In this case, the information is of value to the caller because the following prompt (“Are you making a deposit or withdrawal?”) could apply to either checking or savings. (For an example of landmarking that does not benefit the caller, see Landmarks as implicit confirmation.)

An alternate non-landmarking approach could be something like:

• System: Are you making a checking deposit or withdrawal?

Advantages and disadvantages of implicit confirmation
The key advantage of implicit over explicit confirmation is that when it's right, it's faster.

When it's wrong, however, it isn't always clear to callers what they need to do to recover from the error.

Weegels (2000) found that 8 of 20 participants had trouble responding to implicit confirmation in which the system made an error (only about 60% were successful). In a similar study that had a similar outcome, Boyce (2008) presented a simulated error with implicit feedback to participants in a study and found that 63% of them responded with “No” or “No” followed by the corrected input; 15% made no attempt to correct the error.

That's why it's important to use implicit confirmation only when it has a high likelihood of being right.

To address this weakness, Boyce and Viets (2010) recommend including a quick instruction as part of the implicit confirmation prompting, especially if the system rates the caller response as having low confidence, for example:

• System: Thank you for calling XYZ Bank. What would you like to do?

• Caller: Transfer funds.

• System: OK, transfer funds. If that's not right, say Go Back. How much do you want to transfer?

Including this type of message to overcome the weakness of implicit confirmation greatly reduces its speed advantage, but maintains the possibility of allowing the caller to proceed without requiring explicit confirmation.

When and how to use explicit confirmation
Use explicit confirmation when any of the following apply:

• The system is about to perform an action it cannot undo
• The enterprise has business rules that require explicit confirmation (e.g., submitting a financial transaction)
• Recognition confidence is low

When scripting explicit confirmation, avoid making claims about what the caller said and focus instead on task goals (Balentine, 1999). For example, avoid, “Did you say you wanted to transfer $500 from savings to checking?” – instead, use something like, “OK, you want to transfer $500 from savings to checking, right?” An even worse example is “I think you said transfer funds, right?” Instead of focusing on what the caller said, focus on the intent, “You'd like to transfer funds, right?”

Advantages and disadvantages of explicit confirmation
The key advantage of explicit confirmation is its clarity – callers know how to respond to the prompts whether or not the system recognized all inputs correctly.

Its key disadvantage is that it's slower than implicit confirmation when recognition is good.

There are a number of alternative approaches to explicit confirmation, each with its own advantages and disadvantages. For more information, see Immediate vs. batch (group) approaches to explicit confirmation.

Balentine, B. (1999). Re-engineering the speech menu. In D. Gardner-Bonneau (Ed.), Human factors and voice interactive systems (pp. 205-235). Boston, MA: Kluwer Academic Publishers.

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.

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.

Boyce, S., & Viets, M. (2010). When is it my turn to talk?: Building smart, lean menus. In W. Meisel (Ed.), Speech in the user interface: Lessons from experience (pp. 108–112). Victoria, Canada: TMA Associates.

Weegels, M. F. (2000). Users’ conceptions of voice-operated information services. International Journal of Speech Technology, 3, 75–82.