This blueprint provides an overview of how to:
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:
Messenger features
Prerequisites
In order to implement the customer service flow outlined below, you need to have:
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:
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*
*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_optins
event 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" } }
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.
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:
We hope this blueprint was useful!