Sign in

1x1 Messaging

Updated: 

High-Level Requirements

  • Each member has one specific navigator (who is essentially an agent/advocate).
  • Members have the ability to message with a specific navigator to which they are assigned
  • When a specific member messages, they will be routed to their specific navigator that’s assigned to them.
  • The designation/mapping between member and navigator will happen based of ‘plan type’
  • Each navigator can have hundreds of members assigned to them.
  • If the specific navigator is not available, the conversation should NOT go to any other navigator.
        • if the navigator is not available, the member may want to leave a message
        • Once the navigator gets the member's message and sends a response back, the member should be notified about this (possibly through SMS).
  • How to allow the navigator to proactively reply to a member that was missed - allow to send Outbound messages (SMS) and have the member continue messaging.
  • Outbound message to the consumer that waiting for agent assignment + reply
  • Specific outbound driven by the navigator to a specific member - 
    Need to allow navigators to proactively reach out to members for different needs (i.e. schedule a follow on your diabetes, your prescription expired for insulin, etc..) 
  • Marketing outbound 

Not Relevant

    1. Assumptions
  • Need to leverage backend mapping between members to navigators
  • UHC will provide an API to retrieve the navigator per member
  • What will UHC return? Can UHC hold LP agentId ?
      1. if UHC returns UHC navigator Id, then need to create an additional solution mapping UHC id to LP agentId.
      2. can be mapped/stored through conversation orchestration policies
      3. can be mapped/stored at a separate DB
  1. Solution Overview
    • Member starts authenticated messaging conversation
    • Routing bot connects
    • Routing bot makes an API call to UHC API to retrieve the assigned Navigator based on member Id (retrieved from the JWT)
    • Routing bot executes business logic to check availability and other criteria to make a decision on whether to transfer or do something else.
  2. Leaving a message when agent is not available and allowing agent to reply
    • Conversations will stay in the agent queue until the agent becomes available and receives the conversation  
    • Can configure up to 100 days max of waiting time.
    • Once agent gets assigned to conversation and replies to member, can trigger FaaS function (on agent assign event) to send a proactive message to member
  3. Routing Flow Based on Navigator Availability
  • Logged out/Offline

       Flow:

    • Routing Bot identifies the target Navigator by calling UHC API
    • Routing Bot retrieves the LP Agent ID 
    • Routing Bot checks is Navigator is online
    • If offline,  Bot sends a message to the customer
    • Routing Bot transfers the conversation to the Navigator to wait
    • The conversation stays with Navigator until answered or until skill fallback happens
  • Logged in

Flow:

  1. Routing Bot identifies the target Navigator by the keyword from the customer
  2. Routing Bot retrieves the LP Agent ID (SF/policies/employeeID)
  3. Routing Bot checks is Navigator is online
  4. Routing Bot transfers conversation to the AgentID + skill
  5. The conversation stays with Navigator until answered or until skill fallback happens;
  • Account terminated

Flow:

  1. Routing Bot identifies the target Navigator by the keyword from the customer
  2. Routing Bot retrieves the LP Agent ID 
  3. Routing Bot checks is Navigator is online
  4. Routing Bot transfers conversation to the AgentID + skill
  5. Routing Bot identifies that Navigator record either deleted or disabled (TB checked -  identifies how ?)
  6. Routing Bot transfers conversation to the target fallback skill


  1. Assumptions
    • Can be multiple navigators that handle the same planType
    • PlanType + additional differentiating info are provided in the JWT
    • Navigator is identified based on JWT parameter values (sub, other)
  2. Solution Overview
    • Each navigator will be associated with multiple members who all have the same ‘plan type’.
    • There can be more than one navigator that handles the same plan type, but is assigned to different sets of members
    • In this case, UHC will need to provide additional information to be able to identify which of the navigators, handling certain plan type members, should be identified as the matched one to a specific member.
    • Mappings between relevant SDEs (i.e. customerType + Branch) to agentId will be managed in Dynamic Routing policies.
    • Routing will be done to a specific AgentId + specify the fallback skill

Comment: In order to ‘stick’ conversation to the specific Navigator/agent - each skill that will be used in the current solution, needs to have a “Transfer To Agent” fallback period set to a significant value, ex: X days (100 days max).

Untitled.png

3. Leaving a message when the agent is not available and allowing the agent to reply

    • Conversations will stay in the agent queue until the agent becomes available and receives the conversation 
    • Can configure up to 100 days max of waiting time.
    • Once the agent gets assigned to the conversation and replies to the member, can trigger FaaS function (on agent assign event) to send a proactive message to the member

4. Routing Flow Based on Navigator Availability

  • Logged out/Offline:

       Flow:

    1. Routing Bot identifies the target Navigator (agentId) + skill from Dynamic Routing policy
    2. Routing Bot identifies the Navigator availability by checking if the agent is online (Agent Metrics API)
    3. If offline,  Bot sends a message to the customer
    4. Routing Bot transfers the conversation to the Navigator;
    5. The conversation stays with Navigator until answered or until skill fallback happens
  • Logged in

      Flow:

    1. Routing Bot identifies the target Navigator (agentId) + skill from the policy
    2. Routing Bot transfers the conversation to the Navigator;
    3. The conversation stays with Navigator until answered or until skill fallback happens;
  • Account terminated

      Flow:

    1. Routing Bot identifies the target Navigator (agentId) + skill from the policy
    2. Routing Bot identifies that Navigator record either deleted or disabled (TB checked -  identifies how ?)
    3. Routing Bot transfers conversation to the target fallback skill).


Not relevant


  • Assumptions
    • Can be multiple navigators that handle the same planType
    • Info allowing to determine the assigned Navigator is NOT provided in the JWT
    • Member will text a keyword to ask for their assigned Navigator (i.e ‘JohnSmith123’)
  • Solution Overview
    • Each navigator will be associated with multiple members who all have the same ‘plan type’.
    • There can be more than 1 navigator that handles the same plan type but is assigned to different sets of members
    • Member will need to text a keyword to be able to identify the assigned Navigator

              Example:

              keyword alias  ‘JohnSmith111’   →    agentId 123

             keyword alias  ‘AmandaR222’’      →    agentId 234

  • Keyword Management
    • Option 1: Keywords can be stored in Brand SF
      • Keyword format
              • Can be Base36 encoded employeeID, always unique
              • Can be personal ( i.e. JohnSmith111)
      • Keywords in SF would need to be mapped to LP Agent ID (SF User object)
      • LP needs to query Brand SF API to retrieve LP AgentId
    • Option 2: Keywords can be mapped to LP agentIDs in Conversation Orchestration policies
    • Options 3: Keywords can be stored as part of the User Profile employeeID field
      note: currently there is no API to retrieve LP user by employeeId from Users API
  • Leaving a message when the agent is not available and allowing the agent to reply
    • Conversations will stay in the agent queue until the agent becomes available and receives the conversation 
    • Can configure up to 100 days max of waiting time.
    • Once an agent gets assigned to the conversation and replies to a member, can trigger FaaS function (on agent assign event) to send a proactive message to the member.
  • Routing Flow Based on Navigator Availability
  • Logged out/Offline

      Flow:

    1. Routing Bot identifies the target Navigator by keyword from Member
    2. Routing Bot retrieves the LP Agent ID (SF/policies/employeeID)
    3. Routing Bot checks is Navigator is online
    4. If offline,  Bot sends a message to the customer
    5. Routing Bot transfers the conversation to the Navigator to wait
    6. The conversation stays with Navigator until answered or until skill fallback happens
  • Logged in

    Flow:

    1. Routing Bot identifies the target Navigator by the keyword from the customer
    2. Routing Bot retrieves the LP Agent ID (SF/policies/employeeID)
    3. Routing Bot checks is Navigator is online
    4. Routing Bot transfers conversation to the AgentID + skill
    5. The conversation stays with Navigator until answered or until skill fallback happens;
  • Account terminated

Flow:

  1. Routing Bot identifies the target Navigator by the keyword from the customer
  2. Routing Bot retrieves the LP Agent ID (SF/policies/employeeID)
  3. Routing Bot checks is Navigator is online
  4. Routing Bot transfers conversation to the AgentID + skill
  5. Routing Bot identifies that Navigator record either deleted or disabled (TB checked -  identifies how ?)
  6. Routing Bot transfers conversation to the target fallback skill

Solution Proposal - Outbound Messaging

  • Existing Conversations
      1. Solution Overview
          • Conversations started by Members and waiting for assigned Navigator to become available
          • May take the Navigator time to become available (lunch, out of office, vacation etc..). Members will no longer be signed into web Portal.
          • FaaS function can be created in LP to send Proactive SMS to members  -  The function will be triggered on agent assignment. Mainly meant to notify the Members and to ask them to come back to the web.
          • If a member replies to the SMS, a new conversation will be created. Routing bot will be needed to route the conversation to the correct member (based of the phone number)

LP OOTB Proactive Tool
The LivePerson Proactive Messaging tool 2.0 allows brands to initiate conversations with consumers by sending outbound messages via SMS, WhatsApp, and the In-app Messaging channel. Once the consumer responds, it creates a 2-way conversation within the Conversational Cloud platform.
Navigators will need to manage their own campaign
Flow:
Proactive Web Tool from the quick launch menu

Untitled (1).png

To create a new Proactive campaign

Untitled (2).png

Add recipients by either uploading the list of recipients via a CSV file or typing in the recipient's phone numbers. Maximum number of recipients per campaign allowed in CSV is 10K.

Untitled (3).png
Untitled (4).png

Continue leveraging UHC Navigators UI + LP Proactive API

The API can be integrated into the existing UHC Navigators UI to perform the outbound messages to the customers.
Flow:
Navigators select  members in the existing UHC Navigators UI

Untitled (5).png

By sending the message UHC Navigators UI will trigger LivePerson Proactive Messaging API to send outbound messages.

Note: LP Campaign with template variables needs to be created in advance. API will use a template and replace the variables with customer-related information, such as a Name or personalized message.

https://developers.liveperson.com/proactive-messaging-api.html#api-specifications


© 2024 LivePerson Inc. All rights reserved.  Copyright Privacy Policy Terms of Use