Routing for Helpful Live Agent Support with Watson Assistant

Overview

Watson Assistant allows users to add third-party service-desk integrations (Zendesk and Salesforce) so that they can connect to a human agent in case Assistant is unable to help them. With these service desk integrations, users can now be routed to the correct human agent. In this blog, we’ll focus on some use cases and along the way, we’ll learn -

• How to customize a dialog skill to incorporate routing
• How to build dialog-based routing tree for complex use-cases
• Best practices for building a dialog-based routing tree

Prerequisites

This blog assumes that the reader has some level of familiarity with Watson Assistant and the integrations it supports.

Some topics the reader should be familiar with:

• How to give your users the service desk experience they deserve
• What Watson Assistant is and can do for your business
• How to set up intents, entities, and dialog for your assistant
• How to use context variables within a dialog skill
• How to integrate Watson Assistant on your website with its web chat UI
• How to integrate Watson Assistant with Zendesk and Salesforce
• How the connect to a human agent response type works in a dialog skill

Important keywords in the context of Watson Assistant that you should be familiar with:

skill, intents, entities, dialog node, child node, context variables, web chat integration, service desk integration, connect to human agent response type

Let’s get started …

Use Case 1.1: Simple Routing

Let’s say you have a Watson Assistant-Web Chat/Service Desk integration embedded in your website. Your website has a billing support page(www.acme.com/billing). You wish that customers talking to Watson Assistant on your billing webpage are somehow routed directly to a billing "human" expert in case Watson Assistant is unable to help them.

Now, users can customize their dialog skill to support this use case.

For every user query about the request for a human agent, we want to filter the requests coming from a billing webpage and port those to a billing expert. Essentially, this is what our routing tree would like -

Let’s set up a skeleton dialog tree that emulates the structure above.

The easiest way of doing this is to set up a parent node that would keep a track of all “connect to human agent” queries and two child nodes, one that would hold additional checks for detecting queries coming from a billing webpage and second for detecting any other type of queries.

Note that, in the dialog tree above,

• I have created an intent called #Track_Connect_To_Human_Agent_Queries which tracks all user queries pertaining to a request for an agent.
• I have a dialog node called Parent Node — Let's Start Routing which has been conditioned on intent #Track_Connect_To_Human_Agent_Queries. This ensures all queries pertaining to a request for an agent would hit this particular dialog node.
• I have added two child nodes to the parent node. The first node will detect all queries coming from a billing webpage and ultimately, forward those to a billing human agent expert. The second node will deal with any other type of queries and ultimately, forward those to a default agent queue. We’ll continue to modify these nodes in the upcoming steps.
• The field Then Assistant Should is set to Skip User Input and evaluate child nodes. This is done to ensure that all child nodes are evaluated and an appropriate response type is returned when a specific routing condition is encountered.

Key Takeaways:

- We used dialog nodes to create a basic structure for our routing tree. The parent node is used as a gatekeeper that checks for all the queries pertaining to a request for an agent. The child nodes are used as additional checks so that appropriate response types are returned.

We will continue to modify the child nodes in the following steps to enhance our routing tree.

Next, let’s figure out how to specify routing parameters pertaining to a particular service desk and an agent queue inside a dialog node. This is needed to make sure that users are escalated to the correct agent.

To to do this, we must start off by adding a connect to agent response type to the billing child node

In the billing child node -

• The field Assistant Responds is set to Connect to human agent response type. The connect to human agent response type allows a user to connect to a human agent within the attached third party service desk integration.
• For a particular service desk integration, one can route customers to a specific agent queue. One can select either Salesforce or Zendesk from the dropdown and populate either a Button ID (for Salesforce) or Department (for Zendesk). This will ensure that the users are routed to the correct agent queue or department.
  As an example, I have selected Salesforce and populated the field Button ID with a billing agent queue ID. This will ensure that all queries hitting this child node would ultimately be escalated to a billing expert inside Salesforce
• Connect to a human agent response type also gives the ability to specify custom messages pertaining to when agents are online vs. offline inside a particular service desk.
• I have specified a custom message “Chat with our billing experts now” within the field Response when agents are online. This message will be rendered inside your web chat-service desk integration when agents are available to chat with your customers.
• Similarly, I have specified a custom message “Sorry all our agents seem to be busy at the moment. You can still reach out to us at help@acme.com.” within the field Response when no agents are online. This message will be rendered inside your web chat-service desk integration when no agents are available to serve customers. This is a nice feature to have as it can potentially be used to let customers know of alternate ways of getting appropriate help.
• Note that, the field Enter Condition is set to blank for now, however, we’ll fill this out in the next step. This will hold a special condition that will allow us to filter queries pertaining to requests coming from a billing webpage.

Are there any features that we can leverage that would tell us that the queries are coming from a billing webpage?

Special Context variables store information about the browser that your customer is using to access the webchat integration. More information about these variables can be found here.

In order to track queries coming from a billing webpage, we can leverage the special context variable page_url. Let’s go ahead and condition our billing child node on page_url.
Note that, special variables relevant to browser-related information sit inside $integrations.chat.browser_info

• I have conditioned the billing child node on $integrations.chat.browser_info.page_url.contains("billing"). The condition checks whether the URL or the path of your website (eg. www.acme.com/billing) where you have embedded the webchat contains the keyword billing. This conditional check will help us filter queries that hit the billing webpage.
• Note that, page_url can be accessed anywhere in the dialog as long as the dialog skill is attached to a webchat integration.

That’s it. The billing child node is now ready to detect any queries coming from a billing webpage as well as port those queries to a billing expert inside the attached service-desk integration.

The child node we created specifies a connect to agent response type for the queries coming from a billing webpage but what about all the other queries that pertain to request for a human agent?

In this case, we want to make sure that customers are routed to an agent sitting in a generic queue.
Therefore, we must define a default child node that must be detected for any other type of queries.

Note that, similar to the billing child node, I’ve added a connect to agent response type to this node as well except

• The dialog node is conditioned on true . This ensures that any queries pertaining to a request for an agent would hit this particular node by default unless child nodes above this node evaluate to true.
• Service Desk Routing is not set. If the routing parameters are not set, then the parameters that were defined at the time of authoring a web chat-service desk integration will be used by default.
  Similar to the billing child node, if you would like to specify specific routing parameters, you can totally do that.

That’s all for Use case 1.1. To summarize, we created a dialog based routing tree that routes user requests coming from a billing webpage to an appropriate billing expert within the attached web chat-service desk integration.

Key Takeaways:

- We learned to define a dialog node with a connect to human agent response type.

- We learned that as a part of connect to agent response type, one can specify routing parameters pertaining to a particular service desk. If a dialog node holds these parameters, then all user queries hitting this node would be routed to the specified agent queue or department within the attached service desk integration. If no routing parameters are specified, then parameters specified at the time of authoring a web chat-service desk integration will be used by default.

- We learned that as a part of connect to agent response type, one can also specify custom messages for when agents are online vs. offline. At the time user requests for an agent, these messages are rendered dynamically within one's web chat-service desk integration.

- We learned that special context variables can be directly referenced inside a dialog node to setup routing rules as long as the dialog skill is attached to a web chat integration.

Use Case 1.2: Simple Routing

You've realized that your billing agents have excessive work load now a days. After some thought, you figured that all your customers using the billing webpage are routed to a billing expert regardless of whether they are chatting about billing or not. You feel bad for your billing agents and wish there was a way to ease their work load. You wish that if you knew the type of conversation the user was having with the assistant just before being escalated to a "human" agent, you would be able to route them in a better way.

Custom context variables can be used to track the type of conversation user is having with the Assistant.

If the user is having a conversation about billing with the assistant just before being escalated to an agent, then it makes sense to modify the dialog node pertaining to a billing-related conversation to include a custom context variable topic

Note that, topic is set to billing. This means that whenever assistant detects a conversation pertaining to billing, it will set topic = "billing"

Now that we have found a way to keep a track of the type of conversation the user is having with the assistant, we need to make sure that we can leverage this to setup appropriate routing rules.

Let’s go back to our billing child node for routing that we defined in use case 1.1. We can modify the condition in our billing child node so that it checks for the topic in addition to the page_url.

Note that,

• The billing child node is conditioned on $integrations.chat.browser_info.page_url.contains("billing") and $topic == "billing" . This ensures that only the queries coming from a billing webpage and those pertaining to a billing-related conversation will be escalated to a billing expert.

That’s all for Use case 1.2. To summarize, we were able to enhance our routing tree by leveraging a custom context variable “topic” that allowed us to keep a track of the type of conversation user is having with the assistant.

Key Takeaways:

- We learned that custom context variables can be leveraged to gather information about the type of conversation user is having with the assistant

Use Case 2: Complex Routing

Your business has expanded. You have multiple support pages on your website now. For example, you have a support page for accounting, billing and technical queries. In addition, you have agents with expertise in not only different kinds of support but also multiple languages. You wish that you could use Watson Assistant to route your website users to appropriate agent queues or departments based on complex routing conditions. Here's what you envision your routing table to look like -

For example, you wish to route a user's request for a human agent to agent group A. if the query is in English, comes from a billing webpage and pertains to a billing conversation. Similarly, you wish to route a user's request for a human agent to agent group B. if the query is in Spanish, comes from a billing webpage and pertains to a billing conversation.

How do we build a complex routing tree (similar to the routing table above) using dialog nodes?

In Simple Routing (Use Case 1), we learned how to create a child node with connect to human agent response type and appropriate routing conditions. We can build on that and create child nodes for each of the rows in the routing table above.

Note that in the image above, we essentially have 7 child nodes for each of the rows A through G.

• The first child node is conditioned on $integrations.chat.browser_info.page_url.contains("billing") and $topic == "billing" and $integrations.chat.browser_info.language == "en-US" and it returns a connect to human agent response type with Service Desk Routing set to department/button ID pertaining to agent group A.
• The second child node is conditioned on $integrations.chat.browser_info.page_url.contains("billing") and $topic == "billing" and $integrations.chat.browser_info.language == "es-MX" and it returns a connect to human agent response type with Service Desk Routing set to department/button ID pertaining to agent group B.
• Similarly, we have other child nodes that map to each of the rows in the routing table.

That’s all for Use case 2. To summarize, we were able to build a complex routing tree using dialog nodes.

Key Takeaways:

- We learned that we would need to add a child node with connect to human agent response type for every agent group we wish to route to.

Let’s wrap it up …

Here are some of the things we learned along the way

1. A simple parent-child structure can be used to create a dialog-based routing tree
2. A parent node can be added as a gate-keeper to check for any incoming queries that relate to request for an agent
3. For every agent department or button ID you wish to route to, you would need a child node returning appropriate connect to human agent response type.
4. Routing parameters can be defined as a part of connect to agent response type in order to route the user to a specific “human” agent expert. Note that, these parameters are optional. In case these are not defined, then the parameters defined at the time of authoring a web chat-service desk integration will be used.
5. Custom messages can be specified for when agents are online vs. offline as a part of connect to agent response type.
6. Context variables can be used to set up routing rules.
7. Special context variables can be referenced directly in a dialog node as long as a webchat integration is tied to the dialog skill.
8. Custom context variables can be set inside a dialog node (to track the type of conversation for example) and later referenced in another dialog node.