Overview

The following documentation outlines the configuration for the connector and how to implement functions specifically for Google Dialogflow Version 2.

Bot Configuration

See the Getting Started guide first.

Outlined below is a sample bot config object that is used to log the bot into LiveEngage as well as pass through any info required for each bot vendor.

The following information should be provided to LivePerson.

Item Description
AccountID LiveEngage Account ID
Username LiveEngage BOT Username
Type Using "Chat" or “Messaging”
vendor Name of the AI engine. “DialogFlowV2”
BotAuth Authentication info for Dialogflow V2:
1. private_key
2. client_email
3. project_id
operatingHours (messaging only) On/Off
Start time
End time
offHoursMessage (messaging only) message to display to customers when it is off hours
transferSkill Default transfer skill name
transferMessage Default transfer message

NOTE: Dialogflow V2 adheres to Google’s oAuth2 unlike the V1 implementation. Some degree of familiarity with Google IAM policies and IAM console is necessary for setting up a valid Dialogflow V2 client with Read Only API access. A service account is a prerequisite for setting up the above config. Documentation available here.

The expected output of a service account setup is a JSON file, example below:

Format of JSON file containing credentials

{
    "type": "service_account",
    "project_id": "[PROJECT-ID]",
    "private_key_id": "[KEY-ID]"
    "private_key": "-----BEGIN PRIVATE KEY-----\n[PRIVATE-KEY]\n-----END PRIVATE KEY-----\n",
    "client_email": "[SERVICE-ACCOUNT-EMAIL]",
    "client_id": "[CLIENT-ID]",
    "auth_uri": "https://accounts.google.com/o/oauth2/auth",
    "token_uri": "https://accounts.google.com/o/oauth2/token",
    "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
    "Client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/[SERVICE-ACCOUNT-EMAIL]"
}

Figure 1.1

The Bot-platform connector uses the below fields from the JSON content above.

  • Client Email

  • Private Key

  • Project ID

NOTE: The config wizard expects each of the pieces of auth data to be copied from the JSON file, without quotes. For the private_key especially, do not modify the string, do not remove any of the newline characters. Just copy and paste directly.

Limitations

Dialogflow Query length Limit

The Dialogflow V2 service has a limitation on the length of the ‘query’ object. Any query longer than 255 characters will invoke a custom event in DialogFlow. To handle this gracefully, we recommend building a simple intent that handles a ‘DIALOGFLOW_CHAR_LIMIT’ event.

  1. Create an intent with an event using the string: DIALOGFLOW_CHAR_LIMIT

    fig.2.1

  2. Do not forget to add a custom response in the Text response section.

    fig.2.2

Welcome Event

The behaviour of the welcome event is different depending on whether the bot is for chat and messaging. This divergence comes down to the way that each individual Liveperson product works..

A Messaging conversation qualifies as "initiated" from a LiveEngage perspective only after the consumer sends their first message. The consumer is prompted for their initial message in the channel they have chosen to initiate the conversation. As a result, the consumer’s first message is something that can be parsed by Dialogflow V2 and an intent determined.

The below documents cover where to configure the initial message on a given platform.

Platform Docs Attribute
iOS https://developers.liveperson.com/consumer-experience-ios-sdk-localizationkeys.html hiMessage
Android https://developers.liveperson.com/android-modifying-string.html#resultOverlayRecordTemplate lp_first_message
Web N/A Default LP Message
Other N/A N/A

A Chat conversation is considered started when the chat is routed to an agent. Best practice is for the agent to provide the first response. In this scenario, there is no text from the consumer to parse, thus the default ‘WELCOME’ event is utilised as a start point for the bot to prompt the user to provide input and progress the conversation.

Ensure you have an ‘entry point’ intent that utilises the default ‘WELCOME’ event.

Fig 1.1

Change Time To Response of Conversation

Change the TTR of a conversation based on the action value in the response object.

LivePerson Messaging uses 4 different types of priorities: "URGENT", “NORMAL” “PRIORITIZED” “CUSTOM”

Only the “CUSTOM” can set a value. The unit of the value is second. And the value of the others are defined in the Agent Workspace.

Fig 3.1

Transfer / Escalations

If the bot needs to transfer the conversation to a human agent, or the conversation flow indicates that another bot is better suited for the identified intent, you will need to tell the connector to transfer the conversation to a given skill.

This is achieved using the built in "Actions and Parameters" section of the Dialogflow console.

NOTE: This implementation branches from the V1 implementation and contains substantial changes.

Multiple scenarios for transfer/escalations exist triggered by the transfer action object.

  1. Explicit request from visitor to transfer to an agent (Eg, action : transfer)

  2. If the Bot does not have an appropriate answer, it should recognise this as a scenario for a transfer. Depending on the connector configuration or the decision making capacity of the bot, the bot will transfer to a particular skill or default skill.

  3. If there is a internal error or the bot service cannot be reached the connector will transfer to a default skill set up during configuration.

Transfers and escalations rely on the action item in the response object.

Action: TRANSFER (Case sensitive)

Parameters: ‘skill’ (Case sensitive) with ‘value’ of skill name (case sensitive) in LiveEngage.

fig.4.1

Send Rich Content (Structured Content)

Structured content/Rich Content is supported by the core LivePerson platform. Documentation for the feature can be found here.

To send structured content via Dialogflow V2, send a custom payload option via an intent.

This should contain valid structured content, along with any optional metadata required for the structured content (as seen in Figure 5.1). Always validate your structured content using this tool before entering into the Dialogflow console.

NOTE: Caution when creating a custom payload. Delete the existing text response before saving the intent. If not LiveEngage will receive a blank text response followed by rich content payload.

fig.5.1

Example Metadata

{
   "metadata": {      //Mandatory
      "type": "ExternalId",    //Mandatory
      "id": "ABCD1234"      //Mandatory
   },
   "structuredContent": {     //Mandatory
      "type": "vertical",
      "elements": [
         {
            "type": "image",
            "url": "https://i.ytimg.com/vi/zmeByDJ02mQ/hqdefault.jpg",
            "tooltip": "image tooltip"
         },
         {
            "type": "text",
            "text": "product name (Title)",
            "tooltip": "product name (Title)"
         },
         {
            "type": "text",
            "text": "product category (type)",
            "tooltip": "product category (type)"
         },
         {
            "type": "text",
            "text": "$155.99",
            "tooltip": "$155.99"
         }
      ]
   }
}

Figure 5.2 Dialogflow Example Custom Payload

Close Chat/Conversation

In the bot’s flow, there will be times when it is appropriate to end the conversation without escalating to a live agent. If a query has been answered, or the brand has determined that no escalation is required for a given query, then it is best practice to have the bot end the conversation.

The method for closing a conversation is similar to the transfer action in that the same "Actions and Parameters" field is utilised in the Dialogflow console.

The action field needs to be set to CLOSE_CONVERSATION to instruct the connector to to close the conversation.

fig.6.1