One of the essential characteristics of a conversational interface is the ability for the user to make corrections or changes in the course of an interaction. This is true for both text based conversational interfaces like chatbots, and voice based interfaces like voicebots, IVRs or virtual assistants. While handling corrections adequately is important in any truly conversational interface, it is especially critical in conversational IVR, for several reasons:

• This communication mode is less forgiving, as the IVR is often not the preferred channel or is used as a last resort;
• Speech recognition errors are not uncommon due to various factors such as noise or speaker behavior;
• When transactions are at play, getting information right is critical and has consequences.

In short, providing an efficient and elegant way to handle corrections in a conversational IVR is a prerequisite for a successful caller experience.

Corrections include fixing errors from the speech recognition engine, but also changes that the caller wants to make, for instance if they realize they said the wrong date during a payment transaction and wish to correct the information immediately.

There are several situations when corrections, or changes, can occur. Depending on the situation, correction strategies will vary. The goal, however, should always remain the same: help the caller get back on track and successfully progress in the conversation.

This two-part post is meant to explore a variety of cases when corrections occur in a conversational IVR, and what we think are appropriate responses and dialogue strategies to handle them. The dialogue strategies are based on a slot filling model, and we will only focus on corrections impacting slots, i.e. entities. Changing intents is a topic that will require its own post.

In Part 1, we will focus on the following situations: corrections occurring when the IVR confirms a low confidence result with the caller, and corrections following the final confirmation of a transaction. In Part 2, we will explore corrections occurring in the course of a transaction and other mixed initiative situations.

The use case

Most of the examples below will rely on the classic bill payment use case. Most banking transactional IVRs (whether speech enabled or in DTMF) allow callers to make one time or recurring payments, and the IVR typically collects each item one at a time through directed dialogue: payee, amount, account from which to pay, recurrence, frequency (for recurring payments), payment date (for one-time payments), start and end dates, or start date and number of occurrences for recurring payments. Once all the elements of information required by the transaction have been collected, the IVR summarizes the transaction and asks for a final confirmation from the user before processing the transaction. The IVR should allow the caller to make corrections in various situations to ensure that the recorded payment is accurate.

The basic correction: no to confirmation

In a speech enabled IVR, when the user answers a question, the input is sent to the automatic speech recognition (ASR) engine, which returns one or several hypotheses, along with confidence scores. When the confidence score falls between the rejection and the acceptance thresholds, this means that the recognizer is unsure that the hypothesis corresponds to what the user said. The most common strategy is for the IVR to confirm the hypothesis with the user; when the caller answers positively, the dialogue moves forward. Otherwise, the IVR re-prompts the caller for a new input.

While many users will simply answer “no”, others may decide to make the correction immediately, for example:

IVR: I heard “fifty dollars”, is that right?
Caller: No, I said sixty

In that situation, the IVR should understand the caller’s intention to correct the value that was misrecognized, evaluate the new input and replace the incorrect value with this new, corrected one. The IVR must also determine whether the confidence score is high enough to accept the new input, and if not, adequate dialogue strategies must be defined to naturally get the caller back on track.

Upon final confirmation of a transaction

Before recording a transaction, a summary of collected items (or slots that were filled) should be provided to the caller for validation, along with ways to modify one or several items if need be. The most basic way to allow the caller to make corrections is to start over and collect everything anew. That’s not very efficient, nor elegant. The caller should be able to tell the IVR what needs to be corrected and with what, and the IVR should handle the caller’s input in a logical, natural manner. We’ll show some examples of how the dialogue may react depending on the type of correction the caller is trying to make.

Only saying what needs to be corrected

This simple pattern occurs when the caller only tells the IVR which item was wrong, without providing anything else:

IVR: To confirm, that’s a one time payment to Visa, for 240 dollars, from your checking account, on May 1st, 2019. Is that correct?
Caller: No the date is wrong
IVR: Sorry about that. What’s the payment date?
Caller: May third

In this case, the incorrect slot is reset and the dialogue must simply recollect the value for that slot, and then reconfirm the whole transaction before recording it. A transition (in this case “Sorry about that”) may precede the re-prompt to ensure dialogue fluidity.

The correction impacts other values

Let’s say that the caller changes her mind and wants to record a recurring payment instead:

IVR: To confirm, that’s a one time payment to Visa, for 240 dollars, from your checking account, on May 1st, 2019. Is that correct?
Caller: I want to make a recurring payment

In such a situation, the dialogue will have to adapt, reset values and modify the set of slots to be filled: “one time” needs to be changed for “recurring”, the “payment date” slot needs to be removed and replaced with “start date” and “end date” slots, and a “payment frequency” slot needs to be added. As a consequence, the dialogue will need to go back, collect these new values from the caller and confirm the modified transaction.

To ensure a smooth transition, an implicit confirmation is appropriate:

[…]
Caller: I want to make a recurring payment
IVR: Alright, how often do you want to make this recurring payment? [short pause] Weekly, monthly, or every other week?

This way, the caller knows exactly what the IVR understood. If the IVR misrecognized the previous request, she has an opportunity to rectify once again.

Providing a new value

An efficient way for the caller to change an incorrect value is simply to provide the new one:

IVR: To confirm, that’s a one time payment to Visa, for 240 dollars, from your checking account, on May 1st, 2019. Is that correct?
Caller: It’s 250 dollars

The user could also say “No, the amount is 250 dollars”, which would give the IVR both the slot to change as well as the value, in the same utterance. That type of input must also be properly supported and handled by the dialogue model.

Correcting more than one item

The caller may also want to change more than one value:

IVR: To confirm, that’s a one time payment to Visa, for 240 dollars, from your checking account, on May 1st, 2019. Is that correct?
Caller: No that’s 250 dollars from my savings account

This example is rather straightforward, since there is only one slot of each type: “amount” and “payment account”.

Things can get much more complicated when more than one slot is filled with the same entity type: for example, a funds transfer, where two accounts are at play, or a recurring payment, where the “start date” and “end date” are both filled with date entities:

IVR: To confirm, you want to make a monthly payment to Utilities, for 240 dollars, from your checking account, starting on May 1st 2019 and ending on April 1st 2020. Is that correct?
Caller: No that’s May third 2019 ending on April 3rd 2020

For such situations, the dialogue model needs to be able to analyze the user input in order to determine which entity corresponds to which slot. While this is obvious for a human, it requires adding various strategies to the dialogue model, for instance syntactic rules, regular expressions, etc.

Disambiguating an imprecise change request

Now, let’s say that our caller wants to change the date of her recurring payment, but does not say which…

IVR: To confirm, you want to make a monthly payment to Utilities, for 240 dollars, from your checking account, starting on May 1st 2019 and ending on April 1st 2020. Is that correct?
Caller: the date is wrong
IVR: Which date do you want to change: the start date or the end date?

To which the caller could answer with “start date”, “end date”, or “both”, or, to make things more interesting, she could also provide new values for either one of the date slots… This requires the dialogue model to include disambiguation within the change request, in order to reset the proper slots before going back to collecting the new values. This also requires the dialogue model to correctly parse and interpret potentially complex input.

In summary

The use cases explored in this post have shed light on potentially complex dialogue patterns. Dialogue models for conversational IVR take into account corrections due to ASR engine uncertainty and due to callers’ wishes or needs to modify information. Modifications can be simply done by putting a new value in a slot, but they can also impact other values, even change the course of the dialogue. Getting the caller back on track in a minimal number of dialogue turns can make all the difference between appreciation and frustration. This complexity is a challenge for VUI designers, but also for application developers, as traditional dialogue models for IVR do not easily support mixed initiative and less predictable user input. Getting them wrong may have a huge negative impact on IVR performance and caller experience, but getting them right can be a true differentiator.

In Part 2, we will explore change and correction management during the course of multi-step interactions or transactions.