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!

The post When “cancel” does not mean “cancel” first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post When “cancel” does not mean “cancel” appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Contact centers are still a central component of medium and large enterprises, and an essential channel for customers to connect with businesses. For a contact center to reach its full potential, it needs to meet the following business objectives:

• Customer service: provide customer support, deliver the best possible experience and generate positive word of mouth
• Customer retention: retain existing customers and boost customer loyalty
• Operational efficiency : by optimizing average interaction and resolution time

Contrary to popular belief, the telephone is still a widely used tool to connect with enterprises. While customers appreciate being able to self-serve and perform transactions on their own—whether on their mobile phone or on the web—they still turn to contact centers for assistance when they have more complex issues or are having a hard time with self-service. In both cases, the customer is likely to call your company looking to speak with a real person. And when they do, you want to be sure you make a strong impression!

Many enterprises today still rely on traditional touch-tone IVRs for call routing and to establish customer intent. But touch-tone menus are often complex, with multiple steps and options, confusing terminology and long wait times. Frustrated with the experience, customers end up hitting zero or selecting an incorrect option (any option!) hoping to reach an agent. This results in a high volume of misrouted calls, with customers having to repeat themselves and agents wasting valuable time talking to customers they can’t help.

These frustrating experiences, for both the caller and the agent, come at a cost: $62 billion in the U.S. alone in 2016.

So how can you improve your customer experience in the IVR while optimizing your agent resources? For starters, by asking customers why they’re calling, instead of having them go through a bunch of menu options trying to get their issue resolved.

Natural Language Call Steering (NLCS) IVRs use natural language understanding and automatic speech recognition to listen to callers, interpret what they’re saying and understand what they need.

By precisely categorizing the caller’s request, the NLCS can route the caller to the right agent on the very first try, most times in a single interaction. This serves to reduce the number of transfers and means callers don’t have to repeat themselves. Not only that, but the IVR can transfer the information it collects directly to the agent, giving them a head’s up as to why the customer is calling.

Making the transition from a touch-tone IVR to an NLCS solution is an investment, but one that will generate great returns. And sticking with the alternative can be extremely costly for companies in the long term, resulting in:

• High call transfer rates, a costly issue that wastes valuable agent resources
• Customer frustration, which again wastes agent resources (with customers spending more time expressing their frustration than discussing their needs) and leads to low agent morale/high employee turnover
• Poor customer retention, with existing customers often leaving the company after a single negative experience
• Loss of potential customers if the IVR experience is negative and you fail to make a good first impression

NLCS solutions result in fewer misrouted calls, reduced route times, fewer abandoned calls and better agent utilization—so you can improve your customer experience and reduce your operational costs. And the benefits don’t stop there. NLCS IVRs give you the opportunity to:

• Identify new self-service opportunities, by undersanding why people are calling, we can identify opportunities to address their issue right in the IVR, therefore greatly reducing the volume of calls into the contact center
• Offer simplified access to your services, by consolidating all your services in a single phone number
• Gather key data with analytics, giving you better insights into your customers, products and services

NLCS IVR solutions are a game changer, leveraging the latest conversational technologies to deliver an intuitive, human-like caller experience. Bring your voice channel into the future to improve your customer experience, boost customer loyalty, optimize your agent resources—and make every call count.

Many thanks to my colleague Annie Brasseur for her invaluable contribution to this post, and to Yves Normandin for his insightful comments.

Download our one pager!

The post Making every call count first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Making every call count appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

In other situations, we must rather produce canned demos, whose purpose is to “wow” potential clients by showcasing inspiring use cases and state of the art functionalities – even before the actual development takes place.

Between these two extremes, other types of demos can serve various purposes and can allow potential or existing clients to try, test and appreciate what a conversational IVR can do.

Different types of demos serve different purposes, require various amounts of effort and budget, allow diverse levels of hands on experience and involvement from those who try them, and present varying degrees of risk. Investing in the right type of demo for the right usage and the right prospect can be a determining factor in the success of that demo.

In the following paragraphs, I will describe four categories of demos, from the least to the most interactive, with their main characteristics, proposed usage, advantages and risks.

The canned demo

This is the type of demo that you often find on Youtube, where overly happy young people have an almost human conversation with the IVR. It recognizes the caller, understands everything, asks the right questions, reacts naturally when interrupted, and sometimes even risks a joke.

This type of demo is great to showcase the possibilities of a conversational IVR, to wow potential clients and make them dream, but also to provide decision makers with a vision of what their IVR could do for them, if they hired you. The canned demo is ideal to approach new prospects without investing a lot and without being too intrusive. Sales can safely use canned demos in early discussions with clients, and these demos can live on your website and be sent to anyone who’s interested in knowing about the potential of a conversational IVR.

On the flip side, canned demos can easily generate unrealistic expectations when the scenarios are too far from what your company can actually, realistically deliver. Overpromising is a risk, as well as making things look way easier than what they actually are to design and develop.

The scripted demo

The scripted demo consists of a working IVR that only supports a very finite number of scenarios, typically involving happy path use cases. It works well when the person calling the demo IVR knows exactly what to say, when, and how to say it.

This type of demo can allow you to demonstrate the technical feasibility of a few sample use cases in a fully controlled environment. Developing such a demo requires to design and develop a simple IVR, but it does not require to plan multiple scenarios or train sophisticated NLU models. Simple static speech grammars can be used, as long as the sample scenarios are covered.

While useful, this type of demo can easily underwhelm the recipient: it does not provide much of a wow factor, nor does it provide any hands on experience, since the prospective client is not really allowed to try it, with or without supervision. To use sparingly.

The environmentally controlled demo

The purpose of the controlled demo is to give your current or prospective client the opportunity to call a prototype of a conversational IVR, while making it clear which use cases or scenarios are included, and making sure you’re in the room when they call. It must be clear that the prototype is not production grade, but that it covers a large enough panorama of use cases and scenarios, including more than just happy paths.

This type of demo is great when you have an opportunity for more involved and detailed discussions with your client and wish to impress them with a sophisticated, well functioning demo. By trying it firsthand, your clients will get a feel for what their customers’ experience could be. By supervising the demo session, you have an opportunity to encourage your clients to try specific scenarios that you want to put forward, you can answer any questions they have and provide any technical details that they may find relevant or interesting. When properly done, this type of demo can convince a prospective client to move forward with your project.

This type of demo, however, requires quite a lot of work and presents some risks. To function properly, multiple scenarios must be anticipated and designed, including mixed initiative dialogues and error recovery strategies. In addition, the application must be robust to user input, which means a lot more time dedicated to developing good NLU models and speech grammars. Clients will try stuff; your demo IVR must be able to handle it.

The free roaming demo

That’s the fearless demo that you’re ready to release and let people use without supervision, and without you breathing down their necks. Scary!

This type of demo is more like a pilot deployment than a demo per se. It is pretty much the last stage of a prototype before it is ready to be deployed in production. It is extremely useful as a tool to collect data from a variety of users, or to share with internal employees at your client’s site to gather feedback for optimization. When it works well, it can also be used by some of your clients to showcase to other prospective clients in their enterprise, or by your partners to show to their clients.

Such a demo must include a significant number of functionalities, use cases and scenarios, including mixed initiative strategies, exception paths and error recovery strategies, as well as a very robust NLU module. This is costly. And the risk of letting such a demo out in the world is also significant. If it does not work well, it may have a very negative impact on your company’s image and communication strategy, among other things. But if it does work well, it can have enormous potential.

So, which one is right?

As you may have guessed by now, it depends. On what you want to demonstrate, to whom, in which context, on how much risk you are willing to take, and most of all, on how much time and money you can afford to spend.

• To manage risk, we recommend a few safety measures:
• Have a canned demo ready in case your interactive demo doesn’t work.
• Know your equipment and test it in advance.
• You should not use a speaker phone, as it affects barge-in and can impact speech recognition.
• Inform your department when you do a demo to ensure that no maintenance operation will take place during your presentation (yes, it happens!).
• The “demo curse” really exists! If a problem occurs, keep calm and carry on, and learn how to improvise.

In summary, whichever type of demo you decide to put forward, managing expectations and clearly communicating the demo’s purpose and limitations are essential to its success. You don’t get a second chance to make a good impression!

Many thanks to my colleague Jean-Philippe Gariépy for the initial idea, his review and great suggestions!

The post How Far Can You Go? Managing Expectations in Conversational IVR Demos first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post How Far Can You Go? Managing Expectations in Conversational IVR Demos appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

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!

The post Corrections in Conversational IVR – Part 2 first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Corrections in Conversational IVR – Part 2 appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

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

The post Corrections in Conversational IVR (Part 1) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Corrections in Conversational IVR (Part 1) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

In this post, I will first revisit what I consider essential criteria for a conversational interface, regardless of the channel or application. Next, I will describe the specificities of an IVR that should be taken into account, and how they differ from other interfaces. Finally, I will explore what it means to design conversational interactions in the context of an IVR.

Conversational Interface Requirements
One fundamental criterion that must be met for an interface to be called conversational is the possibility for the end user to be an active participant in the exchange; in other words, the user must be able to:

• Express their requests in their own words;
• Base their requests on their actual needs, not on what the application proposes (i.e. without the need of a menu or list of options);
• Include more information when answering a question than what the question specifies;
• Interrupt an ongoing task with an unrelated question, get an answer and resume the previous task (in other words, digress);
• Change their mind, e.g., correct of piece of information, go back, interrupt and cancel a task, etc.;
• Switch topics or tasks.

And the conversational interface must be able to:

• Understand the meaning and extract relevant information from free-form spoken or written utterances;
• Keep track of all the input provided by the user to ensure that the application never asks for information that was already provided;
• Consider context when interpreting the meaning of a user’s input;
• Handle digressions and resume tasks;
• Handle change and cancel requests.

This list is not exhaustive, but it provides a basis to determine whether a given interface or application is conversational or not. For instance, a DTMF IVR is not a conversational interface, nor is a speech enabled directed dialogue phone application. Other examples of user interfaces that are not conversational are one shot question-answer sequences such as “OK Google, what’s the weather forecast for today?”, or chatbots that only handle clicking or tapping as input mode.

> CLICK HERE to read the full blog post

The post Whaddya mean, conversational IVR? first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Whaddya mean, conversational IVR? appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.