Confirmation Strategies

This topic describes different confirmation strategies, and reasons for choosing one or the other.

Yes/No Confirmations

A Yes/No confirmation is one in which the user is asked to explicitly confirm an item or chunk of information gathered during a previous part of the conversation.

In the preceding example of the telephone-based scheduling scenario, the application has gathered a few pieces of information over the course of four states, (getDate, getTime, getDuration and getSubject). The next dialogue (confirmAppointment) confirms the data the user has provided by reading back the data and asking an explicit Yes/No question.

There are at least two possible approaches to organizing the call flow for this type of confirmation. One is to confirm using two dialogues—a non-recognition state that reads the information back, followed by a recognition state that asks for confirmation:

(READ BACK)

So that's: <SUBJECT> on <DATE> beginning at <START_TIME> and running for <DURATION>. 

(CONFIRMATION)

Does that sound right?

The user can either confirm or reject the data by answering "Yes" or "No."

An advantage of this scheme is that the confirmation of the yes/no state has the same supporting prompt structure associated with all other recognition states in the system. If the user does not respond, the system could follow with a further prompt.

(SILENCE 1)

I didn't hear anything. Were those the correct details for your new appointment? <pause> 
If you need to, just ask me, and I'll say them again.

This approach enables a reasonably clean separation from a dialogue modeling point of view. The confirmation of the yes/no state looks like any other. It has all the basic supporting prompts that any standard dialogue does.

When coding this approach, developers might combine these two questions into a single QA control or keep the Yes/No separate if it relies on a shared prompt function that implements basic counting of NoReco, Silence, and GiveUp errors. Some situations may benefit from the simplicity of using a single dialogue. There is no right answer. It all depends on the situation at hand and the needs of the design. Often, writing the prompts points to a solution.

Short Time-out Confirmation

Another confirmation strategy involves the use of a short time-out. The system includes the most recently gathered information as part of the next turn. In the absence of user denial, the system takes the user's silence as a tacit confirmation of the data, as in the following example:

When and How Often

While it might be most reliable from a recognition point of view to confirm what the user says after each turn, this strategy might become tiresome and counterproductive. However, allowing too much of the conversation to pass by without confirming crucial details may cause users to have to retrace their steps, become frustrated and possibly lose important data. Some simple guidelines are:

• Gather 3 (+/- 1) items before confirming
• Observe logical task boundaries

See Also

Call Flow