大厂的客服平台架构实践

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&优惠券等营销中台建设
• 交易平台及数据中台等架构和开发设计

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：

• 编程严选网

智能中台是啥

集结了中台产品技术、AI能力和体验平台技术，致力于为集团各业务线提供行业领先的专业服务，当前已沉淀了账号、支付、计价、触达、IOT、体验等核心中台能力；AI技术已深入应用于安全、智能运营、智能客服、智能驾驶等场景；持续通过搭建客服及体验平台等技术手段，提升用户体验问题的解决效率。智能中台是一支专业、多元、高效、务实的团队，坚持用技术赋能出行领域，力争成为业内多快好省的中台标杆。 体验平台聚焦于公司的服务质量和用户体验，通过研发工作台、工单体系、聊天机器人、呼叫中心、解决方案平台、运营工作台等核心服务产品体系，赋能公司服务体系降本增效，不断提升服务质量和水平。在这里有机会了解公司全BU的产品逻辑，并用数据驱动的方式持续优化，不断输出技术价值。

0 前言

客服是连接用户与BU的桥梁。从用户角度，用户通过智能渠道如C端自助或者人工客服渠道反馈问题和表达诉求，渠道识别和记录用户问题后，给出问题对应的解决方案。

在过去，问题对应的解决方案散落在渠道及各相关模块中，导致很多问题的解法（包括体验和逻辑）不一致，解决方案质量难以保证，影响解决能力和用户体验，而且难以管理和运维。另一方面，这些解决方案很大程度依赖BU提供的服务能力，以往的编程式接入成本高迭代周期长，而且缺乏统一管理会导致相同场景下服务能力使用的一致性难以保证，影响解决方案的质量和用户体验。 为了保证解决方案质量，提升用户体验和管理效率，我们需要统一管理这些解决方案：建设解决方案平台，整合各BU提供的业务信息和服务能力，为人工和智能渠道统一提供标准化解决方案。

1 解决方案平台

分析散落各处的解决方案，一般是基于BU输入的业务逻辑和服务能力封装的处理能力，大体可以分为两类：回答咨询使用的话术和解决问题的处理流程。为此我们目前提供了静态知识和动态流程两类标准解决方案，加上方案匹配层，组成整个解决方案平台：

• 动态解决方案：主要指流程，简称为SOP，应用场景比较广泛，例如用户自助处理单车关锁失败的流程，或者人工客服解决用户费用投诉的流程等，主要支持需要按标准流程处理和解决用户问题的场景；

• 静态解决方案：主要指知识，相关产品在业内通常称为知识库，在咨询类和指导类场景中很常见，例如用户进线咨询某个活动的规则，又例如客服熟悉新业务知识等，主要应用于规则介绍、问题解释和指导等场景；

• 方案匹配：主要负责管理问题到答案的关系；

2 动态解决方案

需标准化流程引导及解决用户问题的场景，提供流程管理平台，负责生产、执行和管理动态流程。

用户（C端用户、客服等）通过表单界面进行信息交互，背后则是处理该问题的业务流程向前驱动和处理。

2.1 链路示意

链路需解决问题：

• 如何支持不同渠道的交互方式
• 如何支持处理流程标准化
• 业务信息和服务能力如何规范且高效地接入

为此，设计拆分：

• 交互方式：不同表单类型支持各渠道不同交互，为用户提供标准化交互能力和一致的交互体验
• 流程管理：业务处理逻辑核心，负责根据用户和业务的输入数据，驱动处理步骤按业务规定的逻辑执行，起到引导和规范作用。基于流程引擎提供核心的流程执行和管理能力，支持业务针对不同场景自定义处理流程，实现从流程接入到执行的线上化和标准化。
• 资源管理：表单和流程的设计支持了业务信息的标准化接入，而服务能力的接入，从使用角度定义资源的概念，主要包括api及api返回的字段field。为管理资源，基于资源引擎搭建了资源配置化接入和使用的能力，支持BU服务能力的标准化接入，同时对业务运营使用服务能力更友好

2.2 整体功能架构

基于流程的整套配置管理能力，一个流程从设计到测试到上线实现全流程线上化，很大程度缩短业务迭代周期，提升产研效率。

基于这条链路实现业务可视化管理，为业务梳理、质量把控、风险控制提供支持。打通C端自助链路，意味着一个用户问题对应的处理自助流程上线可完全配置化上线，迭代效率平均提升60%。在此基础打通端-解决方案-工单的数据链路，为业务精细化运营提供数据支撑。

3 静态解决方案

业务信息要透传给用户或辅助客服解决用户问题的场景，提供标准的静态知识解决方案，从产品层提供客服知识点、用户Q&A对、相似问题列表等。

整体功能架构

客服业务对静态知识的核心诉求：

• 知识的结构化/非结构化存储
• 适用各场景的检索能力

当前产品在这两方面的能力受限于关系型数据库的存储，接下来将进行一系列升级建设，同时也包括产品层面知识检索、运营和反馈等功能的进一步加强。

4 方案匹配

根据用户问题找到相应解决方案，处理多渠道的问题与同一方案的匹配关系。

匹配过程，一个问题能找到唯一解决方案，一个解决方案可对应多个问题。理想，分别为用户每个问题和每个解决方案设计唯一编号，方案匹配层只需要维护问题到答案的一对多的关系即可。但：

• 用户问题描述方式不是唯一编号，而是多维排列组合
• 每次想匹配的不一定是一个标准解决方案，也可以是一组，比如一个静态知识方案和一个动态流程方案打包成最终的解决方案

因此方案匹配层的设计思路是维护问题组到答案组的关系，目前这一层的能力比较单薄，未来计划升级底层能力，支持异构的问题组和答案组匹配，提升可扩展性以适应业务及产品层的快速迭代。

5 技术沉淀

前面我们从业务视角介绍了解决方案平台如何支持客服业务，其实在平台建设过程也遇到了一些技术上的挑战，下面主要结合解决方案平台建设过程中遇到的问题介绍一些技术沉淀：

6 流程引擎

介绍动态解决方案，提到底层依赖核心基础能力——流程引擎。调研了Activiti等方案，作为成熟工作流引擎，activiti功能强大完整生态，但在场景中优势不明显：

• 定位，建设的是流程引擎产品化后的产品，对流程引擎只依赖流程驱动的核心能力
• 功能，在流程定义和执行过程中对部署校验、数据交互、分支选择等方面有activiti不满足或不易扩展的需求
• 性能，Activiti通用性和灵活性决定实现复杂度，如频繁存储层操作等导致性能不佳，不能很好满足C端
• 上手成本及维护成本

最终决定场景自研。轻量级流程引擎，自研流程引擎主要负责提供稳定而高效的能力：驱动流程执行，告诉上层下一个节点是啥。

6.1 关键模型

考虑兼容性，在设计如何描述流程时参考bpmn规范：

• 流程：定义起点、终点及起点到终点要执行的活动、执行路径、执行策略
• 流程元素：构成流程中的各种元素，分为节点和顺序流两大类，节点又分事件节点（如开始和结束节点）、任务节点、网关节点（如排他网关节点）
• 流程模型：每个元素中描述了它从哪来可以向哪去，于是用流程元素列表可以完整描述一个流程

6.2 整体设计

要使用一个流程，分两步：

• 设计一个流程
• 执行这个流程

就像定义一个类与创建一个对象。因此流程引擎架构基本按这思路，分为两大部份：流程定义和流程执行

6.3 流程定义

为保证流程在执行过程中：

• 不受流程模型更新的影响

• 考虑运维

流程定义时，对流程模型采用近似快照的处理，在流程执行时直接使用快照模型：

6.4 流程执行

从【开始节点】开始，处理【当前节点】，完成处理后，根据当前状态及配置规则找到下个节点，并继续处理节点，直到【结束节点】：

• RuntimeProcessor：上游主动与引擎交互的时机为开始执行流程和执行流程中的一些任务节点，流程引擎为流程执行开放了三个核心接口：开始执行、提交、回滚任务

• FlowExecutor：负责根据流程定义不断驱动节点的处理，同时管理流程实例状态

• ElementExecutor：负责单节点处理，包括下个节点选择，同时管理节点实例状态

7 资源引擎

解决方案平台为解决各种用户问题，会整合的业务输入中还有一部分是服务能力（目前主要是由各BU通过API提供）。整个客服业务在其他场景也有类似对接大量业务API需求。基于使用和管理这些API以及高效接入和迭代的各种需求与痛点，参考解决方案平台的API接入&管理模式，将其沉淀抽象出资源引擎，收敛管理客服体系内接入的BUAPI，提供使用资源的工具，支持配置化接入及统一管理。

7.1 整体设计

将BU提供的服务能力称为“资源”，并根据使用场景将资源分为两大类：

• API：BU提供的接口能力，如查询订单详情api
• Field：通常为一个字段，如订单详情接口返回的“总金额”字段

使用资源分为定义资源和获取资源两部份，资源引擎提供的能力也以这两部份为核心，辅以相关的配套管理能力，于是我们设计了相关的模块：

• 客服端：SDK，使用方自行集成该SDK，根据资源引协议，查询资源定义，并获取及解析资源
• 服务端：服务端，支持资源定义的查询
• 管理平台：配置化接入资源及资源列表的统一管理
• 质量数据：产出离线数据，包括接入的资源的使用情况、错误率、耗时等质量数据，帮助使用方及BU发现问题，迭代方案

7.2 交互模式

7.3 系统架构

Manager：资源管理后台，是资源及相关的配置管理入口

Server：服务端，需要高性能且稳定地支持客户端的查询，尽量做到轻量，因此server只做两件事：访问控制、高效查询

Client：客户端SDK，负责获取资源

Resource：BU提供的服务能力，目前主要支持API，未来根据需求考虑扩展

7.4 资源计算

Client即SDK负责最核心的获取资源的逻辑，层次设计：

• Protocol：协议层，描述sdk使用方如何使用资源，如可扩展GQL

• Processor：核心逻辑，

  • a. 与server交互获取资源相关定义
  • b. 根据定义计算执行计划
  • c. 通用executor调用BUAPI
  • d. 解析和加工API返回的数据，得到最终结果

• Executor：根据资源定义，调用BU能力获取直接结果

7.5 案例

• field f1来自api a1(对应返回结果的apiField1字段)

• api a1的参数为field f4

• field f4不是api数据，只是对field f3的再加工；

• field f3的值为v3；

• field f2描述省略...

求：f1、f2值：

• Interpret：协议解析，解析出参数列表以及需要获取的资源列表；

• Preprocess：这里包括要获取的资源以及它们依赖的所有资源的配置；

• Allocate：将2得到的资源列表分成组，分组原则是组内的每个资源至少与组内的另一个资源有依赖关系，且不依赖任何组外的资源，抽象来说类似有向联通图的意思；

• Process：将每个组内的资源列表提交给处理任务，遍历进行原子处理：

• 1. 递归获取该资源依赖的资源列表；
  2. 执行API，得到原始结果；
  3. 根据transformer，对原始结果进行加工，得到最终结果；

资源引擎除了支持解决方案平台，目前还在特征、工单等场景落地。此外，除了支持BU服务能力接入，资源引擎也适用于客服能力输出给BU的场景中，目前这套标准化方案也在建设中。

8 总结

解决方案平台通过标准化的思路，整合业务提供的业务信息和服务能力，拉齐不同渠道的答案和处置方案，提供可视化的方案管理平台。在打磨标准化能力的同时，下一步将会向着自动化与智能化的方向探索，以期在提升解决能力，支持精细化运营等方面发掘更大价值。