《滴滴客服平台建设解决方案》由会员分享，可在线阅读，更多相关《滴滴客服平台建设解决方案（17页珍藏版）》请在金锄头文库上搜索。
1、滴滴客服平台建设解决方案1.前言客服是连接用户与事业部的桥梁。从用户角度，用户通过智能渠 道如 C 端自助或者人工客服渠道反馈问题和表达诉求，渠道识别和记 录用户问题后，给出问题对应的解决方案。在过去，问题对应的解决方案散落在渠道及各相关模块中，导致 很多问题的解法（包括体验和逻辑）不一致，解决方案质量难以保证， 影响解决能力和用户体验，而且难以管理和运维。另一方面，这些解 决方案很大程度依赖事业部提供的服务能力，以往的编程式接入成本 高迭代周期长，而且缺乏统一管理会导致相同场景下服务能力使用的 一致性难以保证，影响解决方案的质量和用户体验。为了保证解决方案质量，提升用户体验和管理效率，我们需
2、要统 一管理这些解决方案：建设解决方案平台，整合各事业部提供的业务 信息和服务能力，为人工和智能渠道统一提供标准化解决方案。2.解决方案平台分析散落各处的解决方案，一般是基于事业部输入的业务逻辑和 服务能力封装的处理能力，大体可以分为两类：回答咨询使用的话术 和解决问题的处理流程。为此我们目前提供了静态知识和动态流程两 类标准解决方案，加上方案匹配层，组成整个解决方案平台：动态解决方案：主要指流程，简称为SOP，应用场景比较广泛, 例如用户自助处理单车关锁失败的流程，或者人工客服解决用户 费用投诉的流程等，主要支持需要按标准流程处理和解决用户问 题的场景；静态解决方案：主要指知识，相关产品在业
3、内通常称为知识库, 在咨询类和指导类场景中很常见，例如用户进线咨询某个活动的 规则，又例如客服熟悉新业务知识等，主要应用于规则介绍、问 题解释和指导等场景；方案匹配：主要负责管理问题到答案的关系；面向终端用户1解决用户问題宀客服 I问题识别I人工渠道智能渠道（在线、热线等（自助、机器人弄）n用辱题标准眠决方案1解决方至平台方案匹配静态知识版茅匪力（API）动态淤程解决方枭事业部口业秀信息mi说明、处逼诡程等）动态解决方案针对需要通过标准化流程引导以及解决用户问题的场景，我们提 供了流程管理平台，负责生产、执行和管理动态流程。用户(C端用 户、客服等)通过表单界面进行信息交互，背后则是处理该问题
4、的业 务流程向前驱动和处理，下图是对这个链路的一个简单示意：用广衷華是否5.橄毎述一下问贮A上一步下一歩流程在这个链路中需要解决几个问题:1).如何支持不同渠道的交互方式；2).如何支持处理流程标准化；3).业务信息和服务能力如何规范且高效地接入。为此，我们在设计上从几方面进行了拆分：交互方式：通过不同的表单类型支持各渠道不同的交互方式。 同时通过多样化的组件能力、交互方式实现表单的可扩展性，支 持不同业务在不同场景的各种诉求，为用户提供标准化的交互能 力和一致的交互体验。流程管理：流程是业务处理逻辑的核心部份，它负责根据用户 和业务的输入数据，驱动处理步骤按业务规定的逻辑执行，起到 引导和规
5、范的作用。我们基于流程引擎提供了核心的流程执行和 管理能力，支持业务针对不同场景自定义处理流程，实现从流程 接入到执行的线上化和标准化。资源管理：表单和流程的设计支持了业务信息的标准化接入， 而对于服务能力的接入，我们从使用的角度定义了资源的概念， 主要包括了 api以及api返回的字段field。为了管理资源，我们 基于资源引擎搭建了资源配置化接入和使用的能力，支持事业部 服务能力的标准化接入，同时对业务运营使用服务能力更加友好整体功能架构人工渠道智能渠道（eg：在线、热绘等）（eg：自助机器人等）管埋平台目前，基于流程的整套配置管理能力，一个流程从设计到测试到 上线实现了全流程线上化，很大
6、程度地缩短了业务迭代周期，提升产 研效率。同时，基于这条链路实现了业务可视化管理，为业务在业务 梳理、质量把控、风险控制等方面提供了有力支持。在今年年中，我 们打通了 C端自助链路，意味着一个用户问题对应的处理自助流程上 线可以完全配置化上线，迭代效率平均提升60%。在此基础上也同时 打通了端-解决方案-工单的数据链路，为业务精细化运营提供数据支 撑，助力业务综合提升解决能力。静态解决方案针对大量业务信息要透传给用户或者辅助客服解决用户问题的这些 场景，我们提供了标准的静态知识解决方案，从产品层上提供客服知 识点、用户Q&A对、相似问题列表等。整体功能架构知侃管理平甘知呪管理平台人工渠论【糾：
7、在瑕、热粧等)齟识应用皆能渠迺(eg-自朗*机謎人等】SUiF!捜爲在客服业务中，对静态知识有两个核心诉求：1.知识的结构化/ 非结构化存储；2.适用各场景的检索能力。当前产品在这两方面的 能力受限于关系型数据库的存储，接下来将进行一系列升级建设，同 时也包括产品层面知识检索、运营和反馈等功能的进一步加强。方案匹配方案匹配是指根据用户问题找到相应的解决方案，处理多渠道的问题与同一方案的匹配关系。一般说来对于匹配过程，一个问题能找到唯一的解决方案，一个 解决方案可以对应多个问题。那么理想情况下，我们分别为用户的每 个问题和每个解决方案设计唯一的编号，方案匹配层只需要维护问题 到答案的一对多的关系
8、即可。但在落地过程中我们发现： 用户问题的描述方式不是唯一编号，而是多维度的排列组合； 每次想匹配的不一定是一个标准解决方案，也可以是一组，比 如一个静态知识方案和一个动态流程方案打包成最终的解决方 案；因此方案匹配层的设计思路是维护问题组到答案组的关系，目前 这一层的能力比较单薄，未来计划升级底层能力，支持异构的问题组 和答案组匹配，提升可扩展性以适应业务及产品层的快速迭代。3.技术沉淀前面我们从业务视角介绍了解决方案平台如何支持客服业务，其 实在平台建设过程也遇到了一些技术上的挑战，下面主要结合解决方 案平台建设过程中遇到的问题介绍一些技术沉淀：流程引擎 背景在介绍动态解决方案的时候，我们
9、提到它底层依赖的核心基础能 力一一流程引擎。在方案选型的时候我们调研了 Activiti等方案， 作为比较成熟的工作流引擎，activiti功能强大且有比较完整的生 态，但在我们的场景中优势并不明显，主要体现在几方面：从定位上，我们建设的是流程引擎产品化后的产品，对流程引擎 只依赖流程驱动的核心能力；从功能上，在流程定义和执行过程中对 部署校验、数据交互、分支选择等方面有activiti不满足或不易扩 展的需求；从性能上，Activiti的通用性和灵活性决定了实现的复 杂度，如频繁的存储层操作等导致其性能表现不佳，不能很好地满足 我们的C端场景对性能的需求；此外考虑上手成本及维护成本等综合 因
10、素，最终我们决定针对我们的场景自研。作为轻量级的流程引擎， 自研流程引擎主要负责提供稳定而高效的能力：驱动流程执行，告诉 上层下一个节点是什么。关键模型sequence-FIqw1以上图为例，简单介绍下我们如何描述一个流程（*考虑到兼容 性，我们在设计如何描述流程时参考了 bpmn的相关规范）：流程：定义了起点、终点以及起点到终点需要执行的活动、执行路径、执行策略；流程元素：构成流程中的各种元素，分为节点和顺序流两大类其中节点又分了事件节点（如开始和结束节点）、任务节点、网 关节点（如排他网关节点）；流程模型：每个元素中描述了它从哪来可以向哪去，于是用流程元素列表可以完整描述一个流程；整体设计
11、要使用一个流程分两步：1. 设计一个流程；2. 执行这个流程； 好比定义一个类与创建一个对象的关系。因此流程引擎的架构基本也 是按照这样的思路来设计，分为两大部份：流程定义和流程执行：接口层核心处理居尸 -r r-m-ra-ava-a vv w a w -w-w - B/ u v-m - a v r a r i流程执行器节点执行器流程定义:流程执行娱里处埋器模型校验雒数据權蹙流程模型1执行奚例1（流程定义、流程部署）（流程、节点、数据）1存储层1.流程定义为了保证流程在执行过程中，不受流程模型更新的影响，以及考虑运维场景的需求，我们在流程定义时对流程模型采用了近似快照的处理，在流程执行时直接使
12、用快照模型：冈1型，托许反矍2.流程执行流程执行其实是从开始节点开始，处理当前节点，完成处理后根据当前状态及配置规则找到下一个节点，并继续处理节点，直到结束节点：RuntimeProcessorsiartPracesscommitrecall4FlowExecutorrElem ent Exec uto rTaskExecutorEventExecutorGatev/ay ExecutorRuntimeProcessor：在流程执行过程中，上游主动与引擎交互的时机为开始执行流程和执行流程中的一些任务节点，流程引擎 为流程执行开放了三个核心接口：开始执行、提交任务、回滚任 务（提交的逆向操作）；
13、 FlowExecu tor：负责根据流程定义不断驱动节点的处理，同时 管理流程实例的状态； ElementExecutor：负责单个节点的处理，包括下一个节点的选 择，同时管理节点实例的状态；经过数月验证与迁移，现在我们的流程引擎已支撑动态解决方案 90%的流量，其中包括面向 C 端的链路。在性能和稳定性表现比较好， 上线至今未发生过任何一起相关故障。除了解决方案平台的使用场景 以外，流程引擎也在进一步探索开放化，目前已在工单相关场景中落 地。I资源引擎背景前文提到，解决方案平台为了解决各种用户问题，会整合的业务输入中还有一部份是服务能力（目前主要是由各事业部通过API提 供）。不仅解决方案
14、平台，整个客服业务在其他场景也有类似对接大 量业务 API 的需求。基于使用和管理这些 API 以及高效接入和迭代的 各种需求与痛点，我们参考解决方案平台的 API 接入&管理模式，将 其沉淀抽象出资源引擎，收敛管理客服体系内接入的事业部API,提 供使用资源的工具，支持配置化接入及统一管理。整体设计 在这里我们将事业部提供的服务能力称为“资源”，并根据使用场景 将资源分为两大类： API：主要指事业部提供的接口能力，eg.查询订单详情api； Field：通常为一个字段，eg.订单详情接口返回的“总金额” 字段。使用资源分为定义资源和获取资源两部份，资源引擎提供的能力 也以这两部份为核心，辅
15、以相关的配套管理能力，于是我们设计了相 关的模块： 客服端：SDK,使用方自行集成该SDK，根据资源引协议，查询资源定义，并获取及解析资源； 服务端：服务端，支持资源定义的查询； 管理平台：配置化接入资源及资源列表的统一管理； *质量数据：产出离线数据，包括接入的资源的使用情况、错误 率、耗时等质量数据，帮助使用方及事业部发现问题，迭代方案交互模式：的：各客艦系统）MaragarServer111L.驶取资Client（资淄筲理后台）（资涓定义脂务韶定义1i11（SDK（僂用资源）API.及f咱Id配萱SdK枭成很据毘义，我的&肆析资源送想疋文董询义管理系统架构:Metadata(resource、sign, caller)Resource
