We Still Need Humans

Chat bots are starting to handle some of the queries being asked of businesses. Even though some of these questions might be easily answered via a simple Google search or by looking at the company’s FAQ page, a segment of customers will still reach out via a live chat or the company’s Facebook page. There is a significant opportunity to automate some of the work to answer these customers’ questions.

That said, bots currently cannot always handle questions gracefully. As a relatively new technology, chat bots may be insufficiently tested and yield confusing or inconsistent experiences. A bug in the chat bot itself may create a situation where the bot becomes unresponsive, and a CSR must step in and manually take over a conversation to ensure client satisfaction. As such, a company that automates a workload using chat bot technology typically will not see an immediate reduction in workload. In fact, it is not uncommon that a new set of skills focused on working with the bot itself becomes necessary. As the technology and our understanding of its uses improve, we may get to a point where humans are replaced, but do not expect that to happen immediately. Human CSRs must remain in the loop to intercede as needed.

Chat Bots from a Customer Service Perspective

There are three main classes of chat bots popular in the customer service industry. The type of bot a company builds is directly correlated to the number of cases it thinks a chat bot can handle correctly and to its users’ willingness and savvy to talk to a computer via natural language.

Typical Customer Service System Concepts

A customer service system can be many things. It can be a knowledge base. It can be a ticketing system. It can be a call center system. It can be a messaging system. Among the big players in the space mentioned in the chapter introduction, all include some combination of these functionalities in their products. In fact, because of the rich set of data that these systems obtain from their customers, such as detailed knowledge bases and rich conversation histories, many of these players are developing their own virtual assistant solutions. For instance, an obvious start is to create a virtual assistant that queries a knowledge base for answers to known problems. A ticketing system could very well provide a chat bot that can check on ticket status and perform basic edits on existing tickets.

Customer service systems will generally organize every interaction between a user and the business into an item known as a case. A customer asking the business for help with a password issue, for example, opens a new case in the system. The new item might come into an inbox that all active agents see on their desktops. The case gets assigned to whoever selects the item, or maybe the system automatically assigns the case to a CSR who is available and not handling many cases at the moment. Once the agent is done helping the customer with the issue, the case is closed. The agent may have created a new ticket for the customer, linking the case with the ticket. The CSR system is aware of multiple pieces of data. It knows when an agent is available. It knows how quickly agents typically handle cases. It knows the call center’s operating hours, thus perhaps not allowing any live chats during off-hours.

All this data makes for very rich reporting. These systems will typically provide detailed reports for everything such as total chats, chat engagement, queue waiting times, time to close cases, first response time, and many other interesting data points. Naturally, the CSR team will be evaluated and compensated on these kinds of measures.

As bot developers, we should not expect the CSR team to change its workflow or data reporting structure. In fact, many of these systems provide bot integration points that treat the chat bot as an agent. Every system is slightly different, but they generally follow this paradigm. One of the benefits of this approach is that the system’s reporting capabilities are not broken by introducing a chat bot as a virtual CSR.

Integrating with a customer service system means that we need to write code to initiate and close out cases. Case initiation may happen automatically when a new message arrives from a customer. Case close-out occurs when the chat bot is finished helping the user with their query. The definition of a case will vary. A case may be defined as from the moment that a user asks a question until an answer is presented by the chat bot. Alternatively, a case may be defined as any interactions between the chat bot and user until there is 15 minutes of activity in the conversation.

Integration Approaches

There are multiple approaches to seamlessly integrate chat bots with customer service systems. We will take a look at three options. The level of integration we select is dictated by the support team’s maturity and available tools. We will address this as we explore each type of integration.

On Platform

If you do not have an existing customer service system but are aiming to deploy to a channel that has its own support tools, you are in luck. Facebook pages, for example, allow customers to interact with businesses via Messenger. Pages include many features for page owners, one of them being a sleek inbox (Figure 12-1). As messages from customers arrive, they will appear on the left-side panel. The page body contains the chat history and allows the business to interact with the user.

Suffice it to say that the user interface is a powerful way for page owners to respond to many types of user queries. The challenge, of course, is that if the bot is deployed to channels other than Facebook, an on-platform interface will not support those live chat scenarios.

Product

If a team already has a customer service system with live chat support in place, we will most likely want to develop an integration into the existing system. The process for doing this is highly dependent on the system. One of the most important tasks in this approach is that the bot must be a good citizen to the customer Service system and must not break the experience for the other agents. This means that case opening and resolution rules must be obeyed, and all messages exchanged between the user and bot must be logged. If an agent opens a case that is missing a conversation history, it would prove to be a bad customer experience. You want to witness a frustrated customer? Ask them the same question multiple times.

If we naively begin implementing a human handover flow, we might end up with what’s shown in Figure 12-2. We will use Facebook Messenger as an example. The chat bot communicates with Messenger via the bot connector. In the normal conversation flow, the bot forwards all incoming messages to the customer service system and responds to the user. The bot is also responsible for opening a case if one is not yet open.

When the flow of the conversation necessitates human handover, the chat bot acts as a proxy, sending the user’s messages into the agent chat and forwarding the agent’s responses back to the user. This is illustrated in Figure 12-3. If the case has been solved by the agent, the case must be closed.

This model is not popular. The main reason is that the customer service system is typically connected to an existing social channel, such as Facebook. The connections between the chat bot, Facebook, and the customer service system look more like Figure 12-4.

Social platforms typically do not support having multiple applications listen to a conversation simultaneously. As such, a choice needs to be made around which system owns the connection. Since customer service systems can provide integration above and beyond chat integration and are usually in place before a decision to build a chat bot is made, they end up owning the connection.

In the case of Facebook, we can use something called the Handover Protocol, which allows us to work around the limitation of only one application owning the connection at a time. Using this protocol, we can designate one app as the primary, and any others are secondary. The primary app will always be contacted when a user first starts a conversation with a page. The primary app can then transfer the conversation thread to a secondary app. When an app is not active in a user’s conversation, it is in standby mode. There is a way to ensure that the apps receive the user’s messages when in standby mode by implementing the standby channel. You can find more documentation at https://developers.facebook.com/docs/messenger-platform/handover-protocol . Figure 12-5 shows the setup described.

Unfortunately for us, not every channel supports the multi-application paradigm, and not every customer service system implements the handover protocol. Not to mention, we are assuming a Facebook-only bot. Adding more channels would create further challenges within this approach.

Figure 12-6 illustrates another approach to integrating human handover. Using this approach, the customer service system acts as a proxy for messages intended for the bot until the conversation is transferred to a human. At that point, the chat bot does not see any pieces of the conversation. This setup also means that the Facebook channel connector is out of the loop, so we need to implement a custom translator that receives Messenger format messages, converts them to the Bot Builder SDK format, and forwards the messages into the chat bot using Direct Line, like we did in Chapter 9.

This approach is a lot more common since it is easier to integrate the back end into the customer service system’s ecosystem than share the Facebook page between two systems. This approach is also effective at supporting human handoff on any system that the customer service system supports.

Facebook Messenger Handover Sample

It would be difficult to demonstrate a fully integrated product-based human handover scenario, but if we pretend that Facebook pages are the customer service system in the previous figures, it becomes easier to do so. In this section, we will add human handover integration to the calendar bot that we have been building throughout the book.

The approach that we use will be the following. First, we will create a new intent to handle a customer’s explicit request to speak to a human agent. Next, we will create a dialog to handle the logic to transfer the user. We will designate our bot as the primary app and the inbox as the secondary app. We will demonstrate how to transfer thread control over from our app to the inbox. Lastly, we will show how we can support a customer via the Facebook page inbox and then send control back to the chat bot.

We train and publish the LUIS app. Our chat bot will not be able to receive the intent and do something with it.

The Facebook Handoff Protocol is composed of two main actions: passing thread control and taking thread control. Any time a new conversation begins, the primary app receives the user’s message. The primary app determines when to pass control to a secondary app. The primary app will either know the hard-coded identifier of the secondary app, or it can query the page for a list of secondary apps and select one at runtime. If our page has multiple secondary apps depending on the functional area, the chat bot can figure out the destination of the transfer based on the user’s input. After the secondary app is done, it can pass control back to the primary app.

In the context of Facebook pages, the page’s inbox can be considered a secondary application. From a functional perspective, this means that anyone managing the page inbox should not see a message unless the chat bot has handed it to the inbox. We can set this up in the page’s Messenger Platform settings (Figure 12-7).

Next, we create the dialog responsible for invoking the handover logic. The requests to the Facebook APIs will be to either of these two endpoints, although our demo will only need to contact the pass_thread_control endpoint.

No matter which endpoint we call, we must include the user’s ID and may include some metadata. The pass_thread_control method also requires a target_app_id to be passed to indicate which application the thread is being transferred to. The Facebook documentation states that handing over to the page inbox requires the target_app_id to be the value 263902037430900. The code then to call Facebook endpoints is shown next. We use the request Node.js package to make new HTTP requests.

The code for the dialog quite simply calls the handover method.

Let’s see what this interaction looks like on the Facebook inbox. Before we run the bot, we note that the inbox in the Facebook page is empty (Figure 12-8).

We can exchange a few messages with the calendar bot. Figure 12-9 shows a sample interaction.

Note that the Facebook page inbox remains empty; that is by design. Since the primary app is taking care of the user’s messages, there is no need for the page inbox to get involved. If we expand the hamburger menu on the top left of the interface, we will find that the inbox has multiple folders (Figure 12-10).

Lo and behold, if we click the Done folder, we will find the conversation we just had with the chat bot (Figure 12-11). We could very well type our reply into the response textbox, but that will just confuse the user as both the bot and a human would be responding to the customer since the bot is still in the loop.

Let’s back up into the Inbox folder. We also go back into Messenger as the customer and ask to speak to a human (Figure 12-12).

If you refresh the page inbox, you’ll note that the conversation appears in the inbox (Figure 12-13).

At this point the chat bot does not see any customer messages, and any message sent from the Facebook page inbox appear in the customer’s chat (Figure 12-14).

Now, the next step is to disconnect from the secondary app. If we had two Facebook apps, we would have to either take control back or pass control back to the primary app using the code we wrote. In this instance, the page inbox has the functionality built right in. In the top-right corner of any conversation, we will find a button with green text labeled “Mark as done” (Figure 12-15).

Once the conversation is over, the agent clicks that button, and the conversation is transferred back to the bot. From the Facebook page inbox perspective, the conversation is moved back into the Done folder, and the bot is once again active (Figure 12-16)! From a customer’s perspective, it is completely seamless.

If the user gets into trouble again, he can once again ask for a human agent and resolve an issue.

Conclusion

The focus of our work in this chapter has been seamless human handover. That is a key experience requirement for our customers and agents. The experience provided for both parties should be as frictionless as possible. The chat bot should be a helpful assistant, which will increase the likelihood that the chat bot gains support from both internal and external parties.

Although the sample we demonstrated in this chapter was limited in scope to Facebook, it illustrates the general approach that most chat bot integrations with live chat systems will follow. There are, of course, many details to figure out, and there is no single approach to the problem, but the work we did in this chapter should be sufficient to get our chat bot’s human handoff functionality going in the right direction.