SAP成都研究院飞机哥: SAP C4C中国本地化之微信聊天机器人的集成

今天的文章仍然来自Jerry的老同事，SAP成都研究院的张航(Zhang Harry)。关于他的背景介绍，请参考张航之前的文章：SAP成都研究院飞机哥：程序猿和飞机的不解之缘。下面是他的正文。

---

大家好，我是来自SAP成都研究院C4C开发团队的Harry。 今天给大家带来一个SAP C4C中国本地化的案例分享，这是我们成都C4C开发团队目前正在进行中的一个具有前瞻性的原型开发：通过C4C、微信、和基于Recast.AI的聊天机器人进行集成， 提升C4C的工单处理能力。 

这个原型开发之前我也在SAP成都研究院内部分享过，这是当时会议的宣传海报。非常感谢我的同事，S4CRM团队的Liu Zoe和最懂我的汪哥帮我量身设计了这张以F35战斗机为背景的海报。

相关业务背景介绍

C4C在业务模块方面分成销售和服务两大块，作为SAP的一款云产品，每天要快速处理大量的且时效性很强的业务信息。比如: 销售模块需要实时挖掘销售机会，服务模块需要对用户提出的产品故障，进行快速实时的反馈和响应。

SAP解决方案和社交渠道集成的价值在于，通过该方式，用户可以随时方便地接入系统，同时系统的反馈信息也能实时快速地反馈给用户，这样系统和用户之间的交互效率和用户体验就大大提高了。

另一方面， 工单处理(Ticket)是服务模块里面重要的功能之一。客服人员每天有数量巨大的工单需要处理，面临很大的压力，同时，系统对用户提出的紧急的产品故障，需要快速实时地做出正确的处理和反馈。因此，工单处理模块必须要保证高速性和高有效性。

我们团队完成的原型开发，在第一阶段实现了C4C工单处理流程和微信的集成：用户可以通过关注微信公众号，来通过微信渠道快速发布产品故障信息，同时，我们处理的结果、解决方案也可以通过微信，快速、实时地反馈给用户。这种方式利用了微信的渠道优势，提高了工单处理的速度。

而聊天机器人的集成，帮助我们提升了工单处理模块的另一个能力：高有效性。尽管客服人员每天会有很多工单需要处理，然而根据实际的客户经验，这些工单里面，大部分问题都有一些共同特点：处理起来比较简单，处理的逻辑不复杂，只需要客服人员稍微指导一下，客户自己就能够解决掉。 

这些问题的一些典型例子有，客户没有看懂说明书，或者产品设计不合理，诱导用户进行了错误操作，再或者是一些很常见的问题。

虽然这些问题单个处理起来花不了太长时间，但是数量一多，也会消耗客服人员大量的时间和精力来处理。

在这种背景下，成都C4C开发团队提出了一种解决方案： 引入智能聊天机器人，通过机器人内嵌的NLP(Natural Language Processing)自然语言分析能力，分析用户提出的问题。识别出用户提出问题里面的关键因素：

• 什么产品出了问题？

• 该产品具体出了什么问题？

然后利用这些关键因素，去后台知识库找到对应的解决方案，反馈给用户，智能指导用户解决问题。

该方案的优点是：理想情况下，会有很大数量的处理复杂度较低的客服工单被机器人自动处理掉了，客服人员面临的工单数量上的压力变小，可以把精力放在真正需要人工处理的那些复杂度较高的工单上。

实现效果展示

在C4C端，我们做了一个UI风格和微信非常相似的聊天界面，目的是方便客服人员在C4C系统里面， 和正在使用微信端的用户进行聊天。界面和交互方式模拟微信，目的是为了让客服人员用起来更加习惯，方便上手。

首先，当用户打开公共号聊天窗口时，机器人客服会致欢迎词，并提示用户按照一定格式输入产品故障信息，方便聊天机器人识别。

下图即是客户在自己手机上的微信应用里同C4C微信机器人进行交流：

当系统成功识别出用户提出的产品故障信息时，就会找到对应的解决方案，包装以后，通过社交渠道反馈给用户。

那么系统是如何自动进行产品故障和其解决方案的匹配呢？除了在C4C UI开发一个上面描述的模拟微信的聊天窗口和前端相关逻辑外，我们还部署了一个独立于C4C系统的第三方服务器, 基于node.js架构，称为Agent Server，用于拦截和处理来自C4C, 微信和聊天机器人的请求，实现相关的路由算法和处理逻辑。

在Agent Server上，我们部署了一个数据库，实现了相应的数据搜索逻辑，称为知识库(knowledge Base)，用来管理和存储工单处理的关键信息，包括：

• 产品型号信息

• 各类产品典型故障信息及其默认的解决方案

当用户输入信息包含合法的产品故障信息时(比如包含有产品型号，或者产品故障信息的具体描述), 通过Recast.AI识别出来后，会尝试去上述介绍的Agent Server上的知识库去查询相关的解决方案。如果能够找到解决方案，聊天机器人直接将其回复给客户，引导客户自己解决问题。

当机器人识别到用户输入的关键信息有问题，比如输入的产品型号有误，故障信息描述不准确，机器人也会在聊天窗口提示用户重新输入正确信息。

如果机器人无法找到相应的解决方案，或者实在无法识别用户输入语言里面的有用信息，会提示用户，切换到人工处理模式，同时向C4C后台发送提示信息，提示客服人员接手处理。当客服人员在聊天窗口输入信息时，工单处理模式自动切换到人工模式。

技术实现

用户输入的自然语言是“扁平化”的文本信息，输出是C4C通过微信反馈给用户的问题处理结果和解决方案，其展现形式可能会多种多样：简单的文字信息、或者是内嵌的链接、或是带有图片，word文档，pdf文档等附件，供用户选择。

上述业务需求的技术实现流程经历了三个阶段：

第一阶段，NLP自然语言建模。用户输入的扁平化的文本信息，系统是无法直接识别的，这些文本信息包含了多个维度的信息，比如: "我刚买的iphoneX 开不了机了"。其中 “iphoneX”和“开不了机”，分别代表了产品信息和故障信息两个维度的特性。NLP建模过程，就是把纯文本里包含的这些信息分门别类提取出来，再映射到不同维度上，形成一个多维度立体化的数据模型。具体体现我们这个原型开发里，就是一个json格式的数据。

下面给出了Recast.AI训练的截图，通过训练，使得AI能够把扁平化的输入文本，分析出正确的Entity, 即生成正确的多维度信息。

关于Recast.AI的更多使用细节，可以参考Jerry的文章：使用Recast.AI创建具有人工智能的聊天机器人。

第二阶段，把第一阶段传来的立体化、模型化的信息，由系统进行分析，识别出关键信息。根据关键信息，去知识库检索，拿到需要回复的信息。如果取不到关键信息，或者用户输入的信息有问题，由相关的逻辑组合成适当的信息作为缺省回复。

第三阶段，把处理的结果和解决方案，组装成满足微信信息要求的格式，反馈给用户。

未来的功能进一步扩展的探讨

目前我们完成的这个原型开发，主要目的是为了验证技术可行性和最简单的业务原型展示。 如果需要把这个原型转化成C4C产品，无论从产品功能还是技术实现，都需要进一步的细化和完善。下面是我们将来会进行进一步研究和探索的方向。

• 更加丰富、多样化的用户反馈信息：目前的原型开发， 对用户提出的问题，智能机器人只能用简单的文本信息进行回应。

  未来在给用户反馈的信息类型上，可以进一步向更加多样化和人性化方向扩展。比如：给用户的回复信息也可以是像word,pdf或者图片这样的格式，更好地帮助指导用户操作。或者通过带有链接，或者可执行按钮的反馈信息，用户点击后，可以进入更加详细信息的帮助页面，指导用户一步一步动态操作。

• 实现机器到人工的智能化切换：当前的原型开发, 一旦在知识库里检索不到产品故障对应的解决方案、或者Recast.AI无法获取足够的关键信息时，就简单地发出请求，提示人工客服接手，属于"一刀切"式的异常处理方式。

  未来，可以考虑进一步丰富异常处理方式，实现智能化切换到人工模式。当系统找不到合适解决方案时，至少能够根据已有信息，和系统里通过人工客服处理过的历史数据进行挖掘，分析哪些技师适合处理此类问题，再把分析结果推送给客服人员。

• 知识库信息更加丰富。产品解决方案的知识库的设计是一个很复杂的需求，当前的原型开发出于快速展示的需要，使用了最简化的产品知识库，只能根据产品型号和问题类型两个必须要素进行简单定位，存储的内容只有文本类型的解决方案。

  未来产品知识库的设计需要考虑到多重场景下多重解决方案的精确定位。比如，引入更多的查询要素，且不同的要素还可以设置不同权值，不同要素呈现层级关系，上层要素定位的解决方案可以被下层复用。查询要素和对应解决方案，也可以呈现多对多的关系。

因为我于2007年就进入SAP成都研究院并从事SAP Business ByDesign相关开发工作，这些年来我也有幸见证了SAP C4C的诞生，发展和壮大。在ByDesign这个基础技术平台上，通过开发不同的业务功能模块，衍生出了突出CRM这个行业垂直解决方案的C4C， 和突出端到端整体化解决方案的ByDesign标准产品。

巧合的是：我文章开头海报中F35战斗机的实现方案和SAP C4C产品有异曲同工之处。 正好我自己也收藏了一架比例为1：72的F35C的模型，拿出来给大家分享一下：

和大名鼎鼎F22“猛禽”一样，F35也是美国第四代先进战斗机，绰号“闪电2”， 21世纪才开始生产和装备，和强调高精尖和技术优势的F22不同，F35一开始研制采用了很多降低风险、成本的方式，比如拉拢多个伙伴国家，共同开发，技术共享和共同生产等。带来的好处就是：降低了技术风险，生产成本和后续维护成本。

另一方面，面临的挑战是：作为一款多国家共同研发多用途战斗机，必须要适配多个国家、多个军种，和各式各样的使用场景。 

同SAP C4C是基于SAP Business ByDesign平台衍生而成一样，F35也在一个基础平台的基础上，通过加装不同功能组件， 衍生出三种子型号， 以适应不同的使用场景： 

1.  F-35A：传统的陆基起降型，加装的功能组件最简单， 成本最低，主要在美国和其它国家的空军服役。

2. F-35B：垂直起降型，机身中间加装了能向下喷气的升力风扇，同时发动机带有矢量喷管，能够90度向下喷气，实现了垂直起降。这种型号的F35可以部署在，像日本 “加贺”级，英国的“伊丽莎白”级这样的中小型航母上，或者美国海军陆战队的“黄蜂”级、“美国”级这样的两栖攻击舰上。

3. F-35C：航母舰载型，也是我照片里面的模型的机型：机翼带有折叠功能，可以节约在航母上部署的空间，并且安装有加强的起落架和降落用着舰钩。

F35C在美国海军服役，部署到“尼米兹”，“福特”级这样的大型航母上。

今天关于SAP C4C和微信集成的创新案例就分享到这里，感谢大家阅读。

更多阅读

SAP成都研究院的C4C开发团队的同事们已经写过很多关于C4C的技术文章了，列表如下：

• C4C和微信公众号集成系列教程

• SAP成都C4C小李探花：浅谈Fiori Design Guidelines

• SAP S4CRM vs C4C, 诸葛亮和周瑜?

• SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的独特之处

• SAP Cloud for Customer Extensibility的设计与实现

• 机器学习在SAP Cloud for Customer中的应用

• SAP移动应用解决方案之一：HTML5应用 + Cordova = 平台相关的混合应用

• 打通C/4HANA和S/4HANA的一个原型开发：智能服务创新案例

• SAP成都研究院大卫哥：SAP C4C中国本地化之微信小程序集成

要获取更多Jerry的原创文章，请关注公众号"汪子熙":