Language is complex. A great conversation is even more complicated. Teaching bots to have a human-like conversation is much more than just adding knowledge articles in response to typical questions asked by our customers. For a bot strategy to be successful, our customers must think and feel like they are having a conversation with someone intelligent, someone who can understand the context and meaning of a follow up question.
For a bot strategy to be successful, customers must think and feel like they are having a conversation with someone intelligent.
Think about your behavior when using a bot system on one of your service provider's websites. How long does it take for you to get to the point where you know you are not working with a human? How long does it take for you to realize that you will not get the answer you need? If technical users can discover a non-human interface within just a few questions, non-technical users can also figure it out quickly. What does it take to program a machine to have a human-like conversation? More data? Or is there something more complex involved in building a conversation?
Understanding the Human Element
For those of us who are masters at having a conversation, we have to step back and think about what it takes to have a conversation. For those of us who aren’t…it doesn't take you long to understand why it is so difficult. A conversation involves active listening and speaking. When it is time to respond, the words have to be crafted in a way that creates an understanding on the part of the listener. When conversations are difficult, often, we spend more time thinking about a response before we speak. What should I say? How should I respond? How can I not offend the other person when I tell them how I feel?
In a conversation, when we are actively engaged with others, and there is a pause in the discussion, our first thoughts are that the person was either not listening or did not understand the question. Computers don't need to pause to think in a conversation; they can access a response within seconds. If no answer is available, then a generic reply can be provided—like when Alexa responds with, "Hmmm, I'm sorry I don't know that one." But in real conversation, there are pauses where thinking is happening, and we are interpreting the context of what is being said.
When we are developing human-like characteristics in machines, we have to have a deeper understanding of how to build human-like conversations—where thinking, listening, pausing, rephrasing, and repeating are the norm.
The Anatomy of a Conversation
Think about walking into work in the morning after a long holiday break. You bump into a close co-worker and start a conversation. It usually begins with, "Hey, how was your holiday break?" You and your colleague speak for about 5 minutes exchanging stories of your time over the holiday, and then you say something like, "Do you want to catch up over lunch? I have an early meeting this morning," before you head off to your office.
The anatomy of a conversation includes an opening, threading of information, comments, etc., and a closing. When creating conversations for a computer, it is essential to understand what makes each part of the conversation productive.
Did you know that if you start over in a conversation that the other person loses confidence almost immediately? Think about how this would work in an incident call to an analyst on the phone. The diagnosis of the issue begins, and the analyst starts asking probative questions. At this point, the customer's confidence is high. But what if the initial conversation takes you down a path that doesn't lead to a resolution and you have to start over? At that point, confidence from the customer is lost. They begin thinking, "Doesn't this person know what they are doing?"
These behaviors are built into the way that we interact with others. A smooth conversation that leads to a successful outcome appears to be valuable. If the conversation goes all over the place and doesn't seem to end in a successful outcome, we grow impatient, dissatisfied. These built-in responses in our mindsets make it even more difficult for us to program a machine to be more human-like in its responses.
Bot Technologies
The bot technologies have three critical parts that help us build an effective conversation: the chat interface (where responses are shared back and forth), the knowledge engine (where knowledge articles or responses are stored), and the conversation engine (which understands the context of what is being said).
Did you know that most of the bot chat interfaces have a configuration for a delay? You can set it up to look like it is thinking or typing—an instant response, and we would know it wasn't a human. An acceptable delay 2–5 seconds to type or respond feels more human. Wait too long, however, and the user will think that the person doesn't know what they are doing. If the bot starts over in the conversation, confidence is lost on the part of the customer, and they are likely to abandon the chat conversation. So exactly how should we build a conversation in a bot to be more human-like?
Want to learn more about the role knowledge plays for your bot strategy? Join Julie for her session, Knowledge is Key to Implementing a Successful BOT Strategy, at SupportWorld Live.
Join us!
Examples of Bot Knowledge
A customer calls in and would like to change the background pattern of the desktop on their laptop. The question from the customer is, “How do I change my desktop background?” When programming the bot, we would probably match a knowledge article for this common request. This matching of a known question to a knowledge article is easy to program into a bot just using knowledge articles.
The user’s question could be handled in a variety of different ways. Let’s look at some examples.
EXAMPLE 1: Link to an existing knowledge base article
In this example, we send the customer to the portal, and they could then walk through the step-by-step process for changing the background. Using this method, we are using the bot as an intelligent front end to connecting the customers with the existing knowledge in the knowledge base.
The benefits are that the knowledge articles are stored in one location only and referenced merely from the bot. Linking to a knowledge article prevents duplication of knowledge. It is also the quickest way to program the bot. For each question posed by the customer, a URL is added to the portal’s knowledge base.
But do we know if the customer gets the answer they need and gets the issue resolved? Unless we analyze the self-service site and verify that the customer's issue is resolved, maybe the user Googled the solution. Another disadvantage is that this interaction does not feel like a conversation. It is just a smart search engine.
EXAMPLE 2: Building a response within the bot
The difference with this response is that we just took the knowledge article and embedded it into the bot interface. The advantage here is that the bot appears to be walking the customer through the solution when, in fact, it is just responding to the question with a programmed answer. In the programming, the bot will compare what the customer types into programmed questions and respond with the programmed response.
The customer doesn’t have to type it exactly as “How do I change my desktop background?” The bot will try to match the best questions/response by parsing out the phrase typed in by the customer. Over time, the bot will have many different ways the question can be asked but will offer just the one solution.
The disadvantage here is that we have duplicated knowledge; the knowledge article is not embedded into the bot programming. If the knowledge article changes, it will also have to be modified in the bot programming. Hopefully, as service management tools advance, we will be able to just link to the original article but display the solution into the bot in conversation form. Another disadvantage is what if the customer “interrupts” the bot with another question? The bot may or may not know what to do in response.
EXAMPLE 3: Building a conversation within the bot
In this example, there is a much more complex dialog happening between the user and the bot. The effort to program the bot to have these types of conversations with our customers is substantial but not impossible.
The advantages here are that the customer "feels" like they are working with a human when, in fact, it is still a bot. The disadvantages are that programming a bot to this level of complexity takes careful planning and the right types of knowledge to be successful.
Using the Right Knowledge
The best way to build a conversation is to capture and use conversations to program your bot. The most popular forms of knowledge are chat sessions with live agents, recorded phone calls with customers, social media dialogs (twitter chats), and KCS knowledge (knowledge captured in the customer’s context). Additionally, once you put your bot into training mode, the conversations captured within each customer's visit also become excellent knowledge to use to program the bot.
The more data that you have, the more successful you will be in identifying the volume of responses and possible conversation paths. If you can find 10 different conversations from customers that ask the same question, you are more likely to build a conversation that "feels" like a human responding. It takes more than just one conversation because the knowledge and experience of end-users varies significantly. Keep in mind that while our response or solution is highly predictable with limited variability, our customer’s responses and questions have a high degree of variability and are not as predictable. Also, our customers may have limited technical knowledge may even struggle to know what questions to ask.
Set a Manageable Scope
Another essential variable to building fruitful conversations is the scope of the bot. Technical support has a high degree of variability. Customers can have an issue with many different aspects of computing, and it is difficult to program a bot to handle all those scenarios well. Request management, however, has a much more predictable and manageable scope. Many organizations have already begun efforts to standardize and automate requests as much as possible. Programming a bot to handle a request with a predefined model for managing that request is much easier than troubleshooting an incident where many different variables are possible and probable.
New Skills Required
It used to be that we needed the right balance of technical and soft skills to provide services to our customers. But as technology begins to change the way we work and interact with our customers, the skills of our people also need to advance. Understanding conversations and how to build a human-like interaction within a bot takes advanced analysis and writing skills. Not everyone has experience in writing scripts (like in a movie, book, or TV show). If you have ever watched a TV show with terrible dialog and asked yourself, "Who writes this stuff?" you know what I mean. A dialog is complex, and the anatomy of a conversation is complex. Building a conversation that is believable and real is a combination of philosophy, linguistics, computer science, and sociology.
Ultimately our goal is to not only solve our customer's issues but also satisfy the customer, not frustrate them in the process. To do this requires us to understand the dialog, emotions, and social context. In building a conversation, three things are required: what do we need to say (content), how do we need to express it (semantics), and did we say the right thing (evaluation).
The best way to build conversations is to use staff who have the skills to write scripts using conversational knowledge that is collected and stored in our systems today. It takes time to build useful conversation maps. But the work to create a system with human-like conversations will ensure more effective adoption from end users.
Julie is a dynamic, engaging change agent who brings authenticity, integrity, and passion to practitioners worldwide. Through her books, articles, speaking, consulting, and teaching, her purpose is to spark change in the world with thought-provoking dialog and interaction on topics of authentic leadership, business strategy, knowledge management, organizational culture, and innovation. Julie has a B.S. in computer science from The Ohio State University and an MaED from the University of Phoenix and is currently pursuing her Ph.D. in Management and Organizational Leadership in Information Systems & Technology from the University of Phoenix. She is an ITIL Expert, Certified Help Desk Director, and Certified Governance IT Professional. She is an HDI Business Associate and teaches training and certification classes for service and support professionals. Visit her website, and follow her on Twitter @JulieMohr, YouTube, and LinkedIn.