In Part 1 of this two-part post, we explored corrections and change management for conversational IVR in two main situations: during the confirmation step of an input collection dialogue, and after the final summary and confirmation of multi-step transactions.

In Part 2, we will discuss corrections occurring elsewhere in the conversation. As was the case in Part 1, we will focus on corrections made to elements of information collected in the course of a multi-step dialogue, or slots. We will not tackle intent changes, which include events like digressions, task switching, canceling a transaction halfway through or requesting to speak to an agent.

For most examples, we will, once again, refer to the bill payment use case described in Part 1.

Immediate corrections

This situation may occur when the caller realizes that she provided an incorrect value when answering a question and wants to fix that mistake immediately, for example:

IVR: From which account?
Caller: checking huh savings

Since there is only one slot corresponding to an entity “account type”, we can safely assume that the second occurrence of the “account type” entity is the correct value to fill in the “from account” slot. Considering that the entire transaction will be summarized and confirmed before submitting it, the dialogue can move on to the next step without further confirmation, or by using an implicit confirmation, like “OK, from your savings account”.

Answering an earlier question

The caller is further down in the transaction and realizes she has said the wrong payee:

IVR: Which bill do you want to pay?
Caller: American Express
IVR: What’s the payment amount?
Caller: Oh no that’s Visa
IVR: Alright, I will make the payment to Visa
IVR: What’s the amount?

In this case, once again, an implicit confirmation is appropriate following the correction, to reassure the caller that the request was well understood, and to allow her the opportunity to make another correction, should the request be misunderstood.

Once the correction is completed, the dialogue continues with the next logical step. Note that the dialogue model should always be flexible enough to allow the addition of transitions or the use of different versions of a collection prompt, to ensure more natural dialogues.

As was described in Part 1, it should also be possible for the caller to only provide the item he or she wants to change without giving the new value, for example:

IVR: Which bill do you want to pay?
Caller: American Express
IVR: What’s the payment amount?
Caller: Change the payee
IVR: Sure, which bill do you want to pay?
Caller: Visa
IVR: What’s the payment amount?

In this case, the IVR will empty the “payee” slot, but it should also use some form of acknowledgement (here, a simple “Sure”) to tell the caller that the change request was understood. If the caller provides both the item to change and the new value (e.g. “the bill I want to pay is Visa”), then the dialogue should replace the slot value with the new value, implicitly confirm the change and move on to the next step.

Other corrections described in Part 1 will also apply within an ongoing task, as long as the impacted slots are already filled and that the dialogue is able to correctly interpret the caller’s utterance. Whenever the interpretation is ambiguous or impossible to infer, the dialogue should fall back to repair or error handling strategies.

Precocious corrections

While the previous examples all refer to legitimate correction attempts, the dialogue should also anticipate situations where the caller tries to – or seems to try to – change something that was not already provided. How to react will mostly depend on how the correction is expressed.

If the caller specifically mentions that she wants to change an item that was not yet collected, it is reasonable for the IVR to respond with a soft warning and continue:

IVR: Which bill do you want to pay?
Caller: Visa
IVR: What’s the amount?
Caller: Change the date
IVR: Sorry, I haven’t collected the payment date yet. Let’s continue.
IVR: What’s the payment amount?

However, if the caller prematurely provides a value for the empty slot, then the IVR should record it and populate the corresponding slot:

IVR: Which bill do you want to pay?
Caller: Visa
IVR: What’s the amount?
Caller: Change the date for May 1st
IVR: Alright, I will make the payment on May 1st
IVR: What’s the payment amount?

Obviously, in this case, the IVR will not collect the date, unless it turns out that the caller wants to record a recurring payment…

A task can branch into different paths (on this topic, you can consult my colleague Pascal Deschênes’s post), and this impacts slot assignment for a given entity. This raises an important question: is it possible to assign this entity to a slot prior to branching? For example, if the caller provides a single date early in the bill payment task, before selecting the one-time payment recurrence value, should that date be assigned to the “pay-date” slot (as opposed to a “start date” or an “end date” slot)? In other words, should we define temporary slots for preemptive slot filling purposes? In the case of the date being assigned to the “pay date” slot preemptively, it is probably reasonable to do so. However, this requires some logic to either render the “pay date” slot obsolete once a “recurring” value is assigned to the “recurrence” slot, or to proceed with a disambiguation step to determine whether the pay date is a start or an end date.

In summary, how to handle correction attempts in the course of a multi-step transaction will depend on several factors like context, what is known of the caller, what slots have been filled or not, the timing of the correction attempt, or how many items the caller is trying to change at once. Though as designers we aim at handling most situations gracefully and adapt to callers’ behaviour, it is also essential to determine when a correction attempt is just not relevant, and react accordingly.

Finding the right dialogue model

The correction use cases that were explored in this two-part post shed light on the need for any conversational dialogue model to be very flexible and adaptable, in order to provide the VUI designer with the right handles to create natural and efficient conversations with the user. This is true not only for IVRs, but also for voicebots, and other truly conversational interfaces.

Finding a dialogue model that provides such flexibility and adaptability is proving to be a challenge. Our team has experienced with various dialogue engines on the market, and we have also explored the possibility of developing our own engine. We met various obstacles and faced a few more serious roadblocks.

We are currently working on adapting the Rasa Core dialogue engine for a conversational IVR solution, with VoiceXML integration. Our approach is promising but we are, unsurprisingly, facing numerous and interesting challenges. We will share our experience in a short blogpost series, coming up in June. Stay tuned!