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.
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.
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.
{!slotName}
in messages to interpolate slot data.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:
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.
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.
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.
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.
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.