聊天机器人几乎从不孤立生存。公司和品牌已经投入了大量的时间、精力和金钱，通过 Twitter、脸书、Instagram、Snapchat 等社交媒体与客户互动。社交媒体公司之间正在进行竞争，为企业提供与客户互动的最佳平台。这些平台中的每一个都希望连接其用户，以促进平台的使用和销售产品。此外，来自 Zendesk、LiveChat、FreshDesk 和 ServiceNow 的客户服务系统，以及 Oracle Service Cloud、Remedy 和 Salesforce Service Cloud 等科技巨头，正在构建将消费者与品牌的客户服务代表(CSR)通过短信、Messenger 和实时聊天等各种通道联系起来的系统。
如今，聊天机器人承担的工作负载可以通过自动化获得很大收益。然而，正如本书所讨论的，聊天机器人的功能有很多限制。在目前的状态下，这项技术无法处理一些人类客户服务代表可以轻松解决的请求。尽管在不同的客户服务系统、团队培训和报告上投入了大量的投资，但是将人排除在与产品用户的对话之外是短视的。在这一章中，我们将介绍客户服务系统的功能，最重要的是，在与客户服务系统集成并为 CSR 移交提供无缝聊天机器人时，我们有哪些选择。
聊天机器人开始处理一些企业的询问。尽管通过简单的谷歌搜索或查看该公司的 FAQ 页面，这些问题中的一些可能很容易得到回答，但一部分客户仍然会通过实时聊天或该公司的脸书页面来联系。这是一个很好的机会，可以自动完成一些工作来回答这些客户的问题。
也就是说，机器人目前不能总是优雅地处理问题。作为一项相对较新的技术，聊天机器人可能没有得到充分测试，并产生令人困惑或不一致的体验。聊天机器人本身的错误可能会导致机器人没有响应，CSR 必须介入并手动接管对话，以确保客户满意。因此，使用聊天机器人技术自动化工作负载的公司通常不会看到工作负载的立即减少。事实上，专注于使用机器人本身的一套新技能变得必要并不罕见。随着技术和我们对其用途的理解的提高，我们可能会达到人类被取代的程度，但不要指望这种情况会马上发生。人类 CSR 必须留在回路中，以便在需要时进行调解。
在客户服务行业流行的聊天机器人主要有三类。一家公司制造的机器人类型与它认为聊天机器人可以正确处理的案例数量直接相关，也与用户通过自然语言与计算机对话的意愿和悟性直接相关。
一个永远在线的聊天机器人直接连接到用户的频道，等待问题或指示。它假设自己可以处理每一个输入，即使是通过说出可怕的“我不知道”的回答。这里的关键是平衡；一个机器人可以尝试处理每一个查询，但它必须清楚自己的局限性，并能够为用户指出可能的帮助来源。当然，如果机器人不能处理请求，建议提供一种替代的联系人类的方式。如果无法实现无缝的人员升级集成，那么即使提供一个参考数字也比没有好。
有时打开的聊天机器人可以处理一个较小的封闭问题集和用户输入，但如果它不确定或不知道答案，它会立即将问题转发给人工代理。这是一种有效的方式来降低用户陷入聊天机器人的循环中而无法获得任何帮助的风险。另一方面，如果一个具有前瞻性思维的客户试图探索机器人的功能，并且在几乎任何输入上都被重定向到人类，这可能会成为一种令人沮丧的体验。一个很好的妥协是建议用户，当机器人不理解用户的意图时，他们可以与人类代理交谈。同样，如果没有无缝的人工上报功能，任何联系业务的方式都比没有好。
面向企业社会责任的机器人充当企业社会责任系统的扩展，并向人类代理提供关于应该如何响应用户查询的建议。这是一个有趣的方法，因为它稍微颠倒了聊天机器人的概念。这也是一种收集数据的好方法，可以根据用户的查询和代理的响应来训练聊天机器人。这种方法是为聊天机器人构建用例及内容的有效技术。我们还观察到，这种聊天机器人在企业客户不了解技术或者更喜欢与人交谈的情况下表现良好。
客户服务系统可以是多方面的。它可以是一个知识库。它可以是一个售票系统。可以是呼叫中心系统。它可以是一个信息系统。在引言一章中提到的该领域的大公司中，所有公司都在其产品中包含了这些功能的某种组合。事实上，由于这些系统从客户那里获得了丰富的数据集，如详细的知识库和丰富的对话历史，许多参与者正在开发自己的虚拟助理解决方案。例如，一个显而易见的开始是创建一个虚拟助手，它在知识库中查询已知问题的答案。票务系统可以很好地提供一个聊天机器人，它可以检查门票状态，并对现有门票进行基本编辑。
客户服务系统通常会将用户和企业之间的每一次交互组织成一个项目，称为案例。例如，客户向企业寻求密码问题的帮助，在系统中打开一个新案例。新项目可能会进入所有活动代理在其桌面上看到的收件箱。该案例将被分配给选择该项目的任何人，或者系统可能会自动将该案例分配给一个目前有空但没有处理太多案例的 CSR。一旦代理帮助客户解决了问题，案例就结束了。代理可能已经为客户创建了一个新票据，将案例与票据关联起来。CSR 系统知道多条数据。它知道代理何时可用。它知道代理通常处理案件的速度。它知道呼叫中心的工作时间，因此可能不允许在下班时间进行任何实时聊天。
所有这些数据构成了非常丰富的报告。这些系统通常会提供详细的报告，包括聊天总数、聊天参与度、排队等待时间、结案时间、首次响应时间以及许多其他有趣的数据点。很自然，CSR 团队将根据这些措施得到评估和补偿。
作为 bot 开发者，我们不应该期望 CSR 团队改变其工作流程或数据报告结构。事实上，许多这样的系统都提供了机器人集成点，将聊天机器人视为代理。每个系统都略有不同，但它们通常遵循这种范式。这种方法的好处之一是，系统的报告功能不会因为引入聊天机器人作为虚拟 CSR 而中断。
与客户服务系统集成意味着我们需要编写代码来启动和关闭案例。当来自客户的新消息到达时，案例启动可以自动发生。当聊天机器人完成对用户查询的帮助时，案例结束。案例的定义会有所不同。案例可以被定义为从用户提问的时刻开始，直到聊天机器人给出答案为止。或者，案例可以被定义为聊天机器人和用户之间的任何交互，直到对话中有 15 分钟的活动。
有多种方法可以将聊天机器人与客户服务系统无缝集成。我们将看看三个选项。我们选择的集成级别取决于支持团队的成熟度和可用工具。我们将在探索每种类型的集成时解决这个问题。
定制界面可能最适合具有高度专业化工作流的团队，或者没有任何现有客户服务人员或系统的团队。此外，如果我们将机器人部署到一个没有现有的负担得起的工具的通道，我们可能别无选择，只能构建自己的工具。虽然不建议使用定制的接口，但是有些开发人员已经自己创建了接口。下面举个例子: https://ankitbko.github.io/2017/03/human-handover-bot 。一般方法是在现有 bot 功能的基础上构建一个类似客户服务的系统。显然，现在的问题是，我们的开发团队拥有客户服务接口，并负有保持系统运行的额外责任。
如果您没有现有的客户服务系统，但打算部署到一个拥有自己的支持工具的通道，那么您很幸运。例如，脸书页面允许客户通过 Messenger 与企业互动。Pages 为页面所有者提供了许多功能，其中之一是一个时尚的收件箱(图 12-1 )。当来自客户的消息到达时，它们将出现在左侧面板上。页面主体包含聊天历史，并允许企业与用户进行交互。
图 12-1
脸书页面收件箱用户界面
可以说，用户界面是页面所有者响应多种类型的用户查询的一种强有力的方式。当然，挑战在于，如果机器人被部署到脸书以外的频道，平台上的界面将不支持这些实时聊天场景。
如果一个团队已经有了一个支持实时聊天的客户服务系统，我们很可能想要开发一个与现有系统的集成。这样做的过程高度依赖于系统。这种方法中最重要的任务之一是，机器人必须是客户服务系统的好公民，并且不能破坏其他代理的体验。这意味着必须遵守案例打开和解决规则，并且必须记录用户和 bot 之间交换的所有消息。如果代理开启了一个缺少对话历史的案例，这将被证明是一次糟糕的客户体验。你想看到一个沮丧的顾客吗？多次问他们同一个问题。
如果我们天真地开始实现人工交接流程，我们可能会以图 12-2 所示的结果告终。我们将以 Facebook Messenger 为例。聊天机器人通过机器人连接器与信使通信。在正常的会话流中，机器人将所有传入的消息转发给客户服务系统并响应用户。如果一个案例还没有打开，该机器人还负责打开该案例。
图 12-2
没有人工代理的正常对话流
当对话流需要人工交接时，聊天机器人充当代理，将用户的消息发送到代理聊天中，并将代理的响应转发回用户。如图 12-3 所示。如果代理已经解决了该案例，则必须关闭该案例。
图 12-3
客户与人工代理交互
这种型号不受欢迎。主要原因是客户服务系统通常连接到现有的社会通道，如脸书。聊天机器人脸书和客户服务系统之间的连接看起来更像图 12-4 。
图 12-4
聊天机器人、脸书和客户服务系统在实践中的联系
社交平台通常不支持多个应用同时监听一个对话。因此，需要选择哪个系统拥有该连接。由于客户服务系统可以提供超越聊天集成的集成，并且通常在做出构建聊天机器人的决定之前就已经就位，因此它们最终拥有连接。
在脸书的情况下，我们可以使用一种叫做切换协议的东西，它允许我们绕过一次只有一个应用拥有连接的限制。使用这个协议，我们可以指定一个应用作为主要应用，其他任何应用都是次要的。当用户第一次与页面开始对话时，将总是联系主应用。主应用然后可以将对话线程转移到辅助应用。当应用在用户对话中不活跃时，它处于待机模式。通过实现待机通道，有一种方法可以确保应用在待机模式下接收用户的消息。您可以在 https://developers.facebook.com/docs/messenger-platform/handover-protocol 找到更多文档。图 12-5 显示了所描述的设置。
图 12-5
Facebook Messenger 上的移交协议实现。Out bot app 指定为主，我们选择的直播聊天平台为辅。
不幸的是，并不是每个通道都支持多应用范例，也不是每个客户服务系统都实现了切换协议。更不用说，我们假设一个脸书专用的机器人。增加更多的通道会给这种方法带来更多的挑战。
图 12-6 展示了集成人工交接的另一种方法。使用这种方法，客户服务系统充当打算发送给机器人的消息的代理，直到对话被转交给人类。此时，聊天机器人看不到任何对话片段。这种设置也意味着脸书通道连接器不在循环中，所以我们需要实现一个自定义的翻译器来接收 Messenger 格式的消息，将它们转换为 Bot Builder SDK 格式，并使用直线将消息转发到聊天机器人，就像我们在第 9 章中所做的那样。
这种方法更常见，因为与在两个系统之间共享脸书页面相比，将后端集成到客户服务系统的生态系统中更容易。这种方法在客户服务系统支持的任何系统上支持人工切换时也是有效的。
图 12-6
聊天机器人与客户服务系统集成的一种更常见的架构方法
很难展示一个完全集成的基于产品的人工交接场景，但是如果我们假设脸书页面是前面图中的客户服务系统，那么这样做就容易多了。在本节中，我们将把人工交接集成添加到我们在整本书中构建的日历机器人中。
我们使用的方法如下。首先，我们将创建一个新的意图来处理客户与人工代理对话的明确请求。接下来，我们将创建一个对话框来处理转移用户的逻辑。我们将指定我们的机器人作为主要应用，收件箱作为次要应用。我们将演示如何将线程控制从我们的应用转移到收件箱。最后，我们将展示如何通过脸书页面收件箱支持客户，然后将控制权发送回聊天机器人。
让我们创建一个新版本的日历机器人模型。在这个版本中，我们将创建一个名为 HumanHandover 的意图，并为其提供如下示例语句:
-
"与代理交谈"
-
“给我一个人类”
-
“我想和人类说话”
我们培训并发布 LUIS 应用。我们的聊天机器人将无法接收到这个意图并对它做些什么。
{
"query": "take me to your leader",
"topScoringIntent": {
"intent": "HumanHandover",
"score": 0.883278668
},
"intents": [
{
"intent": "HumanHandover",
"score": 0.883278668
},
{
"intent": "None",
"score": 0.3982243
},
{
"intent": "EditCalendarEntry",
"score": 0.00692663854
},
{
"intent": "Login",
"score": 0.00396537
},
{
"intent": "CheckAvailability",
"score": 0.00346317887
},
{
"intent": "AddCalendarEntry",
"score": 0.00215073861
},
{
"intent": "ShowCalendarSummary",
"score": 0.0006825995
},
{
"intent": "PrimaryCalendar",
"score": 2.43631575E-07
},
{
"intent": "DeleteCalendarEntry",
"score": 4.69401E-08
},
{
"intent": "Help",
"score": 2.26313137E-08
}
],
"entities": []
}脸书切换协议由两个主要动作组成:传递线程控制和获取线程控制。每当新的对话开始时，主应用都会收到用户的消息。主应用确定何时将控制传递给辅助应用。主应用将知道辅助应用的硬编码标识符，或者它可以查询页面以获得辅助应用的列表，并在运行时选择一个。如果我们的页面根据功能区域有多个二级应用，聊天机器人可以根据用户的输入计算出转移的目的地。辅助应用完成后，它可以将控制权交还给主应用。
在脸书页面的上下文中，页面的收件箱可以被认为是一个辅助应用。从功能的角度来看，这意味着任何管理页面收件箱的人都不应该看到消息，除非聊天机器人已经把它交给了收件箱。我们可以在页面的 Messenger 平台设置中进行设置(图 12-7 )。
图 12-7
为脸书页设置主要和辅助接收人
接下来，我们创建负责调用移交逻辑的对话框。对脸书 API 的请求将指向这两个端点中的任何一个，尽管我们的演示只需要联系 pass_thread_control 端点。
const pass_thread_control = 'https://graph.facebook.com/v2.6/me/pass_thread_control?access_token=' + pageAccessToken;
const take_thread_control = 'https://graph.facebook.com/v2.6/me/take_thread_control?access_token=' + pageAccessToken;无论我们调用哪个端点，都必须包含用户的 ID，并且可能包含一些元数据。 pass_thread_control 方法还需要传递一个 target_app_id 来指示线程被转移到哪个应用。脸书文档指出，移交到页面收件箱要求 target_app_id 的值为 263902037430900。接下来显示了调用脸书端点的代码。我们使用 request Node.js 包来发出新的 HTTP 请求。
function makeFacebookGraphRequest(d, psid, metadata, procedure, pageAccessToken) {
const data = Object.assign({}, d);
data.recipient = { 'id': psid };
data.metadata = metadata;
const options = {
uri: "https://graph.facebook.com/v2.6/me/" + procedure + "?access_token=" + pageAccessToken,
json: data,
method: 'POST'
};
return new Promise((resolve, reject) => {
request(options, function (error, response, body) {
if (error) {
console.log(error);
reject(error);
return;
}
console.log(body);
resolve();
});
});
}
const secondaryApp = 263902037430900; // Inbox App ID
function handover(psid, pageAccessToken) {
return makeFacebookGraphRequest({ 'target_app_id': secondaryApp }, psid, 'test', 'pass_thread_control', pageAccessToken);
}
function takeControl(psid, pageAccessToken) {
return makeFacebookGraphRequest({}, psid, 'test', 'take_thread_control', pageAccessToken);
}该对话框的代码非常简单地调用了 handover 方法。
const builder = require('botbuilder');
const constants = require('../constants');
const request = require('request');
const libName = 'humanEscalation';
const escalateDialogName = 'escalate';
const lib = new builder.Library(libName);
let pageAccessToken = null;
exports.pageAccessToken = (val) => {
if(val) pageAccessToken = val;
return pageAccessToken;
};
exports.escalateToHuman = (session, pageAccessTokenArg, userId) => {
session.beginDialog(libName + ':' + escalateDialogName, { pageAccessToken: pageAccessTokenArg || pageAccessToken });
};
lib.dialog(escalateDialogName, (session, args, next) => {
handover(session.message.address.user.id, args.pageAccessToken || pageAccessToken);
session.endDialog('Just hold tight... getting someone for you...');
}).triggerAction({
matches: constants.intentNames.HumanHandover
});
exports.create = () => { return lib.clone(); }让我们看看这种互动在脸书收件箱里是什么样子的。在我们运行 bot 之前，我们注意到脸书页面中的收件箱是空的(图 12-8 )。
图 12-8
清空收件箱
我们可以和日历机器人交换一些信息。图 12-9 显示了一个示例交互。
图 12-9
预热
请注意，脸书页面收件箱仍然是空的；这是有意的。由于主要应用负责处理用户的消息，因此没有必要让页面收件箱参与进来。如果我们展开界面左上方的汉堡菜单，会发现收件箱有多个文件夹(图 12-10 )。
图 12-10
我们已经找到了收件箱文件夹
瞧，如果我们点击 Done 文件夹，我们会找到我们刚刚与聊天机器人的对话(图 12-11 )。我们完全可以在响应文本框中键入我们的回复，但这只会让用户感到困惑，因为机器人和人都会响应客户，因为机器人仍然在循环中。
图 12-11
我们找到了我们的对话！
让我们回到收件箱文件夹。我们还以客户的身份返回 Messenger，并要求与人交谈(图 12-12 )。
图 12-12
我要求和她说话！
如果您刷新收件箱页面，您会注意到该对话出现在收件箱中(图 12-13 )。
图 12-13
好了，是时候和我们的客户谈谈了！
此时，聊天机器人看不到任何客户消息，从脸书页面收件箱发送的任何消息都会出现在客户的聊天中(图 12-14 )。
图 12-14
哦，哇，无缝的人员升级集成！
现在，下一步是断开与二级应用的连接。如果我们有两个脸书应用，我们将不得不使用我们编写的代码收回控制权或将控制权传递回主应用。在这种情况下，页面收件箱具有内置的功能。在任何对话的右上角，我们会发现一个标有“标记为完成”的绿色文本按钮(图 12-15 )。
图 12-15
通过点击“标记为完成”按钮将用户转移回聊天机器人
一旦对话结束，代理点击那个按钮，对话就被传送回机器人。从脸书页面收件箱的角度来看，对话被移回 Done 文件夹，机器人再次被激活(图 12-16 )！从客户的角度来看，这是完全无缝的。
图 12-16
机器人再次活跃起来
如果用户再次遇到麻烦，他可以再次请求人工代理来解决问题。
我们在这一章的工作重点是无缝的人员交接。这是我们的客户和代理的关键体验要求。为双方提供的体验应该尽可能无摩擦。聊天机器人应该是一个有用的助手，这将增加聊天机器人从内部和外部各方获得支持的可能性。
虽然我们在本章中演示的示例在范围上仅限于脸书，但它说明了大多数聊天机器人与实时聊天系统集成将遵循的一般方法。当然，还有许多细节需要解决，这个问题没有单一的解决方法，但是我们在这一章所做的工作应该足以让我们的聊天机器人的人工切换功能朝着正确的方向发展。