Developer-Guide to Customer Experience Excellence in Enterprise Bots
If you are just entering into the world of chatbot development, and have successfully built your first bots, this would be a perfect time to sharpen your chatbot development skills from the viewpoints of customer experience and conversational design.
In this blog, we are going to explore the know-hows of fine tuning our creativity of designing and building robust conversational interfaces.
Conversational AI is on the brink of augmenting customer service, sales and marketing functions with enterprise bots.
Studies show that by 2020, around 80% of enterprises will have been using customer service automation by deploying intelligent chatbots to provide their customers base a seamless experience with a smaller workforce.
By now, you must have come across a lot of chatbots on various platforms. Most of the chatbots today are click-based, implying most of the functionalities depend on whether or not user taps the buttons in place.
Some business bots even disable keypad to become intolerant towards “unhappy paths”. This makes the conversational design rigid and give customers a synthetic experience. It also exhibits the limited intelligence of the bots. Befittingly, 9 out 10 CXOs around the world think “Artificial Intelligence” driven bots needs to be smarter before they can be adopted.
The focus today is shifting towards Natural Language Understanding bots. It is appropriately termed as Conversational Agents. These agents provide us with a better platform by bringing chatbots closer to human interactions. This is what businesses all around the globe are looking for.
So, fasten your seatbelts… Let’s dive in!
In this blog, we shall be exploring the following topics —
1. Conversational Design Guide
2. Real-time Typing Suggestions
3. Action Confirmation and Intent Suggestions
4. Human-in-the-Loop Conversational Design
5. Handling “Out of Domain” Utterances
6. Pre and Post Deployment Feedback
1. Conversational Design Guide
As discussed above, we now understand that click-based chatbots have limited functionalities but are tolerant to misleading or out of scope conversations. Hence,
Our primary focus must be to guide the user towards business paths.
As a user gets introduced to a conversational agent, most of the information he/she has about the bot is its name and/or the website it is deployed on.
User is unaware of the tasks that are within the capability-scope of the bot. This leads to overestimation or underestimation of the bot. This is followed by misleading paths right from the start. As a result, bots often breakdown, much to chagrin of its developer, and starts uttering gibberish.
To avoid this mishap, the scope or the capability of the bot must be introduced to the user in its very first response.
Since capabilities are individual tasks, each may be shown as buttons as options for the user to enter each business path directly.
However, if the user does not choose to tap on any button and queries directly, the bot’s NLU must be robust enough to handle them explicitly. This is the first mark of conversational intelligence.
Apart from the conversation starter, we must choose to show buttons wherever the necessity is felt to provide the user with some options to choose from.
For example, if we are expecting approval of user as next input Yes/No buttons can be used. Same holds for cases where we would want the user to shift to a different business path to get his or her task done immediately.
We can advise the users to shift the path and show business path buttons for a convenient and seamless experience.
2. Real-time Typing Suggestions
This method is a technically advanced version of error handling as compared to others.
Whenever a user starts typing, text completion or automatic intent suggestions can be done.
This strategy would reduce the failure rate of your enterprise bot by a significant level. Most of the users do not prefer typing complete sentences for their issues/queries.
Hence, suggestions should be done to the users real-time whenever the sentence, being typed, has a relevancy rate above the threshold set (based on the scope for which enterprise bot is built).
This can be accomplished based on the following approaches:
· Text Completion based
· Quick Reply based
This reduces the users from unwillingly deviating from happy paths.
However, our chatbot must be foolproof when it comes to handling user’s intentions. The whole design and development would be futile if our chatbot is unable to comprehend the user’s intent.
3. Action Confirmation and Intent Suggestions
Each conversational agent has 3 major components: Natural Language Understanding Engine (NLU), Dialogue Manager and Action Scripts.
Dialogue manager is the core of our chatbot. As soon as a user utterance is received by our Dialogue Manager, it hits the NLU server to receive the predicted intent and entities.
After successfully receiving NLU information of the predicted intent with confidence above the NLU threshold, the Dialogue Manager predicts the next action to be taken based on conversation stories or scenarios on which it is trained.
As per the above chatbot architecture, there are 2 primary breakpoints of our chatbot. Although we can efficiently reduce failure cases due to conversation stories, by rigorously testing each and every corner case, the dependency on NLU accuracy can never be ignored.
Any Enterprise would never accept a chatbot if it enters into a business action without the action being the actual motive of the user. One ought to be bumfuzzled if he asks a bot for its name, only to get an erroneous response with his account balance in a beautifully designed response.
To avoid such scenarios, it is good practice (as long as you have sufficient live data) to get confirmation from user before executing “critical” business actions. If the user denies the predicted action, then there should be suggestions displaying next predicted intents (Texts mapped to each intent) as buttons or quick replies.
This approach can be best implemented by defining a “confirmation threshold” for the NLU response.
My balance please.
intent: "ask_fundTransfer" confidence: 0.67
If the predicted intent’s confidence lies within the range of fallback threshold (let’s assume 0.25) and confirmation threshold (let 0.8), we can then wish to go for action confirmation based on further logic.
However, this approach must be employed with great scrutiny, meaning, it is only to be used where its necessity is felt.
4. Human-in-the-loop Conversational Design
We know that Conversational AI is the key to winning customer loyalty in today’s market. But the question to be asked is, whether an Enterprise is willing to risk their customer interactions completely on conversational agents.
Of course NOT!
This is where Human Handoff comes into picture. This means handing over the control of our bot’s responses from Dialogue Manager to a custom Widget for the user to interact with a human agent to resolve its issue.
Once the chat is transferred to a live agent, all the previous conversations and the context of conversation in the current session must be displayed in the widget.
After the user’s issue is resolved by a human agent, the chat should be “marked as done” for our bot to take over the control of conversation again or terminate the session for the user or continue as the scenario demands.
Following are the scenarios where you can expect to handover the chat to a live agent.
- User explicitly wants to chat with a human agent.
- The confidence for NLU prediction is below threshold twice consecutively.
- User agrees to chat with Human when we suggest to do so for some business actions.
This creates a seamless experience for the users of our chatbot. Also, the enterprises would be satisfied that no user would return simply because of the incapabilities or mistakes due to complete dependency on Conversational AI.
This conversational flow also ascertains, to the satisfaction of a business, that no user would return simply because of a mistake that is due to the dependence of the bot on the NLU.
I shall be writing about Human Handoff on a more detailed blog.
5. Bot Handling Out of Domain Utterances
A “complete” chatbot handles all possible paths, in and out of scope of the desired domain.
Even if we guide the users towards business paths using the aforementioned ideas, our chatbot must have the capability to confidently classify when a user utterance is within its handling domains.
Further, if a query is within the domain of the bot’s understanding, the bot must be programmed to understand whether it is provisioned to resolve such queries. This is often subject to business requirements or limitations. Based on this, we can handle every corner case scenario of conversations.
Let’s have a look at few scenarios to understand better.
In this case, the user is asking for a refund. Let’s assume, we have built a bot for just booking flights. In this case, the query is within our domain, but out of our scope of handling.
So, we just inform the user that we understood the concern but currently are not handling such cases, and therefore suggest to transfer to live chat.
Similarly, the handling of utterances which are classified as completely out of domain, can be handled in the following approach.
We simply show the bot’s capabilities whenever the user queries about something not in our domain to be handled. Of course, the bot must remember to be polite :)
This approach shall greatly handle the “bot-bullies” interacting with our enterprise bot, and I assure you, there are plenty.
6. Pre and Post Deployment Feedback
We perfectly know that feedback and suggestions exponentially improve any software being developed. Feedback incorporate a wider lens of the audience that actually puts the software to use.
Hence, there absolutely must be a mechanism to receive these feedback in our conversational agents too.
* Pre Deployment Feedback Mechanism
Once our bot is built, we add users to test it internally. During this phase, we can use a feedback system to store the last few conversations and the logged data in a database whenever a tester reports a bug.
This can be implemented by using an intent named feedback which would trigger an action that can perform the aforementioned task.
However, instead training any NLU for this intent, it must directly bypass the NLU engine, using “/feedback” command.
* Post Deployment Feedback
However, after deployment, we must remove the /feedback command and make our bot ready to accept feedback from users based on the conversational experience.
Again, there are various approaches to this, depending on the business for which bot developed.
One such approach would be to ask the user how satisfied he was with the query-resolution, after a business path comes to an end.
If the user is satisfied, then we proceed with normal flow. If unsatisfied, we may suggest for the correction to be made and store the data for releasing a more appeasing bot in the next iteration.
Conclusion
This article laid down certain criteria on which the CX and conversational robustness of any enterprise bot is based on. Essentially, any chatbot developer must understand the plausible loopholes in his conversational design, and address every corner case to bring robustness into the conversational flows.
Of course, there are various other ideas to implement before making our bot enterprise ready. Conversational AI is the emerging technology where all these magic happens. As the saying goes…
The more a bot is capable of imitating a human, the more ‘intelligent’ it is considered.
Keeping this statement in mind, we must design and develop our conversational agents (be it speech or text).
Hope you enjoyed the article.
Subscribe for my article. Follow our page on Facebook and LinkedIn
