Hands On: Live Experience Engagement Scenarios

Read a convincing example of creating engagement scenarios to engage your customers at the right time, the right place, and with the right context.

When a customer is on your Live-Experience enabled website or mobile app, they'll see the Live Experience widget pop up. When they tap on the widget, they initiate an engagement that connects them with an associate.

This article assumes you already have some knowledge about engagement scenarios and Live Experience engagement channels and engagement features. See Manage Engagement Scenarios if you need more info.

The features and channels available to your customers and your associates, and how the widget appears, is all controlled by Live Experience engagement scenarios. In fact, as soon as the widget appears on a page, Live Experience already knows (based on context attributes and data points you create and control) which engagement scenario will be used IF the customer taps on the widget to start an engagement. When the page containing the widget loads, Live Experience goes through each engagement scenario, one after another, until it finds the first one whose rules fits your customer's context. If Live Experience goes through all the engagement scenarios without finding one whose rules meet the customer's context, Live Experience hides the widget.

Naturally, your goal is to create one or more engagement scenarios so that you can engage your customers at the right time, the right place and with the right context.

Plan and Determine How Many Engagement Scenarios You Need

The first thing you need to do is plan and determine how many engagement scnearios you need to meet your business needs. Consider your website or mobile apps: on which pages do you want the Live Experience widget to appear, and do you want the behavior to be the same on each page, or different? Consider the kinds of issues your customers might have and determine how best to meet their needs.

For example, you could design a single basic engagement scenario with a very loose rule that almost always applies. You could configure this engagement scenario to start as a basic audio call, but grant your associates the flexibility to upgrade the call to use video or screen sharing so that associates have the tools they need to address a wide range of customer issues.

Or, you could design several engagement scenarios, each one with different features and channels, and use order and rules to intelligently determine which engagement scenario will apply in different contexts (such as the page your customer is on, or the services your customer already uses).

Implement Your Plan

At this point, you should have a pretty good idea of the number of engagement scenarios you need. Creating engagement scenarios is quick and easy, so if your plan changes, that's OK; just create a few more (or fewer) engagement scenarios.

You can either create brand new engagement scenarios, or you can repurpose the default engagement scenarios that come out of the box with Live Experience.

If you are creating new engagement scenarios, you should disable or delete the default ones so that they don't get triggered by accident.

Fine Tuning Engagement Scenarios with Rules

The key to getting the most out of your engagement scenarios is controlling exactly when they apply to any particular engagement. If you're just creating a couple of general categories, say sales, support, and administration, you probably won't need to worry too much about rules; you'll just specify an Application Location. But if your business needs are more advanced you'll find yourself needing more control. That's where engagement scenario rules come in...

When creating an engagement scenario rule, you'll first choose the type of rule set you'd like, either AND or OR, and then you'll add a variety of conditions depending on your requirements. A engagement scenario rule condition consists of the following components:

  • A context Attribute containing the data you'd like to examine.

  • An Operation determining how you'd like to process the attribute's data (either equals or reg exp [regular expression]).

  • A Value that you want to compare to the data contained in the attribute via the Operation.

Live Experience provides some default context attributes. But you have the ability to pass any information you collect in your app or on your website to Live Experience and to capture that as a context attribute. For example, if you allow your customers to log into your site or app, you can communicate whether your customer is logged in to Live Experience. If you have a customer database that ranks your customer by prestige or tier, you can inform Live Experience whether a given customer is a bronze, silver, or gold tier customer. You can then use that information in Live Experience when creating rules for your engagement scenarios.

Custom context attributes and certain default context attributes are NOT automatically populated by Live Experience. You'll have to gather the context you're interest in when you're creating your Live-Experience enabled app or website.

For more information on initializing context variables, depending on your platform, see:

Example: Defining and Configuring an Engagement Scenario Rule

Let's start with a plain English definition of a rule you might want to use in an engagement scenario:

If an engagement request is initiated by a customer from the Support page of our website or mobile app, and the email domain of the customer is example.com, then this engagement scenario should apply.

First, let's analyze the important parts of that statement:

  1. Your definition mentions a specific part of your website or mobile app. In Live Experience, the context attribute Application Location refers to the location in your app or website from which a customer initiates an engagement request. So you will want to add a condition to the rule for your engagement scenario, and you will want it to use the Application Location context attribute, with a value equal to "Support".

  2. Next, you've got and, meaning you want another condition to apply in addition to application location. So you need to set the Rule Type to AND for this engagement scenario.

  3. Finally, you've got email domain. Looking at the list of pre-defined context attributes, you'll see that there's already an Email context attribute defined. Add another condition to your rule that uses the Email context attribute. For the operator, we'll use a regular expression with a value of ^.*@example.com. This regular expression will match any valid email address with an example.com domain. (The ^ refers to the beginning of the string, and .* matches everything after up until @example.com.)

The engagement scenario configuration should look like this.

Choose the Priority of Your Engagement Scenarios

Once you've finished creating your engagement scenarios, you need to determine the order in which Live Experience goes through them when determining which scenario applies to an engagement. The order matters.

You can re-order engagement scenarios by grabbing a scenario by its handle and dropping it where you want it.

When an engagement comes into the Live Experience queue, it'll match the first engagement scenario it encounters that is least specific. What that means is, if you create an engagement scenario with no rules and place it at the top of your list of engagement scenarios, it'll match any incoming engagement, short circuiting any of your other scenarios below it.

For instance, in the following image, we've got an engagement scenario named Least Specific at the top of the list.

The Least Specific engagement scenario, as its name implies, contains no or few conditions on its use.

You'll notice that we've got two other scenarios, Most Specific and Somewhat Specific. As their names imply, they contain conditions that provide additional filtering on incoming engagements, with Most Specific having the greatest number of rule conditions.

If you leave those engagement scenarios in the current order, the Least Specific engagement scenario will match most incoming engagement. Most Specific and Least Specific will seldom be applied. With that in mind, you'll always want to keep your most specific engagement scenarios at the top of the list and continue in descending order of specificity as shown by the arrow.

Understanding and Using Short Codes in Your Engagement Scenarios

It might not be immediately obvious how to use the Short Code feature when planning and determining your needs with respect to engagement scenarios.

But imagine if your company uses other traditional communication tools external to Live Experience for engaging with customers (for example, a 1-800 support telephone number). And it might happen that you need to escalate an external engagement into a Live Experience engagement (because the best way for your associate to solve your customer's issue is with a video or screen sharing engagement).

The short code feature makes the Live Experience widget generate a six-character code when the customer taps on it. The customer can then read out the code to the associate, who enters the code into the Associate Desktop, ensuring that the ensuing engagement is with the customer who just provided him the code.

In short, the short code feature is like a back-door way of connecting a customer with an associate.

What does this mean practically for your planning of engagement scenarios? You'll want to configure your short-code engagement scenario with a specific and narrow rule so that it doesn't get triggered by accident. For example, you could configure a condition that looks for an application location value of "short code", and then you could add a "short code" page to your website or app and add the Live Experience widget to that page. Then, when your associates want to escalate a phone call to a Live Experience engagement, they could tell the customer to go to the "short code" page and tap on the widget.

The Short Code Workflow in Practice

With a short-code engagement scenario in place, here's an example of how to make use of the short code functionality.

  1. A customer calls your 800 support number and is connected with an associate.

  2. The associate determines that it'd be helpful if they could initiate a screen sharing session to help solve the customer's issue.

  3. The associate directs the customer to the application location in your mobile app or website triggers the short-code engagement scenario.

  4. When the customer gets to the page, they see widget. The widget shows a screen sharing icon, as shown in the graphic below.

  5. The customer taps the widget, which then displays a six-character short code.

  6. The customer provides that code to the associate over the phone.

  7. The associate, in the Associate Desktop, starts a meeting (using the Ask them for a short code option) and enters the short code the customer provided them.

  8. You and your customer are now connected in a Live Experience engagement.

Return to the Docs Home Page

Key Solutions and Concepts for Administrators