Use case

When an automated conversation with a consumer begins, you want the bot to check whether the consumer has messaged with the bot recently. More specifically, you want it to check whether a conversation occurred within the last 48 hours that resulted in a transfer to a human agent. In this case, you want the returning consumer to be transferred immediately back to the same skill. Your goal is good continuity of care.

Products involved

Workflow

Step 1: In the bot, save the transfer time and skill to the CCS

Before completing this step, verify the Conversation Context Service is turned on in Bot Accounts. Also, note that, when you save data to the CCS, the namespace is created automatically if it doesn’t exist already.

In the bot’s flow, when the conversation is transferred from the bot to the agent, create a namespace in the CCS and save some necessary info:

  • Save a key/value pair for the time that the consumer was transferred. It’s important to set this data in User scope, so it’s available in all conversations for the same user. You can get the time in JavaScript using Date.now(). This returns the current time in a format called Epoch. Epoch is the amount of milliseconds that has passed since January 1, 1970 00:00.
  • Save a key/value pair for the ID of the skill to which the consumer was transferred. Here again, it’s important to set this data in User scope.

Learn about managing the Conversation Context Service.

Code example
var skillId = botContext.getBotVariable(“skillId”);
var time = Date.now();

botContext.registerContextNamespace(“returningUser”);
botContext.setContextDataForUser(“returningUser”,“skillId”, skillId);
botContext.setContextDataForUser(“returningUser”,”escalationTime”, “time”);

Step 2: In the bot, check the returning user namespace wherever conversations can start

  1. Identify the points in the bot’s flow where a consumer can start a conversation.

    If the bot uses Natural Language Understanding to determine the consumer’s intent, multiple places might serve as starting points. In this case, all of these places must perform the same check (step 2).

  2. At the entry points, call the returning user namespace. If it doesn’t exist, this means the bot has never transferred the consumer to an agent in this channel.
  3. If the namespace does exist, get the current time using Date.now().
  4. Subtract the time saved in the namespace from the time you have now. This is the amount of time that has passed since the most recent transfer. It’s in milliseconds, so convert it to hours.
  5. If the time that has passed is less than 48 hours, get the skill ID from the namespace too, and then transfer the consumer back to the skill. Also overwrite the old time of transfer that’s in the namespace with this new time of transfer.
Code example
var currentTime = Date.now();
var oldTime = botContext.getContextDataForUser(“returningUser”, “escalationTime”);

var timeDiff = currentTime - oldTime;
var hoursDiff = timeDiff / 3600000;
if (hoursDiff < 48) // Now transfer to skill or flow. If a skill is being transferred to, then pull the skill ID the same way we pulled the time.

Important considerations

With a Returning Consumer flow, the major consideration to think about is time. If you choose the time of transfer as the “start time,” you must also make sure your solution accounts for the time spent waiting for and speaking to the agent.

For example, assume you want to implement this solution but only identify consumers as returning if their prior and current conversations happen within two hours of each other. An example flow might go like this:

  • 4:00 p.m. Time of transfer from bot to agent (“start time”)
  • 4:30 p.m. Consumer starts conversing with agent
  • 5:00 p.m. Consumer finishes conversing with agent
  • 6:00 p.m. If your solution doesn’t account for the wait and engagement timeframes, this is the end of the window for considering the consumer as returning.
  • 6:01 p.m. Consumer is no longer considered as returning. But in reality, only one hour has passed since the last conversation ended.

Variations on this flow

Flows designed for returning consumers can be very simple, as is this use case, or much more complex. For example, you might use LivePerson Functions to create a function that triggers on conversation close so that the agent can set the time. Or, you might implement a much more complex bot flow to use when the consumer has returned.

Whether simple or complex, all Returning Consumer solutions share these characteristics:

  • The Conversation Context Service is used to store the necessary data.
  • You need to use two specific points in time (“then” and “now”) to be able to identify the consumer as “returning.”
  • You need to decide what to do with the consumer if they’ve returned within the timeframe that you’ve chosen.