Intelligently Route Support Requests Using Segment & Twilio

Chances are your support team is dealing with a high volume of support tickets, many of which can be solved by simply sending relevant documentation to the customer. 

It can be time-consuming and inefficient to utilize valuable support team bandwidth for these types of support tickets. Conversely, as a customer, it can be frustrating to open a support ticket only to be sent documentation that they have already reviewed.

What if there was an automated way to understand exactly what documentation a user has looked at prior to opening a support ticket, and customize the support experience based on that data?

In this recipe, you will learn how to leverage your customer data to intelligently determine if a user has looked at documentation prior to raising a support ticket, and use that information to route the support request to a real person, or to an automated chatbot which can send the relevant documentation.

Step 1: Determine criteria for sending a user to a chatbot, or to a real person.

Before we start, we need to identify the criteria for sending a user to a real person, or sending them to a chatbot. Here are some ideas:

1. If a user has not viewed any docs or articles recently, send them to a chatbot. Else send them to a human.

2. If a user or account has a high LTV or VIP status, send them to a human. Else send them to a chatbot.

For this example, let’s choose the first option: If a user has not viewed any docs or articles recently, send them to a chatbot. Else send them to a human.

Step: 2:  Understand your users and their behavior with Segment

Once you decide on your use case, the next step is to understand your users and how they are interacting with your site. 

This is where Segment comes in — by instrumenting Segment’s Analytics library on your website, you can implement event tracking to understand your user behavior.

 For this use case, the instrumentation will be very simple. When you instrument Segment, we will automatically collect information about page views (what docs and articles the user have viewed). You will only need to use an identify call to understand who is the user making the support request. 

For the purpose of this case, we will be identifying customers who open a support request by their phone number. So it is important that we collect the customer’s phone number, and set it as a custom external ID (see this link for more info). 

This will allow us to identify them and retrieve their profile by their phone number at the point they open the support request.

Step 3: Enrich user profiles with Computed Traits/Audiences

When you implement event tracking (step #2), you are collecting information about your users like their name, email, phone number, etc. by sending an Identify call to Segment.

Here’s a sample payload of an identify call with the most common fields removed:

An example identify call payload

We can easily query this information directly from the Profile API (which we’ll get to later), but there are other instances where you may need to understand things about your user that require certain calculations (ex: Most frequent, last seen, etc.). 

Using the Computed Traits feature in Twilio Engage, you can calculate user traits based on events that are happening in real-time. 

Let’s say we want to make the decision to send a user to a chatbot, or to a real person, based on documentation a user has viewed. 

First, we need to create a computed trait. 

1. Go to Engage > Computed Traits feature and click on New Computed Trait.

   

   A computed trait in Twilio Engage

2. Click on Event Counter. Note: Based on the URL structure of your site, the computed trait definition may need to be different than the screenshot below.

   

3. Click Preview, ignore Select Destinations, and save your audience by giving it a name. We will be later using this trait via the Profile API. The name we will use for this flow will be Docs Last 2 Days.

Pro tip: We don’t need to necessarily use Computed Traits, but can also personalize based on Audiences.

Step 4: Generate a token for the profile API.

Segment Personas allows you to query for a user’s traits, audiences, or events via the Profile API. We will be using the Profile API to query for user’s information and send use the result in Twilio Studio to determine whether to send the support ticket to a chatbot, or to a real person.

In order to create an API Access token, go into the Profiles Settings tab in Profiles, choose API access, and click the Generate button:

Step 5: Integrate Segment Profile API into the Twilio Studio Webchat Workflow using a Twilio Function

You’ll need access to Twilio Studio and Flex. Sign up for a free account here.

Once you have access to Twilio Studio, you will want to manage your existing flows. For the purpose of this recipe, we will be editing the pre-created WebChat Worfklow. Add a new HTTP Request Widget. This is the widget we will use to call Segment’s Profile API and use the results to determine to send a user to a chat bot, or send the user to a live support agent. 

• Name the widget profile_api.

• Select Request Method: Get.

• In the request URL, copy the following: https://<Profile API Token>==:''@profiles.segment.com/v1/spaces/<Workspace ID>/collections/users/profiles/phone {{trigger.message.ChannelAttributes.from}}/traits?limit=200

  • The {{trigger.message.ChannelAttributes.from}} will dynamically read the phone number from the incoming message, and pass it into the Profile API request as a variable.

• Lastly, trigger the profile_api widget from an incoming message, like so:

  

Add a new AutoPilot Studio Widget:

• Select the autopilot assistant.

• Note: This recipe does not detail how to create an Autopilot assistant. Please refer to Twilio’s documentation. To continue with the recipe, feel free to create a placeholder or build something simple from a template.

Next, add a new Split Based On… Widget. We will use the response from the Profile API to split our workflow. 

• In the“Variable To Test” section, paste widgets.profile_api.parsed.traits.docs_last_2_days

• docs_last_2_days is the key of the computed trait we created in Step 3.

• This will be the variable we will use to split our workflow.

• Click on the “Transitions” section of this widget. 

  • For “No Condition Matches” select, your autopilot widget.

  • Add a “new condition.” If the value is Greater than 0, then choose the widget to send to flex. 

    

In the above example, we are saying, “If a user has looked at any documentation in the last 2 days, then send them to a real person. If not, we send them to a chatbot where the automated response will likely be to send them a link to the documentation.

• Click back to the profile_api widget. If successful, direct the flow to split_based_on widget. On failure, select the widget to send to flex as the default option.

• Lastly, publish your flow!

When all is said and done, your studio workflow should look something like this:

Test your flow!

• Within the Phone Number section of Twilio Studio, note the phone number that is assigned to your account.

• Send a text message to this phone number to test the workflow.

  • If you have looked at the documentation in the last 2 days (or whatever the criteria of your decided computed trait), you should see an incoming request in your flex console.

  • If you have not looked at any documentation, or do not meet the criteria of your computed trait, you should receive an automated text response from the autopilot bot.

Wrapping Up

Here’s what we’ve done in this recipe:

• Track data customer data, such as documentation browsing history.

• Use this customer data to create traits for your users.

• Leverage Segment Profile API within a Twilio Flex Studio flow which uses these traits to decide whether to send a customer support ticket to a chatbot, or to send it to a real person.

Want to start using real-time customer data to power your live chat? Get in touch with a member of the team or start building today.