Handling Customer Service In Messenger

This blueprint provides an overview of how to:

  1. Deflect customer service requests from your website to Messenger, and
  2. Offer answers from your existing knowledge in an automated way to reduce the number of tickets opened.

Scope

Not all customer support requests are created equal. While some complex issues require hands-on support by a real person, most requests can be resolved by pointing customers to the right place or source of information. This is why FAQs were born in the first place. In an ideal world, customers find an answer to their issue before they need to open a ticket. Open tickets cost time and money, plus having to manually answer the same questions over and over can be painful.

Bots are a powerful way to automate support for commonly asked questions and reduce the number of opened tickets. This blueprint shows how you can use Messenger to offer answers from your existing knowledge base in an automated and streamlined way. It also shows an example of how to deflect customer support requests from your website to Messenger. Here is where the flow of this blueprint starts and ends:

  • Starting point:
    • User requests customer support on your web customer support page
  • Ending point:
    • Issue resolved: user views knowledge base article in the webview
    • Issue unresolved: user opens a ticket in the webview

What you will need

Messenger features

  • Send to Messenger plugin: this is used to trigger an authentication event to your webhook.
  • Webhook: the Messenger Platform sends events to your webhook to notify your bot when a variety of interactions or events happen, including when a person sends a message.
  • Webview: allows you to open a standard webview, where you can load webpages inside Messenger.
  • List template: a structured message that consists of a list of 2-4 structured items with an optional attached button rendered at the bottom. Each item may contain a thumbnail image, title, subtitle, and one button.
  • Button template: sends a structured message with text and up to three attached buttons.
  • Quick replies: provide a way to present a set of up to 11 buttons in-conversation that contain a title and optional image, and appear prominently above the composer.
  • getContext() (which is part of the Messenger Extensions SDK): this method retrieves additional information about the person and the thread that opened the webview.

Prerequisites

In order to implement the customer service flow outlined below, you need to have:

Architecture Overview

Architecture overview of how to resolve customer support requests using Messenger

Step-by-step

Deflect the user to Messenger to resolve the request in an automated way

STEP 1: User navigates to your web support page to seek support

There are a few ways you can deflect the user to your Messenger bot:

  1. m.me link
  2. Send to Messenger plugin
  3. Message Us plugin
  4. Customer chat plugin

In this Blueprint, we will use the Send to Messenger plugin.

To display the Send to Messenger button on your support page, make sure to implement the FB JS SDK and add the following code snippet. We recommend you also add a prominent call to action that explains the user is opting in to receive messages from you in Messenger.

To get support, find us on Messenger!

<div class="fb-send-to-messenger" 
  messenger_app_id="<APP_ID>" 
  page_id="<PAGE_ID>" 
  data-ref="<PASS_THROUGH_PARAM>" 
  color="<blue | white>" 
  size="<standard | large | x-large>">
</div>
        

STEP 2: User clicks on the Send to Messenger button and thereby opts-in to receive messages from you in Messenger*

Send to Messenger button prompting a redirect to Facebook Messenger

*NOTE: If the user is not logged into her Facebook account or the wrong account is showing, then the user will need to log in on the web.

STEP 3: Inform the user that the conversation will continue in Messenger (client side)

By default, no message will show to users on the client side when the Send to Messenger button is clicked. You need to update your UI to indicate that they’ll be hearing from you in Messenger.

<script>

  FB.Event.subscribe('send_to_messenger', function(e) {
    // callback for events triggered by the plugin
    alert('Thank you! We've contacted you in Messenger to attend to your request.')
  });

</script>
        

STEP 4: Your server receives the customer’s PSID (server side)

By clicking on the Send to Messenger button, the user automatically opt ins for receiving your communications. No other action is required on the user’s part. On the server side, your webhook receives the messaging_optinsevent which gives you the person PSID (sender.id.) You can use that PSID to send a welcome message and ask what the issue is.

{
  "sender":{
    "id":"USER_ID"
  },
  "recipient":{
    "id":"PAGE_ID"
  },
  "timestamp":1234567890,
  "optin":{
    "ref":"PASS_THROUGH_PARAM"
  }
}
        

Collect problem from the user in free text form

STEP 5: Send a welcome message and ask what the issue is in Messenger using the PSID

curl -X POST -H "Content-Type: application/json" -d '{
  "messaging_type": "RESPONSE",
  "recipient": {
    "id": "<PSID>"
  },
  "message": {
    "text": "Welcome to Messenger! What's the issue?"
  }
}' "https://graph.facebook.com/v2.6/me/messages?access_token=<PAGE_ACCESS_TOKEN>"7
        

STEP 6: Your Messenger bot receives the `messages` webhook event and parses the issue description in free text form from `message.text` (server-side)

{
  "sender":{
    "id":"<PSID>"
  },
  "recipient":{
    "id":"<PAGE_ID>"
  },
  "timestamp":1458692752478,
  "message":{
    "mid":"mid.1457764197618:41d102a3e1ae206a38",
    "text":"My screen is broken"
  }
}
        

STEP 7: Bot extracts`message.text` from the webhook event and queries internal knowledge database

Offer knowledge base articles the user can open in the webview

STEP 8:Query matches are presented to the user using the list template

If the database query finds a match, the results are presented back to the user. In this blueprint we present the result in the format of a list template.

For the issue “my screen is broken”, list template items could be: “Find store to repair”; “Send back via mail” etc.

curl -X POST -H "Content-Type: application/json" -d '{
  "recipient":{
    "id":"RECIPIENT_ID"
  }, 
  "message": {
    "attachment": {
      "type": "template",
      "payload": {
        "template_type": "list",
        "top_element_style": "compact",
        "elements": [
          {
            "title": "Title 1",
            "subtitle": "Subtitle 1",
            "image_url": "some_image_url",          
            "buttons": [
              {
                "title": "View",
                "type": "web_url",
                "url": "url_to_knowledge_base",
                "messenger_extensions": true,
                "webview_height_ratio": "tall"
              }
            ]
          },
          {
            "title": "Title 2",
            "subtitle": "Subtitle 2",
            "image_url": "some_image_url",          
            "buttons": [
              {
                "title": "View",
                "type": "web_url",
                "url": "url_to_knowledge_base",
                "messenger_extensions": true,
                "webview_height_ratio": "tall"
              }
            ]
          },
          ...
        ],
         "buttons": [
          {
            "title": "None of these",
            "type": "postback",
            "payload": "NOPE"            
          }
        ]  
      }
    }
  }
}' "https://graph.facebook.com/me/messages?access_token=PAGE_ACCESS_TOKEN"
        

STEP 9: Customer clicks on one of the result options and the article opens up in the webview

If the results contain the solution the user is looking for, the user clicks on the relevant button to open the knowledge base article in the webview.

If none of the results solve the user’s issue, the user clicks on “None of these” the user is redirected to open a ticket.

User opens a ticket and case ID is stored in your ticketing system

STEP 10: You are informed that the request is still unresolved in the messaging_postbacks webhook event

When the user clicks on “None of these”, your webhook handles the postback to signify that the issue isn’t resolved.

STEP 11: You prompt the user to open a ticket in the webview with a button template

Using the button template, you provide the user with the option to open a ticket in the webview. This essentially follows your regular customer support flow except that the user isn’t taken out of Messenger.

curl -X POST -H "Content-Type: application/json" -d '{
  "recipient":{
    "id":"<PSID>"
  },
  "message":{
    "attachment":{
      "type":"template",
      "payload":{
        "template_type":"button",
        "text":"Let's open a ticket",
        "buttons":[
          {
            "type":"web_url",
            "url":"https://www.ticketmaker.com",
            "title":"Open Ticket",
            "messenger_extensions": true,
            "webview_height_ratio": "tall"
          }
        ]
      }
    }
  }
}' "https://graph.facebook.com/v2.6/me/messages?access_token=<PAGE_ACCESS_TOKEN>"
        

STEP 12: User clicks on “Open Ticket” and fills out a form in the webview in Messenger

STEP 13: PSID is retrieved and stored in your system to ensure follow up is possible

Client calls getContext() to retrieve PSID and store it with the ticket in your ticketing system. This ensures follow up in Messenger is possible to send status updates. The conversation ends.

MessengerExtensions.getContext('<YOUR_APP_ID>', 
  function success(thread_context){
    // success
    let psid thread_context.psid;
  },
  function error(err){
    // error
  }
);
        

STEP 14: The webview closes when the user clicks on “submit”

MessengerExtensions.requestCloseBrowser(function success() {
  // webview closed
}, function error(err) {
  // an error occurred
});
        

STEP 15: Prompt the user to opt-in for follow up messages using quick replies

As a best practice, you should ask the user to opt-in to receive follow up messages in the future. Technically the user has opted in already by starting the thread with your bot. Explicitly asking for the user consent ensures a positive customer experience.

In this case, the quick replies options are: “Yes” and “No”

curl -X POST -H "Content-Type: application/json" -d '{
  "recipient":{
    "id":"<PSID>"
  },
  "message":{
    "text": "Want to receive updates in Messenger?",
    "quick_replies":[
      {
        "content_type":"text",
        "title":"Yes",
        "payload":"yes",
        "image_url":"some_image_url"
      },
      {
        "content_type":"text",
        "title":"No",
        "payload":"no",
        "image_url":"some_image_url"
      }
    ]
  }
}' "https://graph.facebook.com/v2.6/me/messages?access_token=<PAGE_ACCESS_TOKEN>"
        

STEP 16: Save the user subscription preference in your ticket record.

Conclusion

This blueprint shows how Messenger features can be combined to streamline and automate a customer support request initiated on your support webpage. We’d like to highlight that:

  • There are many ways to drive users to your Messenger bot beyond the Send to Messenger plugin. You can find all other entry points options here.
  • Quick replies, the webview, and message templates are easy ways to create a rich and intuitive user experience.
  • The Messenger Extensions SDK has other features beyond the getContext() method that help bring Messenger-specific features to any website or web app opened in the webview.

We hope this blueprint was useful!