In recent years, virtual agents have benefited from outstanding technology improvements in the field of Natural Language Processing (NLP) and Artificial Intelligence (AI). 

However, the complexity and the amount of effort required to leverage conversational AI platforms such as Google or Amazon still prevents many businesses from seeing a move towards virtual agents as a profitable investment. That’s where managed virtual agent solutions save the day!

By leveraging the call volumes of several customers, managed virtual agent solution providers are able to offer on-demand virtual agents much faster and at a much lower cost than the implementation of an entire conversational AI platform.

Many businesses have developed their own set of criteria when it comes to selecting an outsourced workforce but these criteria may not entirely apply when it comes to virtual agents.

When choosing a managed virtual agent solution provider, businesses should consider these 4 factors:

• Integration & security 
• Voice & telephony experience
• Conversational design experience
• Continuously improving solution 

Let’s explore the details of each factor and what should be expected from providers.

Integration & security

From an integration perspective, a managed virtual agent solution is similar to outsourcing your calls which involves providing a way to transfer calls to another contact center and providing them access to the systems required for the selected  use cases. 

The following figure provides a high-level architecture view of a managed virtual agent solution.

Hopefully, your provider will be able to integrate with your existing systems without requiring that  you upgrade some of them, such as your contact center platform. You will also need to review the implications of exposing some access points to an external provider.

You will need to discuss how secure the overall integration will be as customer data and their voice interactions will be shared with this provider. You need to verify that your provider will maintain customer data (in transit and at rest) within the geographies you serve. For example, you might not want to have traffic go through the US if your business is in Canada. You also need to review the security posture of your provider. Security audits and certifications (ex. SOC 2, ISO 27001) can surely help reviewing and ensuring compliance with your requirements more quickly. 

Voice & telephony experience

Providing a great conversational experience on the phone channel is more than just taking a chatbot and adding speech-to-text and text-to-speech. Voice conversations are real-time synchronous communications. There are multiple factors at play: keeping response time in milliseconds to avoid silence and awkwardness, detecting accurately the end of speech and interruptions (i.e. barge-in), handling low quality audio and noise, have great recognition accuracy even when faced with accent or people hesitating or changing their mind and being able to render natural responses.

When choosing a managed virtual agent provider, you will want to make sure that they have a lot of experience with the challenges of handling phone communications. 

Conversational design experience

As mentioned regarding low satisfaction scores for some IVRs, a one-size-fits-all mentality does not usually provide a good experience. Personalisation should be part of your conversation design strategy. For example, integrating your virtual agents with a CRM can help leverage customer data and context to better understand their needs and the reason why they might be contacting you. When working with a provider, you will want to ensure that they will not just give you a cookie-cutter solution that does not provide any personalization with the conversational experience.

Focusing on the user experience should aim at reducing friction with different interactions. Unfortunately, badly designed IVRs might be too restrictive and follow a rigid structure that customers do not appreciate. While you don’t want to trick your customers into believing they are talking to a human, your goal should be to  replicate as much as possible the experience of talking to a human. Letting people express themselves more naturally and capturing the required information as they speak freely is what happens in a human-to-human conversation. 

You also need to consider your engagement channels with regards to the conversational design. While having an omnichannel solution is certainly desirable, businesses need to understand distinct constraints that relate to each channel. Let’s take for example an appointment booking use case with a virtual agent. If a customer wants to book an appointment on a given day where there is a lot of availability, then you could show all the times in a widget on a chat interface and let the customer review and select the proper time. But on the phone, this strategy will fail since the number of choices will be too great to just list them verbally. A voice user interface comes with several considerations that need to be incorporated in your design. Be wary of providers that tell you their virtual agents work with any channel. 

Continuously improving solution

People are unpredictable. For a virtual agent solution, you need to plan that people might not interact with a virtual agent as expected. In addition, the needs of your customers can evolve with time. Just like human agents, virtual agents need some form of monitoring, quality assurance and training. 

Therefore, it is important to understand that a virtual agent solution is not only about implementing and launching a solution. It involves monitoring, supporting, maintaining and optimizing the solution to adapt to your customers. You will want to make sure that your provider will be a good partner in constantly improving your solution. 

You will also want to see how your provider can leverage the usage data to provide insights into the voice of your customers. As people express themselves naturally, this is a great opportunity to identify how you can better serve them. This can also help identify other use cases that could be automated. 

Benefits of a managed solution

Leveraging the expertise of a partner provider of virtual agents has multiple benefits. 

The most significant benefit is accelerating the time-to-value of the solution. A provider will already have possible integration connectors to your systems, have designed similar conversational agents or dialogs, have optimized difficult user inputs to recognize, … This can greatly reduce a virtual agent project time from several months to just weeks. 

Defining, designing, implementing and maintaining virtual agents requires a cross-functional team and a good understanding of the latest conversational AI technologies. This expertise can greatly increase the total cost of the solution and increase the required investments. A fully managed virtual agent provider can reduce these investments and make costs more predictable. 

Deploying a customer facing voice virtual assistant can be risky for businesses.  According to a Rasa survey, 41% respondents reported that limited experience building virtual assistants was a barrier to conversational AI adoption and only 18% of respondents using voice assistants are in production with it.  A fully managed virtual agent provider can leverage its experience to ensure the successful deployment of solutions in production. 

Summing up

Automating calls through a fully managed virtual agent solution can help contact centers service their customers for simple and repetitive tasks in order to let their human agents focus on value added calls. It involves partnering with a provider and businesses should make sure that key criteria will be fulfilled by their provider. 

Nu Echo has 20+ years of experience creating conversational experiences that improves operational efficiency with an exceptional customer experience.  If you are interested in a managed virtual agent solution, then contact us today. 

The post Call automation doesn’t have to be risky, long and costly first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Call automation doesn’t have to be risky, long and costly appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Imagine you booked tickets to an upcoming event that you are really excited about. A few weeks later, you get an email saying that your event has been canceled. You try to understand your options: can I get a refund, is the event postponed, what seating will I get if I reschedule, … You browse through the Web site and cannot find answers to your questions. So you decide to call the event’s customer service and then you have to wait for almost an hour until you can finally talk to an agent. 

This may sound like a familiar story. Through this blogpost, I will illustrate why with a few counterexamples.

 These bad experiences are mostly due to 4 main trends currently affecting contact centers.

⚠️High volumes on the phone channel

According to CFI group, 76% of people reaching out to customer service choose to place a phone call.

⚠️Unpredictable call volumes

 According to Talkdesk, 50% of retail CX professionals say the top challenge they face is high variability in the amount of customer support needed during holidays, seasonal spikes, off-season dips and others. People are also adapting to new situations such as work-from-home, virtual interactions and changing travel rules.

⚠️Rising call complexity

According to the Harvard Business Review which studied the effect of the COVID pandemic on customer service, the percentage of calls scored as “difficult” more than doubled, hold times increased by as much as 34 percent and escalations by 68 percent.

⚠️Increasing contact center workforce costs & complexity

According to CGS, 37% of companies are not confident or only somewhat confident in their ability to maintain service levels and prevent negative effects to service levels from additional waves of COVID. 

🌀A perfect storm for contact centers

The combination of these trends is putting a tremendous strain on contact centers. Managing a contact center workforce has become increasingly difficult with more unpredictable call volumes combined with hiring and staffing difficulties. 

Not being able to speak with a business can lead to lower customer satisfaction and engagement which can lead to loss of revenue and lower brand value. 

How can contact centers keep up? Hopefully, businesses can use different strategies to mitigate the impact of these challenges. To help choose the right strategies, it is important to consider the complexity as well as the volume of each use case or categories of calls. Call automation is becoming a key element for contact centers to let virtual agents handle simple, transactional calls and leave more complex, added-value calls to human agents. 

We will learn more about how contact centers can partner with providers to automate calls with reduced investments, more predictable costs and lower time to value in our soon-to-be-published article We are currently experiencing higher than normal call volumes. 

The post Ladies and gentlemen, we’re experiencing some turbulence. Please hold the line while we try to find an available agent. first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Ladies and gentlemen, we’re experiencing some turbulence. Please hold the line while we try to find an available agent. appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Even in its core conversational AI business, Nuance is fast transforming itself from a software company with a very large focus on professional services to a product and platform company. This was evident at the 2019 Partner eXperience Summit, but it was even more so at this year’s event.

This change was of course necessary and, I might add, a bit overdue. Long the dominant vendor of enterprise speech technology solutions, Nuance is now being challenged by companies – Google, Amazon, Microsoft, and IBM among others – that offer easy to use conversational AI platforms with state-of-the-art technologies. With these platforms, the claim is that anybody can now develop sophisticated conversational AI solutions; that speech recognition (ASR) and natural language understanding (NLU) work “out-of-the-box” without any need for speech scientists; and that, in fact, you don’t even need developers to build solutions. This is the “do-it-yourself” (DIY) message and it is a compelling one.

Of course, that message is highly misleading. Yes, to some extent, the technology now works “out-of-the-box” in the sense that it is possible to get a simple conversational demo bot up-and-running quickly. With speech-to-text (STT) engines, there is no need to write speech recognition grammars and NLU engines can be trained with a few training phrases per intent. But that’s only good for a demo. Building an effective, enterprise-grade conversational AI system is hard work, no matter what the platform is (more on that in a future blog post).

What is true, though, is that enterprises really are looking for DIY tools. And they are increasingly demanding cloud-native solutions. And, above all, they want flexibility. And Nuance has heard that message loud and clear. They now understand that it’s no longer sufficient to have best-in-class technology and a good professional services organization. Customers want to have flexible development and deployment models.

The most recent big steps that Nuance has taken in that direction are:

• Conversational AI APIs (launched November 2019);
• The Nuance GateKeeper cloud based security and biometrics suite (launched October 2019);
• Nuance Mix: DIY Tooling for partners and end users (general availability planned for end of March)

The introduction of Nuance Mix, in particular, is a big change for a company that is used to directly delivering most of its conversational AI solutions through its professional services organization, using closely guarded development tools. But what we’ve seen so far of Mix is promising, with a slick, contemporary user interface. From a company that has years of experience building and deploying compelling conversational AI solutions, this is quite encouraging.

Nuance is facing powerful new competitors, but it has many advantages. Its technology is top-notch, it has a very large installed base, it offers the most flexible deployment models (premise or cloud), its technology is integrated with most contact center platforms, and it understands better than anybody what it takes to deliver conversational experiences that work not just in demos, but in the real world. Nuance also offers the most extensive capabilities to adapt and optimize the technology for a specific domain and a specific dialog state, which is often what makes the difference between a good demo and an enterprise-grade solution.

Another Nuance differentiator – which they position as a key element of their value proposition – is its strong professional services organization. But that could also turn out to be its Achilles’ heel, because customers no longer want to be dependent on the vendor’s PS; they want to know that there is a large pool of people that are skilled on the technology and have all the tools necessary. It will be a challenge to change a company that is culturally used to delivering all the big projects into one that enables its partners and customers to do it themselves.

In conclusion, Nuance is clearly going in the right direction and making all the right moves, but its plan is ambitious, so execution will be key. Perhaps the biggest challenge will be to implement the culture changes that are required in order to successfully implement this transformation.

We’ve been in this market for close to 20 years and these are by far the most interesting times we’ve seen. We’re expecting quite a ride in the next few years.

The post Nuance Partner eXperience Summit Review: An accelerated transformation in a fluid market first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Nuance Partner eXperience Summit Review: An accelerated transformation in a fluid market appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Consequently, the phone channel now handles more complex problems, and it does so in a larger proportion than before. Since it has become the ultimate channel for these more complex or problematic customer journeys, organizations should strategically pay special attention to their phone channel. No one today would raise doubts about the relevance of offering clients a simple and efficient phone service experience to gain and maintain their loyalty.

The word “conversational” on everyone’s lips

The word “conversational” has been part of the customer experience vocabulary for a few years now; for more on that concept, you may refer to the “Whaddya mean, conversational IVR?” post. Essentially, so-called conversational approaches allow users to express themselves freely by describing their issue in their own words, while supporting a low constraint dialogue structure. The role of the system in the conversation is to collect missing information while adapting to interruptions and topic changes.

When added to interactive voice response (IVR) systems, conversational interfaces revolutionize customer experience by allowing the caller to speak their entire request at once instead of navigating through a maze of menu options. The customer doesn’t need to adapt anymore. Rather, it’s the system that must.

The wake up phone call

For those who have yet to deploy conversational solutions on the phone channel, defining a roadmap for this transition is a crucial step. The strategy must consider potential business benefits, as well as technological risks and organizational impacts. So, how do we get there?

We need a multi-step plan that will allow the organization to progressively assimilate transformations while maximizing benefits. The organization must learn and adjust. Indeed, developing and deploying conversational systems demand that we change the way we define specifications, design the user interface, develop and test the solution. In addition, natural language understanding (NLU) requires large quantities of user data, that is, recordings of calls along with their transcriptions. This is a new but essential element that we need to take into account during project planning.

First words: natural language call steering

As a first step in the transition towards a conversational IVR, it’s quite interesting to consider a natural language call steering solution (NLCS). The goal of such a solution is to allow callers to speak the reason for their call in their own words. The system then analyzes and interprets the caller’s request and routes the call to the right destination, that is, either to appropriate agents or to a self-service module. This replaces menus, at least as the main interface, keeping menus as a useful fallback strategy. Illustrated below is a scenario of a caller interacting with a NLCS solution:

What level of effort is required to deploy a NLCS solution? First, we must run a data collection. On the one hand, collecting speech data from real clients allows to understand how they express themselves when they communicate with the organization. On the other hand, an inventory of products and services, internal and external terminology as well as the structure of the contact center (agent groups, skills, etc.) will help us understand the business domain.

Secondly, the data will be analyzed so that we can define an intent catalogue, that is, all the categories of customer requests/reasons for calling that can be handled by the system. For vague intents requiring a more precise classification, we will need to define a disambiguation strategy, which consists of defining the questions to ask the caller to help them clarify their intent. Finally, for every specific intent, we will need to determine the right destination, whether an agent group or a self-service, able to respond to the caller’s request.

With the data that was gathered during the data collection step, we will then train and tune the speech recognition and NLU modules to successfully recognize the utterances spoken by the callers and correctly classify their intents.

The IVR application for a NLCS is simple. This is partly what makes it an ideal first step in the transition towards conversational IVR. In the flow of such an application, the system asks an initial question, after which it may ask for a confirmation depending on the confidence level of the NLU module. Then, if the request is vague, a disambiguation dialogue may be necessary. Finally, based on the intent identified from the caller’s request, the call will be routed to the right destination.

There are thus very few states in this application. This significantly simplifies design, development, as well as testing.

Once the application is completed, we will proceed with a pilot phase. Typically, during the pilot, the new NLCS solution will only be exposed to a fraction of the customer base. This will allow not only to measure, but also to improve the application performance. Caller utterances will be collected and will be used to enhance the NLU model. During the pilot, it would also be wise to take the opportunity to survey users on their new experience. Once adjustments are made, it will be possible to make the application available at a larger scale.

Following deployment in production, it is important to periodically retrieve caller data in order to improve the NLU model. These post deployment optimizations allow the application to adapt to evolving customer requests.

Here is a simplified view of the development process:

Harvesting the fruits

Reducing the number of incorrect transfers is the main benefit of a NLCS solution and will contribute to improving agent utilization. As a consequence, contact center operational efficiency will increase. By the same token, users will feel less frustrated, which will improve not only customer but also agent experience.

The efficiency and user-friendliness of the conversational interface, in conjunction with the fact that clients can express themselves naturally in their own words, are additional factors that contribute to a better customer experience. The contact center being the connection between the organization and its customers, a better customer experience translates into an increased loyalty.

The new solution will shed light on the actual call reasons. A traditional IVR only reflects what callers select among options that the organization assumes they’re calling about, as opposed to unfiltered natural language utterances that can help identify recurring problems or questions that could be handled by self-services (phone or otherwise). Having this information on hand will also allow us to focus our efforts on optimizing design for the most frequent queries.

The NLCS also offers the possibility of regrouping many phone numbers under a single point of contact. It makes it unnecessary to separate services in order to reduce the complexity and size of the menus. All is available at the first interaction. With a single number, we avoid frustrating callers by forcing them to look for the right number to use or having them use the wrong doorway.

Gaining experience

The NLCS allows the organization to gain experience in several aspects of conversational IVR. For example, when working with natural language speech recognition, it is not possible to use deterministic technical specifications, which are typically what we do when developing traditional IVR. Language being a human phenomenon, it is impossible to anticipate all possible phrasings, which is why we resort to artificial intelligence systems that learn from input data. It is thus necessary to deal with the concept of uncertainty. The system is comprised of two steps, speech recognition and natural language understanding, each adding a degree of uncertainty to the end result.

Therefore if, before, it was enough to say…

“When the user presses the Y key, the call is transferred to department X”

…we must now describe the behavior as follows:

“When the system recognizes intent Y, the call is transferred to department X”

The way the intent is recognized cannot be formally described; it must be considered as a black box. This not only impacts specifications, but also testing. We must consider the following aspects separately :

• The performance of intent detection, i.e. the combined performance of speech recognition and NLU
• The application behavior following intent detection, in other words, once a given intent is recognized, the application will have to behave in a predetermined manner

This principle will stay relevant throughout the evolution towards a complete conversational solution.

This is only an example of one of many practice aspects that require particular attention. We will also need to pay attention to performance evaluation reports, audio data collection and storage, execution of pilot experiments, post deployment tuning, as well as continuous improvement process.

What next?

Once the NLCS solution in place, there are many possible avenues to explore the conversational approach. We could, for instance, add a knowledge base query module. This solution would allow answering the user’s question directly instead of routing the call to an agent who would then need to run the search herself in order to answer the caller.

It is also possible to offer transactional self-service modules in the phone channel. We could modify the existing self-services and introduce new ones. To help identify the most relevant self-services to add, we could leverage the data obtained through the call steering solution. These self-services will allow users to speak complex requests right off the bat. Contrary to the NLCS, whose dialogue structure is simple, conversational self-services demand a sophisticated dialogue engine that can take charge of mixed initiative dialogues and adequately manage specific dialogue events like digressions, topic changes and corrections (see this two-part post on corrections).

Since many self-services need to know the caller’s identity to execute operations linked to their profile, we will have to implement an identification and authentication module. And to preserve the naturalness of conversational interfaces, it would be sensible to opt for a voice biometrics solution to authenticate the caller. This method, which authenticates a client simply with their voice, is user-friendly, quick and efficient.

Having deployed a NLCS solution will allow the organization to face new challenges with confidence. The experience acquired will help the organization to anticipate technical challenges and will allow it to discover how conversational interfaces can bring value.

The post Natural Language Call Steering: Your Gateway to Conversational Automation first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Natural Language Call Steering: Your Gateway to Conversational Automation appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

In an attempt to, if not eliminate, at least reduce some of that confusion, I’ll propose some broad definitions for these terms.

A chatbot is an automated system with which users interact through a “chat-like” interface. This includes messaging channels such as Messenger, WhatsApp, Slack… but it also includes SMS, iMessage, as well as other chat-like interfaces such as web chats, chat widgets in mobile applications, etc. Although chatbot interactions should primarily be done through text input and output, they in practice increasingly incorporate rich media (depending on what the channel supports) such as buttons, images, carousels, webviews, etc. In reality, many chatbots have little or no support for text input, relying primarily on buttons for user input. A chatbot is not necessarily conversational (see here for an explanation of what we mean by conversational) and in fact most chatbots are highly directed, menu driven “dialogs”.

A voicebot is a chatbot with which users can interact vocally. This assumes that the chatbot behind the voicebot can handle natural language input and it requires a capability to convert voice input into text (or directly into intents), as well as text output into voice. Example voicebots include any bots accessible through a voice channel, which include the now ubiquitous smart home speakers, but also the plain old telephone channel as well as any VoIP channel, for instance the call channels of Skype, Messenger, WhatsApp, Slack, etc. In that sense, a conversational IVR could be seen as a voicebot. Another example would be a Dialogflow voicebot, accessible through any voice channel, that takes advantage of Dialogflow’s ability to detect intent from audio.

An Intelligent Virtual Agent (IVA) is a robot that simulates an agent (which, in this context, really means a contact center agent). It provides some of the services normally provided by a contact center agent through a communication with users – via voice or text channels – that resembles human-to-human communication. For reference, DMG defines an IVA as “A system that utilizes artificial intelligence, machine learning, advanced speech technologies (including NLU/NLP/NLG) to simulate live and unstructured cognitive conversations for voice, text, or digital interactions via a digital persona.” A virtual agent can hence be a chatbot, a voicebot, or both.

An Intelligent Virtual Assistant (also IVA, unfortunately) is a system that is dedicated to helping its user, either by providing useful information or advice (weather or traffic information, financial advice, etc.), by answering questions, or by accomplishing tasks on his/her behalf (e.g., planning meetings, booking hotels, paying bills, whatever). Interaction with an intelligent virtual assistant is often done through text or voice conversational channels, which effectively makes it a chatbot or a voicebot, but it can also be done through mobile or web applications.

An IVR (Interactive Voice Response) is an interactive telephone system that is primarily used in a call center to steer calls to the appropriate agent, and possibly to enable callers to perform some self-service transactions. Most IVR systems today are anything but conversational, relying instead primarily on menu navigation through DTMF (touch-tone) user inputs. Several IVR systems also enable speech input, but most of these only support voice menus and directed dialogs. More recently, natural language call steering applications, which enable callers to state the purpose of their call in their own words, have gained in popularity, but that remains a very small minority of IVR systems out there. The surge in popularity of conversational systems, however, is inevitably now impacting IVR, so expect to see a rapidly increasing number of IVR voicebots being deployed in the near future.

The post Chatbots, Voicebots, IVA, IVR: Sorting through the confusion first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Chatbots, Voicebots, IVA, IVR: Sorting through the confusion 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.

Our banking IVR is a self-service application in which a caller can execute tasks like paying a bill or getting an account balance. The dialogue includes a loop that allows the caller to carry out tasks as many times as he or she wants:

The application accommodates expert users by allowing them to quickly complete their tasks:

It also adapts to less experienced users by providing them with a more directed dialogue when needed:

The IVR supports mixed initiative strategies like digressions:

As well as change requests or corrections:

The dialogue also handles error recovery, including errors that are specific to the voice channel:

This is only an overview of the patterns handled by our dialogue model; several others are already implemented. We are also planning on adding other dialogue strategies, such as cancelling a task or handling more complex corrections and change requests.

Implementation: why we opted for a deterministic approach

Early on, we decided to rely on a deterministic approach for our use cases. The main reasons why machine learning was less adapted to our current use cases are as follows:

• Task related dialogues are predictable and relatively directed
• Tasks can be executed repeatedly and the application behavior should be identical every time
• Tasks should be interrupted and resumed reliably
• Tokens of information that are collected for a given task are not relevant for another
• Tasks are independent and must not interact with each other

In addition, our requirements for error recovery and change management were rather strict.

Deterministic approach

Our deterministic approach consists in managing actions using a stack. A stack is a data structure of type last in first out; in other words, the last item added to the stack is the first one to be removed. The action at the top of the stack is the one in focus. When we add an action to a stack, it becomes in focus. When the action in focus is completed, it is removed from the stack and the dialogue goes back to the previous action. This allows to interrupt and resume actions in a predictable and robust manner.

This can be illustrated as follows:

Here is an example of the state of a stack for a dialogue in which the user interrupts the ongoing action (digresses) to ask for a list of their accounts. Once the digression to hear the list of accounts is completed, this action is removed from the stack and the focus comes back to the previous action, that is, the bill payment action.

In addition to allowing us to manage digressions elegantly, our approach allows us to define isolated contexts for each action. This ensures that they remain independent.

Next are some additional details on how this was implemented using Rasa.

Custom policy

In Rasa, a policy is what allows to predict/specify the next action to be executed in the dialogue depending on context (tracker). Out-of-the-box, Rasa offers a combination of deterministic and machine learning based policies. It is also possible to create our own policy. This is what we did by implementing a deterministic policy that alternates between waiting for the next user input and triggering an action used as an action manager (responsible for managing the action stack). Since we do not make predictions as to what action must be executed, our policy does not use stories and does not require a training phase. This is the only policy that we use.

Action manager

We have created an abstraction to manage the action stack that was described above. The stack is a complex object that we store in an unfeaturized slot. The action to be executed depends on the user’s input as well as the state of the stack.

Custom dialogue patterns

One frequent dialogue pattern is information token collection, or slot-filling. This pattern is used, for instance, by the bill payment action. Rasa provides an action for this pattern: the FormAction. However, we needed to support other, more complex patterns than what is offered by the FormAction, for example: slot confirmation when the speech recognition confidence score is low, final confirmation at the end of an action, etc. We have therefore created a custom class “Task” that handles these more complex patterns. Some of our actions inherit this class. We appreciate that Rasa offers the flexibility that we need to implement our own dialogue management strategies.

Unit test framework

Since we have implemented our dialogues using a deterministic approach, we were able to build our own unit test framework to test our dialogues. This allowed us to increase our application’s reliability.

Next steps

Although we have been relying on a deterministic approach to develop our banking use cases, we are also currently experimenting with machine learning to develop dialogues for different use cases.

• Here are some of the next items that we will explore:
• Use the Recurrent Embedding Dialogue Policy to support uncooperative user behavior
• Use Rasa X to learn from real conversations
• Create more natural dialogues by using recorded prompts instead of TTS
• Try to integrate machine learning in our deterministic model

We will share our experience in future posts as we move forward. Stay tuned!

The post Developing Conversational IVR Using Rasa Part 3: Dialogue Management first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Developing Conversational IVR Using Rasa Part 3: Dialogue Management appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

I know, there’s only one question on your mind right now: “What in the world is that name?”. First off, “Rivr” is because it uses Rivr, subtly mentioned in the first post, which is a Nu Echo created, open-sourced framework to write VoiceXML applications, entirely in Java. Then “Bridge” because it links a VoiceXML platform with the chosen dialogue engine. And yes, the pun was intended (but not by me).

But the real question is: “What does it do?”. As I said, Rivr is a framework to develop full-fledged applications, but the Rivr Bridge’s goal is only to translate what comes in and out of the VoiceXML platform and throw it to the Rasa side of the world in a digestible format. For instance, a classic Rivr application would programmatically process each user input and define the next dialogue steps, unlike the Rivr Bridge, which would query the chosen dialogue engine to decide the next dialogue steps. Adapting the model was simple, maybe even simpler than we thought. It roughly looks like this:

The great advantage of using the Rivr Bridge is that it interprets the VoiceXML platform’s input and generates bulletproof VoiceXML. For reusability purposes, we decided to make the Bridge platform-agnostic and application-agnostic, and let an IVR channel on the Rasa side manage the Rasa-specific aspects, which would allow us to eventually plug in other dialogue engines.

Here is an artistic representation of our input pipeline:

… Through an IVR JSON Protocol…

To better define the content of the requests and responses exchanged by the Rivr Bridge and the IVR channel, we designed a generic JSON protocol that could represent all necessary information for a conversational IVR application using VoiceXML. The protocol describes 5 types of input, namely: data (initialization data for example; caller’s phone number or any information the platform is set to return), user input (vocal or using the keypad) recognition/interpretation result, recording (of the user’s voice), transfer details (status, duration, etc.), event (hangup, noinput, nomatch…). Concerning outputs, we only designed support for interaction (the dialogue asks for a user input) and exit/hangup to cover our use cases.

As an example, to ask a question and wait for the answer, the dialogue could send this payload:

And the result sent by the Bridge could be:

… To the IVR Channel

Not a lot was then left for the IVR channel to do. Concerning inputs, each one would need some processing to be made accessible to the dialogue management. Specifically, inputs have to fit into Rasa’s NLU result format (namely, a string following the template: `intent@confidenceScore{“entityType”: entityValue, …}`). With well written grammars, this step’s implementation was rather simple for recognition results, but could have been tricky for input types with no intent nor entities (data, events), for which we still wanted to trigger a dialogue turn. To solve that problem, we could either create synthetic intents and entities representing the information we wanted to pass on, or insert it directly in the tracker and send a semantically empty input. We went for the first option, and created four synthetic intents to date:
start_conversation (with a data entity containing initialization data as a JSON object)
– noinput
– nomatch
– hangup

For the outputs, yet again some formatting was necessary, but since Rasa gives us full liberty on the output content through custom payloads, this was pretty straightforward. The (tiny bit more) delicate work was to concatenate and validate outputs from different parts of the dialogue. Rivr supports playing messages alone (without a recognition or hangup step), and it could be a nice feature for our Rasa dialogues, but would have required a bit more gymnastics in both the channel and the Bridge, so we chose not to implement it for now.

Ok, presenting it like that, maybe the IVR channel had a lot to do even with the use of the Rivr Bridge. But it was still less than generating VoiceXML content would have been. Thanks Rivr! To discover the journey of those user inputs once they enter the Rasa ocean, read the yet-to-come rest of the series!

The post Developing Conversational IVR Using Rasa Part 2: The Rivr Bridge first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Developing Conversational IVR Using Rasa Part 2: The Rivr Bridge appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Since Nu Echo’s foundation in 2002, VoiceXML has been the bread and butter of our IVR application development. We’ve been using it to create many solutions ranging from turnkey address change and identity validation modules to large scale IVR system using a custom JavaScript framework. We even open-sourced a Java VoiceXML development framework named Rivr, check it out!

While it is definitely possible to develop IVR applications in 2019 without using VoiceXML (think Dialogflow or Amazon Lex through Amazon Connect), it is still very prevalent in the large contact centers, which are an important part of our customer base. That’s why we decided to give Rasa a serious spin to find out if it could be a viable solution for developing multilingual conversational IVR applications using VoiceXML.

The use cases

For our proof of concept, we selected some banking use cases (account balance and pay bill) that offer us interesting dialogue patterns like digressions, confirmations, corrections and global commands (cancelling a task for example).

Here is an example that mixes some of those patterns:

Introducing Rasa IVR

Developing VoiceXML IVR applications using Rasa offers interesting challenges. For one, the real-time aspect of a voice conversation that must progress if the user says nothing is quite different from the classic chatbot approach. The application can’t keep the user waiting if he says nothing, it must propose alternate and more detailed messages and eventually terminate the conversation if the user decides to stay silent.

While Rasa offers a lot of prebuilt channels, nothing exists to express the richness of VoiceXML and interpret its different outputs. As you can see from the complexity of its specification, a lot must be done to cover all the functionalities (although some of them are less used than others). Some of the most important ones that must be taken into consideration for developing basic use cases are related to constructing the output (audio files / speech synthesis), activating bargein, specifying grammars / input mode (speech and/or DTMF), and configuring confidence levels / timeouts.

The user experience (UX) must also be tailored for the voice channel since the user cannot scroll up to access the whole conversation (unless he has a supernatural memory). Some patterns like confirmation or choosing in a list are much trickier to properly implement using voice than text and widgets.

Along with those challenges come some interesting opportunities. For example, using automatic speech recognition (ASR) alongside contextual grammars allows us to greatly improve the recognition accuracy by giving a greater weight to the most probable responses. VoiceXML also offers many functionalities for a better integration to the contact center, which must be exposed (agent transfer, attached data, recordings). The synchronous aspect of the conversation also simplifies the implementation since the user can’t frantically send multiple (sometimes contradictory) inputs.

As I said earlier, this post is the first of a series that will cover different aspects of the making of our conversational banking application proof of concept. Stay tuned for more articles from my colleagues on our approach toward generating VoiceXML, dialogue management, cloud deployment and more!

Many thanks to my colleagues Linda Thibault and Guillaume Voisine for their precious advice!

The post Developing Conversational IVR Using Rasa first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Developing Conversational IVR Using Rasa 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.