Stories

Stories teach your Mpower Agent A virtual agent created with CXone Mpower Agent Builder that can handle voice or chat interactions. 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 Mpower Agent learn how to predict the correct response based on the messages the contact sent previously.

The other method of configuring Mpower Agent 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 The person interacting with an agent, IVR, or bot in your contact center. says "What are your hours," the Mpower Agent probably doesn't need any context and you can use a rule. But if the contact says "How do I do that," the Mpower Agent needs to understand the context of the message. What the contact asked earlier in the conversation will help the Mpower Agent understand how to respond appropriately, so you should use a story.

Glossary

Concept	Definition	Example	What the Mpower Agent Does
Utterance	Anything a contact The person interacting with an agent, IVR, or bot in your contact center. says in an interaction The full conversation with an agent through a channel. For example, an interaction can be a voice call, email, chat, or social media conversation.. Sometimes called a message.	"I lost my password." "What is my balance?" "Are you a bot?"	The Mpower Agent 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 Mpower Agent 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 your Mpower Agent 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 Mpower Agent uses NLU to identify entities in a contact's message. Entities help the Mpower Agent understand what the contact's message means.
Slot	An entity extracted from a contact's message and saved for use in Mpower Agent responses. Similar to a variable.	Creating a slot for contact name lets the Mpower Agent use that name in responses during an interaction, making it more personal.	When configured to do so, the Mpower Agent extracts an entity from a contact message and saves it in a slot. You can have your Mpower Agent use this information later in the conversation.
Rule	Defines Mpower Agent responses 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. Mpower Agents come with default intents and rules for several of these, including greetings, handover The transfer of a contact from a virtual agent to a live agent. requests, and more. FAQs Insults and classic bot challenges	Rules are one of two ways you can configure how your Mpower Agent responds to an intent. Rules are useful for certain kinds of intents, but not all intents.
Story	Trains an Mpower Agent to handle an interaction based on message intent and conversational context.	In an interaction about a forgotten password, the Mpower Agent 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 your Mpower Agent responds to an intent. Stories teach the Mpower Agent how to use the context of the conversation to respond appropriately.
Mpower Agent Action	Anything an Mpower Agent says or does while handling an interaction.	In an interaction about a forgotten password, the Mpower Agent 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 Mpower Agent responds with "I'm sorry. Would you like me to transfer you to a human agent?" When the contact says yes, the Mpower Agent initiates the transfer.	Mpower Agent actions are the options you have when defining how you want your Mpower Agent 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 The person interacting with an agent, IVR, or bot in your contact center. following the conversation flow as you'd expect. The contact always provides the expected information and replies 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 Mpower Agent how to handle scenarios where the contact's requests are outside of what it can do.

It's important to design stories for both happy and unhappy paths for all of your intents. Happy paths ensure the Mpower Agent knows how to get the job done for each intent. Unhappy paths make sure the Mpower Agent isn't thrown off course by the unexpected. There may still be times when your Mpower Agent cannot confidently predict how to respond and must follow an out-of-scope path or use fallback. However, by training plenty of unhappy paths, you can help your Mpower Agent 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 Mpower Agent is not confident enough to proceed with a given action or intent The meaning or purpose behind what a contact says/types; what the contact wants to communicate or accomplish. prediction. Out-of-scope paths are useful when contacts The person interacting with an agent, IVR, or bot in your contact center. ask your Mpower Agent to do things that it could do, but isn't currently trained to do. You can create out-of-scope intents for these requests so the Mpower Agent recognizes them. Then you can use the intents in stories to teach it how to respond to those requests.

For example, contacts might frequently ask your Mpower Agentto update their account information, but you haven't set it up to do that yet. You can create an accountUpdates intent, provide training examples, and configure the Mpower Agent 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 live agent to help with your account."

Stories and Context-Switching

Stories are useful to train the Mpower Agent to handle context-switching when the conversation requires multiple turns. The following example shows a conversation where the contact The person interacting with an agent, IVR, or bot in your contact center. changes their mind and states two intents one after the other:

Contact: Hi, I want to pay my invoice.

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

Contact: Actually, I want to transfer money.

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

Contact: Transfer $200 from savings to checking.

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

Mpower Agent: Would you like to continue paying your invoice now?

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

For certain types of context-switching, rules Used to define an Mpower Agent'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 Mpower Agent 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.

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

Contact: What's the weather where you are?

Mpower Agent: It's sunny outside.

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

Mpower Agent: 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 Mpower Agent's response can be the same every time.

Checkpoints

Checkpoints are a bot action you can assign to an Mpower Agent'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 The person interacting with an agent, IVR, or bot in your contact center. 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 contact 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 Mpower Agent 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 Mpower Agent about Classics, Inc. accounts, so Akela Wolfe is adding a intent to her Mpower Agent 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. If your Mpower Agent needs context to understand how to respond, use a story. This is true even if a conversation only involves one exchange between your Mpower Agent and the contact The person interacting with an agent, IVR, or bot in your contact center.. 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 Mpower Agent learn to respond appropriately based on which account a user specifies.
Use stories to help your Mpower Agent learn to make predictions. Choose the subject of each story carefully. Ensure that it's designed to help the Mpower Agent 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.. Combining paths in a story can lead to intent confusion.
Use stories to handle context-switching. This helps your Mpower Agent 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 Mpower Agent.
- 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 Mpower Agent on the more common ways that contacts present out-of-scope information.
Include back-and-forth between the contact as needed, but carefully. 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 the process of training your Mpower Agent.