故事

故事教您的Mpower 坐席通过 CXone MpowerAgent Builder 创建的可处理语音或聊天交互的虚拟坐席。如何在互动环境中回复消息联系人在机器人交互中所说的任何内容，无论是问题还是陈述，书面或口头。。当消息的上下文很重要时使用故事。这有助于Mpower 坐席了解如何根据联系人之前发送的消息预测正确的响应。

配置 Mpower 坐席响应的另一种方法是创建 rules。规则适用于每次应答都相同且上下文不重要的消息。当上下文对于了解联系人的需求很重要时，请使用故事。如果上下文不重要，并且联系人的消息始终意味着同一件事，请使用规则。

例如，如果联系人与联络中心的坐席、IVR 或机器人交互的人员。显示“What are your hours”，则Mpower 坐席可能不需要任何上下文，您可以使用规则。但是，如果联系人说“我该怎么做”，则Mpower 坐席需要了解消息的上下文。联系人在对话中前面询问的内容将帮助Mpower 坐席了解如何适当地做出回应，因此您应该使用故事。

Glossary

概念	定义	示例	Mpower 坐席的作用
话语	联系人与联络中心的坐席、IVR 或机器人交互的人员。在交互中说的任何话通过某个渠道与坐席进行的完整对话。例如，交互可以是语音呼叫、电子邮件、聊天或社交媒体对话。。有时称为消息。	“我丢失了密码。” “我的余额是多少？” “你是机器人吗？”	Mpower 坐席使用自然语言理解（NLU）来分析每个联系人话语，以确定其含义或意图。
意图	联系人想要传达或完成的内容。联系人发送的每条消息都有一个意图。	“我丢失了密码”具有“重置密码”的意图。 “你好”有“打招呼”的意思。	Mpower 坐席使用 NLU 该流程扩展了自然语言处理 (NLP)，以根据它所理解的内容做出决定或采取行动。分析联系人的消息以确定意图。一旦它知道这一点，它就可以用自己的消息进行响应。您可以配置希望 Mpower 坐席用于每个目的的响应。
实体	联系人消息中定义的一条信息。	个人或产品名称、电话号码、帐号、位置等。	Mpower 坐席使用 NLU 来标识联系人消息中的实体。实体帮助Mpower 坐席了解联系人消息的含义。
插槽	从联系人的消息中提取并保存以供Mpower 坐席响应中使用的实体。类似于变量。	为联系人姓名创建插槽可让Mpower 坐席在交互期间在响应中使用该姓名，使其更加个性化。	配置为执行此作时，Mpower 坐席会从联系人消息中提取实体并将其保存在插槽中。您可以让Mpower 坐席稍后在对话中使用此信息。
规则	定义对不随上下文改变含义的消息的Mpower 坐席响应。	包含固定响应的单回合交互：您的工作时间是几点？你的地址是什么？对话积木：问候、再见、谢谢和过渡；简单的是/否问题；和致谢。 Mpower 坐席为其中一些请求提供了默认 intent 和规则，包括问候、handover 将联系人从虚拟坐席转移给人工坐席的操作。请求等。常见问题解答侮辱和经典机器人挑战	规则是配置 Mpower 坐席响应目的方式的两种方法之一。规则对于某些类型的意图有用，但不适用于所有意图。
故事	训练Mpower 坐席以根据消息意图和对话上下文处理交互。	在关于忘记密码的交互中，Mpower 坐席会回答“我该怎么做？ “我该怎么做？”。如果交互是关于创建新帐户，则响应会大不相同，即使在这两种情况下，联系人都使用相同的词语和相同的意图 - 获取更多信息。	Stories 是配置 Mpower 坐席响应 intent 的两种方式中的第二种。故事教会Mpower 坐席如何利用对话的上下文来做出适当的回应。
Mpower 坐席作	Mpower 坐席在处理交互时所说或所做的任何事情。	在有关忘记密码的交互中，Mpower 坐席通过发送指向网站上密码重置常见问题解答的链接来做出响应。当联系人表达沮丧时，例如“我不明白！没用啊！！！”时， Mpower 坐席回应说“对不起。您想让我把您转给人工坐席吗？” 当联系人说 Yes 时，Mpower 坐席将发起转移。	Mpower 坐席作是定义希望 Mpower 坐席如何响应每个目的时拥有的选项。它们可使您灵活地配置每个响应，以实现满足联系人需求的结果。

愉快、不愉快和超出范围的路径

在规划故事时，从路径的角度思考会很有帮助：

快乐路径：训练快乐路径的故事描述了联系人与联络中心的坐席、IVR 或机器人交互的人员。并按照您的预期遵循对话流程。联系人始终提供预期信息，并在出现提示时进行回复。在愉快路径中没有什么不寻常的事情发生。
不愉快路径：不愉快路径描述联系人偏离“脚本”并插入意外问题、评论、闲聊或其他中断类型的情况。
超出范围路径：超出范围路径的故事将教Mpower 坐席如何处理联系人请求超出其能力范围的情况。

为您的所有意图设计愉快和不愉快路径的故事非常重要。 Happy paths 确保 Mpower 坐席知道如何完成每个 intent 的工作。不愉快的路径确保Mpower 坐席不会因意外而偏离轨道。有时，您的Mpower 坐席可能无法自信地预测如何响应，并且必须遵循范围外的路径或使用 fallback。但是，通过训练大量不愉快的路径，您可以帮助Mpower 坐席学习让对话重回正轨的方法。

超出范围的路径

超出范围的路径与回退不同。当 Mpower 坐席没有足够的信心继续执行给定的作或 intent 联系人所说/所输入内容背后的含义或目的；联系人想要传达或达成的事情。预测时，将使用 Fallback。当联系人与联络中心的坐席、IVR 或机器人交互的人员。要求Mpower 坐席执行它可以执行但当前未接受培训的作时，范围外路径非常有用。您可以为这些请求创建范围外的 intent以便 Mpower 坐席识别它们。然后，您可以使用 stories 中的 intent 来教它如何响应这些请求。

例如，联系人可能会经常要求你的 Mpower 坐席更新他们的帐户信息，但你尚未将其设置为执行此作。您可以创建 accountUpdates 目的，提供训练示例，并将 Mpower 坐席响应配置为“对不起，我还不知道该怎么做。我可以帮助您完成 [任务] 或将您转接给实时代理来帮助您的帐户。

故事和上下文转换

故事可用于训练Mpower 坐席在对话需要多个轮次时处理上下文切换。以下示例显示了一个对话，其中 contact 与联络中心的坐席、IVR 或机器人交互的人员。改变了主意，并一个接一个地陈述了两个意图：

联系人：您好，我想支付我的发票。

Mpower 坐席：当然，没问题。您的发票号码是多少？

联系人：实际上，我想转帐。

Mpower 坐席：当然，我能做到。您想转入哪个帐户？

联系人：从储蓄帐户转帐 200 美元到支票帐户。

Mpower 坐席：确定。您的转帐已完成。我将 200 美元从您的储蓄帐户转到您的支票帐户。

Mpower 坐席：您现在是否要继续支付发票？

使用不满意的路径，您可以训练Mpower 坐席处理联系人未按预期方式回答的情况。

对于某些类型的上下文转换，规则用于定义 Mpower 坐席的对不受上下文影响的消息的响应。可能更合适。有时，联系人可能会插入一条不相关的消息。如果消息是 Mpower 坐席可以在单轮次中响应的内容，然后返回到上一个目的，则可以使用规则。以下示例对话显示了联系人插入天气问题的对话：

联系人：您好，我想支付我的发票。

Mpower 坐席：当然，没问题。您的发票号码是多少？

联系人：您所在地的天气如何？

Mpower 坐席：外面阳光明媚。

联系人：很幸运！哦，我的发票号码是 123456。

Mpower 坐席：谢谢，您想如何在该发票上付款？

使用规则可轻松处理联系人有关天气的问题。 Mpower 坐席的响应每次都可以相同。

检查点

检查点是一项 bot作您可以将其分配给故事中的Mpower 坐席的响应。它们可使您通过将故事细分为更小的子任务并关联相关部分来简化故事。这在联系人与联络中心的坐席、IVR 或机器人交互的人员。可能会询问多个后续问题之一的情况下非常有用。您可以为对话的每个部分创建较小的故事，而不是根据联系人提出的后续问题为每个场景从头到尾创建整个故事。

您还可以使用不基于联系人消息的检查点。例如，您的公司可能想要向所有客户提供限时特别优惠。您可以将特价消息和作添加到每个Mpower 坐席故事中，然后在优惠到期时从多个故事中删除该部分。更简单的方法是为特别优惠创建一个故事，然后在优惠期间为每个故事添加一个检查点。

如图所示，检查点总是在开始处显示一个带曲线箭头的蓝色小圆。这表明它连接到一个或多个其他故事。即使您在检查点之后添加操作，检查点也都是用来结束故事。

许多联系人一直在向 Classics， Inc Mpower 坐席询问 Classics， Inc. 的情况。帐户，因此 Akela Wolfe 正在向她的Mpower 坐席中添加处理这些问题的意图。联系人会询问一些有关帐户的常见问题。 Akela 决定使用检查点来处理这些问题。

她为 explain_account 意图创建了主要故事：

联系人：您好，什么是 Classics, Inc 帐户？

机器人：您好。 Classics, Inc. 帐户可使您访问从 Classics, Inc. 购买的所有电子书。

她还为三个常见的后续问题创建了故事：

您能告诉我有关帐户福利的更多信息吗？
我如何创建帐户？
我必须付费还是它免费的？

Akela 返回到针对 explain_account 意图的故事。最后，她添加了关联到后续问题的故事的检查点。

故事规划最佳实践

规划故事时请遵循以下最佳实践：

当上下文很重要时使用故事。 如果您的Mpower 坐席需要上下文来了解如何响应，请使用故事。即使对话只涉及您的Mpower 坐席与联系人与联络中心的坐席、IVR 或机器人交互的人员。之间的一次交流，也是如此。例如，如果您有一个lookup_balance意图，但一些联系人想要支票账户的余额，而另一些联系人想要了解储蓄账户，您可以创建一个故事来帮助您的Mpower 坐席学习根据用户指定的账户做出适当的回应。
使用故事帮助您的Mpower 坐席学习进行预测。 仔细选择每个故事的主题。确保它旨在帮助Mpower 坐席学会正确预测以前从未见过的对话的响应。
使故事以真实对话为基础。 请勿编造您认为可能发生的故事。使用真实的交互来创建故事。
设计遵循 愉快针对意图产生正确结果的故事。路径或 不愉快路径针对意图产生错误结果的故事。的故事。 在故事中合并路径可能会导致意图混淆。
使用故事来处理上下文切换。 这有助于您的Mpower 坐席学会在两个对话流之间切换或处理需要多次对话才能响应的中断。如果中断只需要一个回合来响应并且不依赖于上下文，则规则可能更合适。
某些意图需要多个故事。 如果对话可能进行的方式可能有多个变化，则根据联系人的独特情况和需求，为同一意图创建多个故事。
- 请勿在同一故事中包含对话流的变化。这可能会使 Mpower 坐席感到困惑。
- 如果联系人表达消息的方式可能存在变化，或者类似的消息本质上都意味着相同的事情，您可以将它们添加为联系人消息意图的示例。
在愉快和不愉快路径方面思考。每个意图都可以有多个愉快路径和多个不愉快路径。
为您超出范围的意图创建一个故事。 这样，您就可以培训Mpower 坐席了解联系人显示范围外信息的更常见方式。
根据需要在触点之间来回移动，但要小心。 故事和规则不应是完整的对话。当对话中的下一个陈述必然会开始一个新的意图时，此时应停下来创造一个新的故事。
将您的故事细分为逻辑子任务。 创建一个从头到尾包含整个对话的长故事是很诱人的。然而，这实际上会增加您需要的故事数量。将您的故事细分为逻辑子任务。如果您有一些密切相关的子任务，您可以将它们与检查点进行关联。
不要过度使用检查点。 它们可以简化您的训练数据。太多的检查点会让你的故事难以理解，实际上会减慢你的Mpower 坐席训练过程。