Stories

Stories teach your bot A software application that handles customer interactions in place of a live human agent. how to respond to messages Anything a contact says in a bot interaction, whether question or statement, written or spoken. in the context of an interaction. Use stories when the context of the message matters. This helps the bot learn how to predict the correct response based on the messages the contact sent previously.

The other method of configuring bot responses is to create rules. Rules are useful for messages where the response in the same every time and context doesn't matter. When context matters to understand what the contact wants, use a story. If context doesn't matter and the contact's message means the same thing all the time, use a rule.

For example, if the contact says "What are your hours," the bot probably doesn't need any context and you can use a rule. But if the contact says "How do I do that," the bot needs to understand the context of the message. What the contact asked earlier in the conversation will help the bot understand how to respond appropriately, so you should use a story.

Glossary

Concept	Definition	Example	What the Bot Does
Utterance	Anything a contact says in an interaction. Sometimes called a message.	"I lost my password." "What is my balance?" "Are you a bot?"	The bot uses Natural Language Understanding (NLU) to analyze each contact utterance to determine its meaning, or intent.
Intent	What the contact wants to communicate or accomplish. Every message the contact sends has an intent.	"I lost my password" has the intent of "reset password". "Hello" has the intent of "greeting".	The bot analyzes a contact's message using NLU This process expands on Natural Language Processing (NLP) to make decisions or take action based on what it understands. to determine the intent. Once it knows that, it can respond with a message of its own. You configure the response you want the bot to use for each intent.
Entity	A defined piece of information in a contact's message.	Person or product name, phone number, account number, location, and so on.	The bot uses NLU to identify entities in a contact's message. Entities help the bot understand what the contact's message means.
Slot	An entity extracted from a contact's message and saved for use in bot responses. Similar to a variable.	Creating a slot for contact name lets the bot use that name in responses during an interaction, making it more personal.	When configured to do so, the bot extracts an entity from a contact message and saves it in a slot. You can have the bot use this information later in the conversation.
Rule	Defines a bot's response to messages that don't change meaning with context.	Single-turn interactions with fixed responses: What are your hours? What is your address? Conversation building blocks: Greetings, good-byes, thank yous and transitions; simple yes/no questions; and acknowledgments. CXone Bot Builder comes with default intents and rules for several of these, including greetings, handover Any contact message that should trigger transfer to a live agent requests, and more. FAQs Insults and classic bot challenges	Rules are one of two ways you can configure how the bot responds to an intent. Rules are useful for certain kinds of intents, but not all intents.
Story	Trains a bot to handle an interaction based on message intent and conversational context.	In an interaction about a forgotten password, the bot would respond to, "How do I do that?" in one way. If the interaction were about creating a new account, the response would be quite different even though in both cases the contact is using the same words with the same intent – to get more information.	Stories are the second of two ways you can configure how the bot responds to an intent. Stories teach the bot how to use the context of the conversation to respond appropriately.
Bot Action	Anything a bot says or does while handling an interaction.	In an interaction about a forgotten password, the bot responds by sending the link to the password reset FAQ on the website. When a contact expresses frustration, such as "I don't understand! It's not working!!!" the bot responds with "I'm sorry. Would you like me to transfer you to a human agent?" When the contact says yes, the bot initiates the transfer.	Actions are the options you have when defining how you want the bot to respond to each intent. They give you the flexibility to configure each response to achieve the outcome that meets the contact's needs.

Happy, Unhappy, and Out-of-Scope Paths

When planning stories, it's helpful to think in terms of paths:

Happy path: Stories that train the happy path describe the contact following the conversation flow as you'd expect. The contact always provides the expected information and reply when prompted. Nothing unusual occurs in the happy path.
Unhappy path: Unhappy paths describe situations where the contact deviates from the "script" and interjects unexpected questions, comments, chit-chat, or other types of interruption.
Out-of-Scope path: Stories for your out-of-scope paths teach your bot how to handle scenarios where the contact's requests are outside of what your bot can do.

It's important to design stories for both happy and unhappy paths for all of your intents. Happy paths ensure the bot knows how to get the job done for each intent. Unhappy paths make sure the bot isn't thrown off course by the unexpected. There may still be times when the bot cannot confidently predict how to respond and must follow an out-of-scope path. However, by training plenty of unhappy paths, you can help the bot learn ways to get the conversation back on track.

Out-of-Scope Paths

Out-of-scope paths are different from fallback. Fallback is used when the bot is not confident enough to proceed with a given action or intent. Out-of-scope paths are useful when contacts ask your bot to do things that it's not trained to do. You can create out-of-scope intents for these requests so the bot recognizes them. Then you can use the intents in stories to teach the bot how to respond to those requests.

For example, contacts might frequently ask your bot to update their account information, but your bot hasn't been set up to do that yet. You can create an accountUpdates intent, provide training examples, and configure the bot response to say "I'm sorry, I don't know how to do that yet. I can help you with [tasks] or transfer you to a human agent to help with your account."

Stories and Context-Switching

Stories are useful to train the bot to handle context-switching when the conversation requires multiple turns. The following example shows a conversation where the contact changes their mind and states two intents one after the other:

Contact: Hi, I want to pay my invoice.

Bot: Sure, no problem. What is your invoice number?

Contact: Actually, I want to transfer money.

Bot: Sure, I can do that. What account do you want to transfer to?

Contact: Transfer $200 from savings to checking.

Bot: OK. Your transfer is finished. I moved $200 from your savings account to your checking account.

Bot: Would you like to continue paying your invoice now?

Using unhappy paths, you can train your bot to handle situations where the contact doesn't answer in the expected way.

For certain types of context-switching, rules Used to define bot's response to messages that don't change with context. may be more appropriate. Sometimes a contact may interject a single, unrelated message. If the message is something the bot can respond to in a single turn, then return to the previous intent, you can use a rule. The following example conversation shows a conversation where the contact interjects with a question about the weather:

Contact: Hi, I want to pay my invoice.

Bot: Sure, no problem. What is your invoice number?

Contact: What's the weather where you are?

Bot: It's sunny outside.

Contact: Lucky! Oh, and my invoice is number 123456.

Bot: Thanks, how do you want to make your payment on that invoice?

The contact's question about the weather is easy to handle using a rule. The bot's response can be the same every time.

Checkpoints

Checkpoints are a bot action you can assign to a bot's responses in a story. They allow you to simplify stories by breaking them into smaller subtasks and linking the relevant parts. This is helpful in situations where a contact might ask one of several follow-up questions. Instead of creating an entire story from start to finish for each scenario based on the follow-up question the contact asks, you can create smaller stories for each part of the conversation.

You can also use checkpoints that are not based on customer messages. For example, your company might want to extend a special offer to all customers for a limited time. You could add the special offer messages and actions to each of your bot stories, and then remove that section from multiple stories when the offer expires. A simpler method would be to create a story just for the special offer, and then add a checkpoint to each story for the duration of the offer.

As shown in the image, a checkpoint always displays a small blue circle with a curved arrow at the beginning. This shows that it connects to one or more other stories. Checkpoints always end the story, even if you add actions after the checkpoint.

Many contacts have been asking the Classics, Inc bot about Classics, Inc. accounts, so Akela Wolfe is adding a intent to her bot to handle these questions. There are several common questions contacts ask about the accounts. Akela decides to use checkpoints to handle these.

She creates the main story for the explain_account intent:

Contact: Hi, what is a Classics, Inc account?

Bot: Hello. A Classics, Inc. account allows you to access all of the e-books you've purchased from Classics, Inc.

She also creates stories for the three common follow-up questions:

Can you tell me more about the account benefits?
How do I create an account?
Do I have to pay or is it free?

Akela goes back to the story for the explain_account intent. At the end of it, she adds checkpoints that link to the stories for the follow-up questions.

Story Planning Best Practices

Follow these best practices when planning your stories:

Use stories when context is important. Even if a conversation only involves one exchange between the bot and the contact, if the bot needs context to understand how to respond, use a story. For example, if you have a lookup_balance intent, but some contacts want the balance of a checking account and others want to know about a savings account, you could create a story to help your bot learn to respond appropriately based on which account a user specifies.
Use stories to help your bot learn to make predictions. Choose the subject of each story carefully. Ensure that it's designed to help the bot learn to correctly predict responses for conversations it hasn't seen before.
Base stories on real-world conversations. Don't make up stories that you think might happen. Use real interactions to create them instead.
Design stories that follow either a happy Story that produces the correct outcome for the intent path or an unhappy path Story that produces a wrong outcome for the intent.
Use stories to handle context-switching. This helps your bot learn to switch between two conversation flows or handle interruptions that take more than one conversation turn to respond to. If an interruption only takes a single turn to respond to and doesn't depend on context, a rule may be more appropriate.
Some intents need multiple stories. Create multiple stories for the same intent if there are variations of how the conversation might go, based on the contact's unique situation and needs.
- Don't include variations of the conversation flow in the same story. This could confuse the bot.
- If there are variations to the way a contact might phrase a message, or similar messages that all mean essentially the same thing, you can add them as examples of the intent for a contact message.
Think in terms of happy and unhappy paths. Each intent can have more than one happy path and more than one unhappy path.
Create a story for your out-of-scope intent. This allows you to train your bot on the more common ways that contacts present out-of-scope information.
Include back-and-forth between the contact as needed. Stories and rules should not be complete conversations. When the next statement in the conversation would necessarily start a new intent, it's time to stop and create a new story.
Break your stories into logical subtasks. It's tempting to create one long story that encompasses the entire conversation from start to finish. However, this can actually increase the number of stories you need. Instead, break your stories into logical subtasks. If you have some subtasks that are very closely related, you can link them with checkpoints.
Do not overuse checkpoints. They can simplify your training data. Too many checkpoints make your stories hard to understand and actually slow down your bot's training.