蚂蚁集团 | 科技加持下的下一代服务体系

我们很有幸生在科技爆发的时代，这样的科技让我们的服务和行业变得更加的美好！

精彩回顾：2021（第五届）中国客户服务节

所谓的体系其实是很难去诠释的东西，我们做的所有事情都可以称之为在一个体系里，那么这个体系到底是好还是不好，其实是没有标准可以界定的，在不同的行业，不同的领域每个体系是不可同比的。

一、科技创新下的未来架构

这是我们服务很基本的一个概念，左边是客户，右边是业务，整个过程当中怎么看服务里面去承载沉淀的东西，其实是做成了四个定义：

1、服务设计。整个服务的流程也好，把产品问题转化为服务方案也好，是服务域很基本的东西。

2、服务设施。能让我们去提供服务，比如说场地，我们的一些设备，我们的一些工作平台，都是提供服务设施，比如智能客服，以及整个智能的渠道，我们都认为他是我们服务的设施。

3、数据资产。基于资产做很多的分析，做很多的重构设计，推动业务做体验优化。

4、数字引擎。为什么叫数字引擎，很多资产都可以做分析，无论是指标分析还是相关性的关联，无论业务分析还是数据的分析，大家在自己的行业都很资深和专业，这么多数据资产到底如何更好的驱动，实际上是需要更科技更智能的能力去加持，这也是在行业里面出现的类似于智能的辅助，分析的辅助，是能够把资产结构化，向业务去做传递，这其实是整个体系最基本的内核。

二、全渠道多种服务模式

那我们怎么看未来这个体系？

1、召唤性服务

实际上我们做这些服务的时候，无外乎就是几种，一种是用户可以找我们，无论是在线的入口还是电话号码，还是官方的微博，或者其他的通道，这是召唤式的服务，用户会主动发起。

2、场景式服务

另外是向用户提供场景化精准化的服务，会做很多的规则，以及对应的智能能力，把我们的能力诠释出来给用户做精准场景服务。

3、陪伴式服务

还有一种，很多行业都开始做的，就是主动的服务。我们会在用户发生问题时，有一个理念，就是不发生问题。其实不太可能的，产品一定会有很多可能的问题会发生。我们希望在产品发生问题的时候，我们的服务就会出现在那里，这种我们称之为“陪伴式的服务”。主动服务好理解，我们会把服务推送给用户，无论是通过预判还是相应的消息，甚至打电话这些都是主动式服务。

三、“Zero  Call”服务模式

有一种陪伴交互的概念，我们现在内部叫做Zero  Call服务模式。看了这么多服务模式，还有之前嘉宾分享的，行业里沉淀的很厉害的各种各样的能力，我们是怎么看待这些内容的呢。

用户整个链路很容易理解，产品发生了问题就来找我们，那我们会去思考，我们怎么在客服这个行业把能力一点一点建设出来。最早我们都是用人工服务的，可能在人工上做了很多续航的能力。包括怎么在人工上做分配，让用户快速的接入。我们会考核接通率，考核服务水平等等。这些能力让我们开始做服务，做得相对比较好以后，开始做智能的能力，增加了很多像智能的云交互，智能的机器人，甚至很多推荐的能力，或者是很智能的AI交互能力。

后来发现这样的服务对所有用户不是通用的。在做介入服务的时候就要做分层，有一些用户需要智能，有一些用户不要智能，还有一些用户给的智能会不太一样等等......现在很多时候，用户在使用产品的时候，很多服务能力就已经嵌进去了。我们希望在用户出现问题的时候就发送这样一些服务的能力，或者是服务的解决方案。

我们发现这个链路，我们服务的能力和思考是随着服务域的沉淀或者是更好的解决一步一步的在往前，那我们现在还要再做什么。我们发现有一个沉默大多数的概念。大家应该都有这个相应的定义，其实是寻求服务跟业务量级的比例。实际上这个比例相差蛮大的，那这些用户是不是出现了问题，是不是出现了障碍，那么怎么样去找到这样的用户，怎么去为他们提供服务。之前类似主动的能力，有些行业的同学会发现很难去把覆盖和打扰的概念平衡掉，我们不可能无时无刻的给用户发服务的消息。

蚂蚁域现在有数千个业务在跑，很多的页面和求助的量级是我们能看到的，实际上在业务层面变得越来越复杂，有越来越多交叉的场景，用户在求助的时候很难把问题描述清楚。那服务如何找到用户，在产品这个地方到底可以做什么，也是过去这一年和接下来一年，我们做蚂蚁服务想突破的方向和重点。

我们希望能把服务的能力组建起来，和一些产品的交互直接嵌入在一起，这样也许可能做到真正去掉服务这个理念。用户在产品使用的过程当中一定会出现障碍或者问题。用户在使用产品的过程，我们需要对用户行为做出一些预判，把沉淀好的服务方案、服务内容以组建化的形式在产品侧进行嵌入。这样从用户的视角来看，他没有去找服务，没有发起一通电话，也没有点击一些问号，但是我们能预判到，定义他在这个地方出现障碍的时候，服务的内容随着产品一起呈现出来。当然我们不会特意的去标识出服务的理念，我们更希望这套组建在前端的交互跟每一个产品是融为一体的。我们会在前端投入更多的工作，跟产品的交互完全的契合掉，让用户没有服务的概念。将服务和产品结合，这是我们下一代服务体系里重点突破的方向和理念。

四、去中心化资源网络

去中心化资源网络。过去很多时候“去中心化”这个词被证明过了，我们为什么还作为重点展示，最主要的还是受活动、疫情的原因。很多服务的资源，包括服务设施、服务入口，智能的能力，背后智能机器和网络的能力我们很容易做到去中心化的。实际上最难被去中心化的是服务的人，这些人他们是需要有血有肉的个体，不可能直接被数字化掉。

其次，他们本身服务的设施，服务的基础，服务的环境，甚至让他们提供服务的安全能力或者是风险能力，这些东西都需要我们固定到某一个地方，或者是禁锢在某一个场景下才能去做服务。真正去中心化的服务，是一个服务的小二，可以随时随地的去提供服务，这才能完成服务资源去中心化的概念。

结合到前面产品上的能力和服务端上面的能力，以及整个前面智能化的能力，才真正的做到了去中心化。最终的目的还是从服务延续性和风险角度考虑，假设之前服务的供应商或者服务的驻地，出现疫情无法提供服务，那大家还有多少能力能把服务延伸下去，这是很现实的问题。为了解决这个问题，把整个资源网络去中心化。

刚才介绍了两个想核心突破的问题，包括为了能够提供服务，实际上我们有小二的作业平台，这个作业平台是否能够随时随地的为小二所应用和给用户提供服务，这是一个重点。第二就是对用户的交互设计，智能大部分都是体现在交互上，但现在很多的交互受限于通道和服务模式的能力，我们也想做一些突破，整个体验的闭环也好，像智能解决能力也好，大家很容易相对去理解，我就不一一详细展开。

五、下一代服务体系核心突破

我们去思考下一代的服务体系到底应该做成什么样子。在过去一年我们内部一直在碰撞和思考，识别率从93%变成93.5%又怎么样呢，可能更多是在模式上突破创新的点，能够让整个服务行业进一步的往前走，我们想到一些在之前不太可能实现的点去突破。

举一个之前我们实现的例子，用户跟我们小二交互的时候可以直接传输很多的东西。比如用户有问题，希望用户进行数据的传输，传一个凭证或者是图片。可能打电话的过程，传这个并不是很方便。那客户端工作台是否能够支持用户在交互的时候传这个东西呢，还有我们要指导用户做什么样的操作。其实小二给用户解释这件事情是很高成本的，我们希望这个渠道可以把交互逻辑也承载起来，可以直接在这里面给用户推送。他应该到什么页面，做什么样的点击和交互，这样对整个服务的形态和模式会有一个办法，也许对用户是最优的，这是我们改造这个产品底层的出发点。

为了做到这个东西，底层会有很多产品技术的改造，里面特别详细的不做介绍，主要讲两个概念，一个是左边的对话引擎，一个是右边的决策引擎。我们的这些智能能力走到最后不管是人机协同还是人机交互，背后让能力真正能应用的无外乎是这两个，第一个就是机器和人的对话能力构建，通过底层知识的结构，通过对话学习，再通过跟用户的服务轨迹跟用户进行对话。第二是决策，可能有用户本身的因素，有业务设计的因素。对话和决策共同组成每一个用户走的流程具体真实的链路。

还有一个例子，当用户在打电话的时候到底是什么样的状态出现。发现用户需要咨询一个交易订单的时候，我可能直接把订单交易选择弹出来，用户看到这个订单以后，我是某一笔订单出了问题，或者某一笔交易记录出现了问题，也可以通过选择直接把交互和信息传递给系统。为什么会让他选择订单，因为这是业务逻辑决定的，就是要让用户来输出这样的信息，只不过这样的交互方式是对用户最好的，信息传递到后台以后，如果打电话可以通过语音方式直接给到他，界面端也会把相应的解决方案弹出来，甚至会把后续具体操作也弹出来，比如把这个自动扣款关闭掉或者怎么样，这样的交互流程是我们想实现的效率，这才是从用户视角最优的设计。

现在整个去中心化的资源网络，想要做到这一点还是有点难的。前面做过调研，为什么小二不能随时随地的服务，到底是受限于设备还是受限于技能，还是受限于我们对他的要求。比如说一些风险或者是安全的控制，这些东西都需要突破。我们建立一套平台，要解决刚才这些问题的时候，单点有效，但会受到一些限制，可能只在某一些点实现，没有办法做到随时随地服务。要做到随时随地服务，需要小二进入到体系的时候就开始做准备，所以我们在整个过程当中，想要让所有“去中心化能力”在上面发挥应用，真正让小二最终做到随时随地服务的状态。还有一个例子，当用户在打电话的时候到底是什么样的状态出现。发现用户需要咨询一个交易订单的时候，我可能直接把订单交易选择弹出来，用户看到这个订单以后，我是某一笔订单出了问题，或者某一笔交易记录出现了问题，也可以通过选择直接把交互和信息传递给系统。为什么会让他选择订单，因为这是业务逻辑决定的，就是要让用户来输出这样的信息，只不过这样的交互方式是对用户最好的，信息传递到后台以后，如果打电话可以通过语音方式直接给到他，界面端也会把相应的解决方案弹出来，甚至会把后续具体操作也弹出来，比如把这个自动扣款关闭掉或者怎么样，这样的交互流程是我们想实现的效率，这才是从用户视角最优的设计。

我们一开始从招聘和训练的时候，就开始用很多人工智能和用分散的能力去支持。比如一开始的训练学习，甚至面试或者去模拟这样的一些服务，都让他能随时随地的开始，这时候让他自己知道在哪些环境下用哪些方式可以直接的提供服务。离散部署的时候怎么让小二用起来，我们要知道哪些小二是在线的，是什么样的环境，他需要什么样的技能，能承接什么样的服务，能实时的和来的服务需求进行匹配，会把前面服务的需求分层分得很细，把后面相应的资源分配也做起来，这样两边匹配，计算出缺口。哪些东西可以喊小二服务，哪些事情让外包小二选择，哪些让社会上的小二上线，这样对整个离线系统进行计算。包括质量的控制，小二本身的管理薪酬和驱动体系，我们都希望做成线上化、平台化、智能化的模式。这样从整个管理上来看，把整个服务资源尽可能的放到了线上数字化，当只剩下自然人这个因素的时候，那就是一个业务逻辑的管理和上线的命令。

为了解决这个问题，从去年开始对整个工作平台做了重新的设计和重构，这个地方有几个理念。首先底层的工作平台把多端的概念打通了，无论是在PC上一体机甚至是手机上都可以相应的提供服务。只要有输入和输出，逻辑上就可以提供服务，这是我们想在应用层或者是到端层提供的效果。用户层可能在APP上打电话，可能任何部署了业务的入口进来，比如说钉钉或者是什么样的渠道进来，这个时候用户和小二的关联最终呈现在工作平台上，需要有这样的接口接起来。后面对小二的交互也好，对业务接入也好，大家都是比较资深的人士，我就不详细讲产品本身的能力了，这些东西真正做到可装配，随时随地能够拼凑出一个服务方案来，我相信是很多做服务运营的同学最基本的诉求。

为了能达成这些诉求，需要做很多定制化的开发，让组建化的东西成为平台的底层，可以往业务走得更深，让很多的业务逻辑提前预留出来，这时候通过组建的拼装也好，快速接入也好，就可以让业务跑起来。在不同的端、不同的设备上支撑这样的服务，这是我们想今年重点做出来，去达成如果再有一次疫情下我们的接通服务。

    一体化作业平台架构，大家看得蛮多的，大体大同小异。很多图真正要变成实际业务，还是有很复杂的过程。很多时候图和PPT上面确实很厉害的东西，但做业务的时候做步到。真正组建化的设计和平台化的设计需要一个很强的架构概念，真正影响架构的其实不是产品，也不是数据，也不是技术，实际上是业务。如果你在业务流程和业务设计上没有这样的分层和产品化的思维，你最终用的时候一定达不到想要的效果，我们做业务或者运营的同学有没有深刻的理解到每一个层为什么会这样分，为什么会有这样的方块，到底是一个产品的想法还是支撑了业务什么样的流程，只有这些东西足够清晰才能更好的运用于智能的能力，真正的去服务，否则的话得到的结论就是这个东西不好用，但实际上真的是不好用吗？可能不是。

我们很有幸生在科技爆发的时代，这样的科技让我们的服务和行业变得更加的美好！