Summer’18: Einstein Bots For the People

Wouldn’t it be fantastic if Service Cloud could automatically handle common customer requests and questions? With the release of Summer ’18, Einstein Bots — harnessing the power of AI — are generally available. Because of their conversational interface, building these bots can be a wholly new experience for Salesforce developers. In this blog post, we’ll investigate the what, why, and how of building Einstein Bots.

Wait, what’s an Einstein Bot?

Einstein Bots are part of Service Cloud. They are designed to augment your human call center agents. The goal of Einstein Bots is to enable your customers to quickly and accurately interact with your company without waiting for a human agent to become available. Bots provide a chat-based interface to customers. That means they can send messages, ask questions and take actions based on defined rules and/or customer input. Bots use the Einstein Platform’s Intent service to interpret customer input. Additionally, bots can present customers with pre-defined options in menus.

Naming things is hard — let’s built a bot

To me, one of the most fascinating things about any technology is the names and words we use to describe it. With Einstein Bots, we’re introducing a few new terms that I want to draw your attention to.

1. Dialogs: Dialogs are a the basic ‘unit’ of conversation between your customers and bots. Dialogs are built from a developer-defined list of Messages, Questions, Actions and Rules.
   1. Messages are used to communicate information to the customer. Everything from static text like ‘Welcome’ to string-interpolated information is done through messages.
   2. Questions enable you to ask for customer input and store that information for later use. You might, for instance, ask a customer what their order number is with a question.
   3. Actions enable you to call Apex code with parameters and store the resulting value for later use.
   4. Finally, Rules act as a conditional engine allowing developers to make runtime decisions based on customer data. You might use a rule to ensure some bit of data has a value before you share it with the customer. You might also use a rule to decide to transition to another dialog based on some existing data.
2. Slots: Slots represent a mechanism to store dynamically created data within the context of a dialog. They act like variables. For example, the customer’s response to a question can be stored in a slot, and you pass data from a Slot as a parameter to an Action. Not only can slots be used to store data, but developers can use familiar merge syntax {!slotName} in messages to interpolate slot data.
3. Entities: Entities define the datatype (i. e. String, Currency, Date etc.) as well as optional selection values. A slot gets assigned to an entity, so that the system knows how to handle the slot in-/output. Think of an Entity as a ‘bucket’ of slots.
4. Intents: Intents are phrases and words that you provide for each dialog. Whenever a customer types a message, the bot framework predicts the customer’s intent using the Einstein Platform’s Intent service. Based on the prediction, the system selects the dialog most likely matching the customer’s input.

Ok, that’s a lot of terms. Putting it all together though, a bot is built from intents that route customer to dialogs via the Einstein Intent service. Dialogs define the conversation flow, and utilize messages, questions, actions and rules to drive customer answers. Rules help ensure data sanity and provide flexibility to dialogs. Dialogs can use the questions to store customer input in slots, actions to call Apex code, and messages to display data from slots. Put together, the system functions to interpret customer requests and quickly provide them information and answers without having to wait for a human agent. So what does this actually look like to the customer? Glad you asked! Below is a quick demo of the bot at work.

Let’s walk through what you’re seeing:

1. The bot welcomes the user with a standard message, which is part of the welcome dialog.
2. The customer enters a question. In this case, “What’s my name?” Based on this question, Einstein predicts the intended dialog is “What’s my name?” and transitions to it.
3. The dialog asks the customer for their name and after they respond, it transitions to the “Say my name” dialog which repeats the customer’s name back.
4. When the customer follows up with the question “What’s the temperature?,” Einstein predicts and routes the user to the “What’s the temperature?” dialog. This dialog prompts them to enter a city and calls an Invocable method. That method returns a random temperature and date, which is then displayed to the user.

Say what?

Populate as many intents as you can, for every dialog

I had the pleasure of working with the Dreamforce ’17 Keynote team on the Developer Keynote. One of the biggest problems I had developing the demo bot wasn’t with the technology or the naming of things. No, I struggled with developing a list of intents. Because these are tied to routing customers to specific dialogs, intents are critically important. The problem, of course, is coming up with a reasonable list of things people might say in relation to a given dialog. The more examples you provide, the more accurate the intent prediction will be. Generating an exhaustive list can be difficult. To overcome this, the demo team would tackle generating intent lists on conference calls. Because we are from different backgrounds and locations, we were able to generate a much larger list of example phrases for each dialog.

Putting it all together

I put together a short video on setting up a demo ‘Hello world’ bot. Watch, and then let’s talk about some of the choices and steps that I used.

For this bot, I chose to create dialogs for “What’s my name?” “Say my name!” and “What’s the temperature?” One dialog can automatically transition to another. In my example, I setup the “What’s my name?” dialog to transition to the “Say my name” dialog as soon as the customer has answered a question. While you can have multiple back-and-forth conversation elements within a single dialog, breaking them out into logical units allows a better re-usage.

Let’s look at the “Say my name!” dialog. Remember, dialogs are chosen based on the predicted customer intent. Because of this, it’s possible a customer is routed to our “Say my name!” dialog before we’ve asked for and saved their name. Rules can help us ensure data exists before we use it. In this case, the rule checks to see if the customerData : customerName slot is not set. If it’s not, we redirect to the “What’s my name?” dialog. Because the “What’s my name?” dialog automatically transitions to the “Say my name!” dialog, if the customer is routed to “Say my name!” first, the rule seamlessly redirects us to gather the name.

After our rule is evaluated, we’re using string interpolation (Your name is: {!customerName?}) to send slot data. In this case, we’re sending the customer’s name in a message. Note: it’s important to use the API name of the slot!

At this point, we have two dialogs: one asking a question and storing the data, the second verifying the data is set and sending that data back to the customer.

Let’s tackle the “Whats the temperature?” dialog. We start off with a question and store the information. We then call an action, which we’ve configured to use our ChatBotTime class:

public with sharing class ChatBotTime {
    
    public class ChatBotTimeAndTempOutput {
        @InvocableVariable(required=true)
        public String city;
        @InvocableVariable(required=true)
        public Decimal temperature;
        @InvocableVariable(required=true)
        public String dateStamp;
    }
    
    public class ChatBotTimeAndTempInput {
        @InvocableVariable(required=true)
        public String city;
    }
    
    @InvocableMethod(label='Get System Time' description='Returns the current system time and temperature for the given cities')
    public static List<ChatBotTimeAndTempOutput> getSystemTimeAndTemp(List<ChatBotTimeAndTempInput> inputs) {
        List<ChatBotTimeAndTempOutput> results = new List<ChatBotTimeAndTempOutput>();
        for(ChatBotTimeAndTempInput i:inputs){
            ChatBotTimeAndTempOutput item = new ChatBotTimeAndTempOutput();
            item.city = i.city;
            item.temperature = Math.floor(Math.random() * (1000 - 100) + 100) / 100;
            item.dateStamp = String.valueOf(dateTime.now());
            results.add(item);
        }
        return results;
    }
}

Because our invocable method accepts a list of ChatBotTimeAndTempInput objects, the Action configuration screen automatically displays the fields we can populate. It knows what fields to show based on the @InvocableVariables listed in our input class.

Similarly, because our invocable method returns a list of objects that have variables marked as invocableVariable, the system knows what output to expect and allows us to map those data points to slots.

So what does this all mean?

As you can see, it’s not hard to build a conversational experience for your customers using Einstein Bots. Declarative configuration, combined with invocable Apex, gives you powerful capabilities to enhance your customer experience. The hardest part is identifying the variety of intents for every dialog. Use crowdsourcing in your company as well as the data in your existing service cases to gather as many examples as possible.

Now what?

I want to encourage you to sign up for a Summer ’18 pre-release org and build a bot for yourself. (Note: You’ll need to setup Live Agent, Omni-Chanel and the Web Snap-ins prior to building a bot.) Experiment with calling Invocable Apex. Ask questions. Play with various slot and entity types. Start a discussion on Chatter to gather intent options for what customers might say to ask “Where’s my order?” Most of all, I want to encourage you to just play with bots. Discover how easy they are to setup and how quickly they can get your customers’ information!

As you build bots, you may want to spend some additional time learning more about the Einstein Platform and the Intent service. The Einstein Intent API Basics module in Trailhead is a great resource for this.

About the author

Kevin Poorman works as a Senior Developer Evangelist at Salesforce. He focuses on Testing, IOT, Mobile, and Integrations on the Lightning Platform. You can pester him on Twitter at @codefriar.