Interpreting global commands in conversational IVR

To give callers some control over the conversation, a conversational IVR should always recognize, interpret, and respond to a handful of global commands. Well known global commands are “repeat”, “main menu”, “agent”, “start over”, “cancel” or “go back”. These commands, maybe to the exception of “main menu”, are intuitive enough and correspond to concepts that everyone is familiar with, to some extent. When speaking one of these phrases, a user likely has a pretty good idea of what they wish to happen at that precise moment. In other words, they expect something specific to happen based on context, and the IVR must be aware of that context to provide an accurate interpretation. Otherwise, it runs the risk of sounding a bit dumb.

Let’s see how context matters for something as simple as “repeat”:
Caller: I want to pay my utility bill
IVR: What’s the payment amount?
Caller: $187
IVR: From which account?
Caller: what’s my checking account balance?
IVR: The balance for your checking account is $829.30
IVR: From which account do you want to make your payment?
Caller: repeat

At first glance, we would think that the caller wants to hear the account balance again, right? But what if he just got distracted and did not hear the following question? Considering that possible ambiguity, it might be safer to replay the last two messages. The bottom line is that something as simple as a repeat global command requires careful design, and this is even more true with other, less straightforward commands.

In this post, I will focus on the most potentially ambiguous commands: “cancel”, “start over” and “go back”.

Go back, cancel, start over, where am I?

Interpreting global commands is especially important when the effect of that command is to halt an ongoing task, bring the user back to a previous step, or even at the very start of that task. Each of these 3 so-called global commands, e.g., “go back”, “start over” and “cancel”, have the potential of being ambiguous or misinterpreted. “Go back” being hard to interpret is not surprising, but we may think that “cancel” and “start over” are pretty straightforward, right? You cancel what you’re currently doing and starting over means, well, go back to the beginning! But how do we define what is currently being done, and where exactly is the beginning?

Cancel

Here is an example of how “cancel” can be ambiguous:
IVR: Welcome to MyBank. How may I help you?
Caller: make a payment
IVR: Sure, which bill?
Caller: my electric bill
IVR: What’s the payment amount?
Caller: $122
IVR: From which account?
Caller: no that’s my cable bill (caller interjects to make a correction)
IVR: You want to make a payment to Cable Company, is that right? (IVR confirms caller input)
Caller: cancel
IVR:…

What does this caller want to cancel? That payee correction he just made? The whole payment transaction? Does he want to start over with a different payment (as opposed to a different transaction altogether)? The IVR should definitely not force one interpretation without validating with the caller, because there are at least two chances out of three to get it wrong. In this specific example, the IVR should reprompt the caller to ensure it got it right. Let’s pick up where we left off:

[…]
IVR: You want to make a payment to Cable Company, is that right? (IVR confirms caller input)
Caller: cancel
IVR: Just to confirm, what would you like to do: cancel this payment, start it over, or cancel that last change you made? (The IVR offers the most likely option first)
Caller: start it over
IVR: OK, starting over
IVR: Which bill would you like to pay?
[…]

This example is tricky and would likely not occur very often, but it shows how things can get complicated when the caller is allowed to take initiative.

Start over

The “start over” command is also ambiguous, especially in multi-step processes, because it can always mean either to restart that process, or go back to the very beginning and choose another option. In many IVRs, “start over” and “main menu” have a similar meaning, which is fine in non-transactional IVRs. But when multi-step self-service tasks are supported, the interpretation may vary.

For example:
IVR: Welcome to My Doctor’s clinic. How may I help you?
Caller: make an appointment with doctor Jones
IVR: Sure. The next available appointment with Doctor Jones is on May 1st at 8:15 AM, would that work?
Caller: yes
IVR: Great. Now, I need to confirm your contact information. Is your phone number still 555-333-2222? (the IVR identified the caller with her ANI and now needs to authenticate her, which would happen next)
Caller: start over
IVR: Do you want to schedule a different appointment? (the IVR validates the most likely interpretation)
Caller: no I want to renew my prescription (the caller has an opportunity to correct the interpretation)

I know, your clinic does not offer that kind of service, neither does mine… But this example nicely illustrates the ambiguity, doesn’t it? The bottom line is: when the IVR cannot confidently assume the meaning, it’s safer to validate with the caller.

Go back

Here is an example of how “go back” has the potential to get a little messy:
Caller: make a payment
IVR: Sure, which bill?
Caller: my electric bill
IVR: What’s the payment amount?
Caller: $50
IVR: From which account?
Caller: go back
IVR: OK, what’s the payment amount?
Caller: go back
IVR:…

Does she want to go back to the previous question (most obvious choice), the very first question, or is she trying to go back a couple of steps by saying “go back” more than once? We may want to give her the benefit of the doubt and go back to the previous question, and hope for the best. Worst case scenario, she can always cancel or start over!

Never let your caller get lost

In summary, interpreting global commands in context and disambiguating meaning with the user when in doubt are crucial to ensure that your IVR sounds smart and does not lose the caller in the process. While it seems obvious from a conversational standpoint, effectively automating these strategies requires a sophisticated dialogue engine.

We will explore this topic in an upcoming post. Stay tuned!