Cross platform transfers

High-Level Requirements

1. Key Technical Requirements:
   • Consistent and seamless customer experience.
   • Support for asynchronous chats from multiple channels (e.g., web or app-based chat, Apple or Google business messaging, etc.).
   • Integration with a third-party messaging platform for business segment carve-out conversations.
     • Technical solution needs to support the transfer of all relevant events between messaging platforms - e.g., typing indicators.
     • Flexibility for different types of content - text, rich content, files, etc.
     • Support for transfer of context and transcript.
     • Flexibility for future additions - e.g., warm transfers, transfers back, group conversations, etc.
     • Authentication information is passed over.

• Out of scope: other messaging modalities (e.g., secure messaging).

1. Genesys transfer use case:
   • UHC Human Agent should be able to transfer the conversation from the LivePerson to the Genesys representative.
   • A conversation transcript from the LivePerson conversation should be available for the Genesys representative.

Sequence diagram provided by UHC team: MVP view of the Genesys transfer solution. Experience is still being defined by the POs, so things are depicted at a high level.

Solution Overview

ETS Cross-platform transfer Solution options:

Based on initial requirements, the LivePerson ETS team provided the following options for the Cross-platform transfer use case:

Option 1 - LivePerson Messaging SDK

An SDK to support interactions with Liveperson's Messaging Platform (UMS).

Liveperson Messaging SDK has replaced Messaging Agent SDK (aka Node Agent SDK) as the recommended method for interacting with UMS from a node.js application (which usually consists of a bot or collection of e2e tests).

LivePerson Documentation

API Reference

• Full access to platform events, including the queue state to accept conversations.

• Works only with Node.js SDK
• Larger implementation effort

The Custom Endpoint feature of Third Party Bots allows brands to provide their REST API as a service of bot responses inside the Conversational Cloud. This is complementary to the LivePerson Functions integration and suited for solutions that are: too complex to be comfortably implemented in a LivePerson function, need to be implemented in a different programming language, or are necessary to be fully controlled by the brand. Possible user cases that can help brands leverage the custom endpoint feature are:

• Brands can provide a REST API service as an orchestration layer between the Conversational Cloud and the AI vendors of their choice that fulfills tasks like context enrichment, data sanitization, or routing.
• Brands can connect their instance of the Conversational Cloud to AI vendors that are not supported out-of-the-box by LivePerson. AI vendors can provide a REST API service to get out-of-the-box support between the Conversational Cloud and their platform.

LivePerson Documentation

• It does not require LivePerson functions usage for message events. Consumer Message (CM) CM sent to Universal Messaging Service (UMS) reaches the Third-Party Bot connector directly.

• Custom Endpoint is only accessible to early adopters.
• Service endpoints methods must be implemented based on LivePerson requirements.
• Limited access to platform events may require additional event-based Functions implementation.

Instead of a vendor, like IBM Watson, for example, LivePerson Functions allows you to write your custom bot and connect it to the Conversational Cloud. To achieve this, we will implement a LivePerson Function.

LivePerson Documentation

• LivePerson Functions source code can implement various ways to proxy requests to 3rd party services. Do not have any specific requirements except the payload format.

• It will require many invocations for the Functions.
• Limited access to platform events may require additional event-based Functions implementation.

When a new conversation request is received on the UHC REST API service, the service retrieves the conversation transcript from the LivePerson Messaging Interactions API and caches it.

• An agent assigns to the conversation.
• WHEN the agent determines the intent
  • THEN the agent selects the destination skill to transfer from the Agent Workspace.
• Note: 3rd party connector to Genesys is configured for the various skills based on the intent.

• Not require the bot automation to determine the intent.
• Less development time.

• An agent should be trained to define an appropriate 3rd party skill.
• May require standard naming convention for the 3rd party skill, including the intent.

• An agent assigns to the conversation.
• WHEN the agent determines the intent.
  • THEN the agent selects the generic Routing bot skill.
• WHEN the routing bot assigns to the conversation.
  • THEN the routing bot determines the intent based on the last customer message.

• It does not require agent training for any 3rd party skills

• Intent recognition is possible only based on the context of the last customer message. If the last customer message does not represent the actual intent (“thanks”, “ok”, etc.), the routing may be failed.

• An agent assigns to the conversation.
• After determining the intent, the agent fills out the Agent survey and transfers the conversation to the routing bot.
• The routing bot assigns to the conversation pulls the Agent survey information from the Messaging interactions API to get the intent.
• THEN bot uses the intent to determine the destination skill

• It does not require agent training for any 3rd party skills

• Intent recognition is possible only based on the context of the last customer message. If the last customer message does not represent the actual intent (“thanks”, “ok”, etc.), the routing may be failed.