Route to the last assigned agent

Updated: Jun 09, 2023

This Business Requirements Document outlines the project scope related to the UHC - Intelligent Routing - Routing to Last Agent.

Business goal/user stories
The UHC team would like to implement the logic to route customers to the Last Assigned Agent.

Pop to advocate when they (same advocate) chatted last with the member
GIVEN a member starts a chat with UHG;
WHEN the member is connected to an advocate they chatted with previously;
THEN the advocate (not member) sees a message/pop-up in the agent-workspace or conversation itself indicating when they chatted last with the member, AND the intent chatted about the previous time.
Route to advocates only with positive previous experiences
GIVEN a member starts a new chat with us, more than one advocate is available (below capacity), and the member has chatted with one of the agents in the immediate conversation previous to this one (we're only going to look at the agent that was assigned at the close of the conversation);
WHEN the system assigns the chat to an advocate;
THEN the system will assign the chat to a previously chatted with advocate only if the MCS score was above X (X=50 to start) for the last conversation AND the advocate is skilled for the intent. If there are no advocates with MCS scores above X, then assign the chat without regard for MCS scores.
Product able to adjust MCS scores
GIVEN route to the same advocate is deployed;
WHEN the product wants to adjust the MCS score for routing to a previously chatted with the advocate;
THEN product has the ability to make the change itself.
Route to the same advocate if member chatted with UHG in the last hour
GIVEN a member starts a new chat within 1 hour of closing a previous chat with us;
WHEN the system routes the member to an advocate AND the same advocate they chatted with last time is available (online & below capacity) AND the MCS score was above X (X=50 to start) for the last conversation AND the advocate is skilled for the intent;
THEN the conversation is assigned to the same advocate.
Pop to advocate if member chatted with ANY advocate within the same skill in last hour
GIVEN a member starts a new chat within 1 hour of closing a previous chat with us for the same skill;
WHEN the system routes the member to an advocate;
THEN the advocate (not the member) sees a message/pop-up in the agent workspace or conversation itself indicating the member chatted with another advocate recently about the same intent.
Product able to adjust the time frame for routing to the same advocate
GIVEN route to the same advocate is deployed;
WHEN the product wants to adjust the time frame for routing to a previously chatted with advocate;
THEN product has the ability to make the change itself;

Based on initial requirements, the LivePerson ETS team proposed to implement a custom solution using the existing LivePerson product capabilities with the following steps:

Implement a LivePerson event-based Function to store the last assigned agen in CCSv2
LivePerson Functions may listen to Conversation Cloud events or are directly linked to conversational bots.Functions can be integrated with other LivePerson systems through events enabling the tailoring of the Conversational Cloud to the brand's needs. They are creating flows and functionality that are not available out of the box.
Messaging Conversation End event triggered when the agent/consumer/system closes the conversation.

LivePerson Documentation on event sources.

Using this functionality, the function code will be needed to pull all necessary information about the conversation participants and MCS score from the Messaging Interaction API and store it in the LivePerson Conversation Context Service v2 API.

The Conversation Context Service (CCS) provides contextual memory to power AI experiences within Conversational Cloud. It enables spontaneous, context-aware conversations by being the central place where internal and external services can store and gather conversation context to further the dialog with consumers.
LivePerson Documentation on Conversation Context Service API (v2).

NOTE: Since the Messaging Interaction API is not designed for real-time decisions, such as routing, the Conversation Context Service should be used instead. However, Messaging Interaction API can be used from the "Messaging Conversation End" event-based function since the conversation is already closed.

Also, Conversation Context Service provides control over the time to store the data, using the ttlSeconds property. This functionality can be used to control the time for how long the last assigned advocate should be considered for the routing once the customer returns.

High-level flow diagram:

UHC - Transfer to the Last Assigned Agent (3).png

Implement additional logic to the routing bot for the last assigned agent functionality
Every routing bot should have additional logic to support routing to the last assigned agent. The logic will include the following steps:
Using the native CCS integration in the Conversation Builder, the routing bot should retrieve all necessary information about the customer at the beginning of the flow.
NOTE: Since the customer data will be stored at the consumer level, this solution will support only authenticated customer experience.
NOTE: Leo is to provide SLA for CCSv2
High-level flow diagram:

UHC - Transfer to the Last Assigned Agent (4).png

Implement a custom Agent Workspace Widget to provide context information for Agent
To provide contextual information for the Human Agent, need to develop a custom widget that will present information about recent customer conversations with the same Agent / Skill.

The Agent Workspace Widget SDK is a lightweight, client-side package for communicating with the Conversational Cloud Agent Workspace. The widget can retrieve information about the assigned agent and consumer using this SDK.

LivePerson Documentation on Agent Workspace Widget SDK.The information retried from the conversation using SDK should be used to retrieve contextual data from the Conversation Context Service and present it in a UI-friendly manner for the Assigned Advocate.
High-level flow diagram:

UHC - Transfer to the Last Assigned Agent (5).png

Requirements:
- The solution requires pulling the information about recent customer activity from Messaging History (Interactions) API.
- The solution requires pulling the information about current agent activity from Agent Metrics API -> Agent Status method.
- The solution requires the customer to be Authenticated with LivePerson.
Flow to Store Customer Last Conversation Context:
- The customer starts an authenticated conversation.
- When the conversation is closed by the customer, agent, or system, the LivePerson Controller bot invokes the “Messaging conversation end” event-based function.
- The source code of the function, using the conversation ID from the payload, sends an HTTP request to Messaging Interaction API to retrieve the following properties:
- The source code of the function, using the payload, sends an HTTP request to create a record into the LivePerson Conversation Context Service:
  1. The customer record should be stored in a dedicated namespace.
  2. The customer record should be stored under the Session ID scope.
  3. The customer record should use Consumer ID as a key for the Session ID scope.
  4. The customer record should be stored for a defined period (TTL).
  5. TTL should be configurable from the Function environment variables.
Flow to Retrieve Customer Last Conversation Context:

The customer starts an authenticated conversation.
The Conversation Builder Routing Bot assigns the conversation.
During the flow, the routing bot determines the destination skill.
Before the transfer, the bot sends an HTTP call to the custom namespace to get the last assigned skill for the customer based on the Customer ID.
- If the record exists:
- If the record does NOT exist: