如何落地服务三角？从需求、策略、渠道数字化出发

“还原事实即洞察。” —— 王一同教授
好好之前在《如何抽象、量化服务？服务三角》一文中介绍了如何抽象服务的三个核心要素，以及为什么要对服务进行抽象和量化。但前文只给出了“如何量化服务”的简要示意。
本文将更具象的阐述“服务三角”如何在运营过程中落地，这包括：

1. 如何数字化服务需求？
2. 如何数字化服务策略？
3. 如何数字化服务渠道？

图1：服务三角

开头先抛结论：

图2：如何实现服务数字化

我们先简单回顾一下服务的三个核心要素，以及核心要素之间的关系 —— 服务三角，分别是指服务的需求、过程与结果；服务需求，经过服务过程，得到服务结果。

● 服务过程包括3个核心的对象：策略、渠道、对象；服务渠道，依据服务策略，向服务对象提供服务。策略在某种意义上而言是一种对客承诺的载体，而渠道则是履约的载体。

● 服务结果比较好理解，就是我们通常说的“品质、效率、成本”，换言之：满意度、处理时长、单通服务成本。

一、需求数字化

可以说绝大多数的服务运营的过程，关注的重点都在服务结果，也就是我们通常说的品质、效率、成本。“我们要提升满意度”、“提高服务效率”、“控制服务成本”，相信大家对这些话并不陌生。那么如何达成更好的服务结果呢？

好的结果，应当由好的过程来保障的。而提供好的过程的前提，是我们能够正确的理解需求。所以，准确地理解客户的服务需求，是一切的起点。那么什么是服务需求？

抽象来说，服务需求是客户来找我们，或者我们去找客户的原因。

图3：服务求助与服务机会

“客户来找我们”比较好理解，比如说客户新买了一台电风扇，因为不熟悉功能找到店家问“这个电扇怎么定时？”这就是一个客户主动寻求帮助的过程。我们把这种情况，定义为求助类需求。通常说的服务承接，就是承接求助类的服务需求。 那么，什么是“我们去找客户的原因呢”？

一个比较典型的例子，就是汽车的故障召回。客户买了一辆汽车，TA可能当下并没有感知到有什么问题。但是厂商检测到了这款汽车的某个零件存在缺陷，然后主动的找到消费者，召回汽车替换零件，并提供相应的补偿。就是一个发现产品缺陷、找到客户解决问题的过程，我们把这种情况，定义为机会类需求。 通常说的主动服务，满足的就是这类机会类的服务需求。

典型的服务需求，通常包括“客观”和“主观”两部分的信息。客观是指“发生了什么”，主观是指“客户希望发生什么”

图4：场景与诉求

举个例子，消费者在电商平台下单后，商家超过48小时延迟未发货，消费者求助平台催促商家发货。在这个服务案例中，“商家超48小时延迟未发货”是一个客观的信息（我们通常把其定义为场景），“催促商家发货”是一个主观信息（我们通常把其定义为诉求）。

无论是求助类需求（客户来找我们），还是机会类需求（我们去找客户），都包括了场景（客观）和诉求（主观）两部分的信息。

弄清楚了服务需求的类型和内涵之后，紧接着的一个问题就是：我们应该通过哪些手段，来把服务需求描绘清楚？或者换言之，如何实体化服务需求？

（一）服务工单

对于客服中心而言，最基础的能力，是能够记录每一次服务。最基础的工单系统，是由作业单组成的。

比如说，上周好好家的冰箱出了点问题，冷藏室的门有点关不紧。维修人员上门完成维修后，给我开了一张“电器维修服务单”。 这张表单上记录了上门的时间、我家的地址、冰箱的型号、遇到了什么样的故障，维修的费用等一系列的信息。 这张作业单，就代表着维修师父的这次上门维修的服务行为。

图5：作业单实例 – 电器维修服务

作业单，实现了对单次服务的数字化。作业单这个实体，非常基础、非常有用、非常重要；它是其他服务要素数字化的基础。但作业单，能否充分实现对于服务需求的数字化呢？

从实践的经验来看，作业单不足以完全代表服务需求。因为存在着很多复杂的服务需求，无法通过单次服务作业得以解决。
举个例子：不久前，好好在京东下单了一条毛毯，支付方式是境外信用卡。后来在淘宝上看到了更喜欢的，就申请了退款。但毛毯的货款，过了很久都没能返回我原本的账户。

当我联系客服咨询这个问题的时候。因为这笔交易，涉及到了跨境支付，是一个比较复杂的问题。客服在给我提供服务的当下，并没有办法立刻解决我的问题。

他需要将我遇到的问题，反馈给后台部门处理；后台部门，可能要过好几天，才能给到我解决方案。在这个过程中，会产生多次服务行为（也就是说有多个作业单）、服务者可能会更替、我也可能主动进线催促（又引发新的服务作业行为和引入新的服务者）。 面对这种情况，如果仅用作业单来串联整个服务过程，就会比较复杂。

但以上过程的本质，其实并不复杂：用户提出了一个服务需求，企业通过多次服务作业，解决用户的问题。

我们可以创建一个需求单的实体，然后将作业单挂载在需求单下。通过这种方式，来追踪用户的一个需求被解决的整个服务过程。

图6：提交需求单实例

需求单，实现了对服务需求的数字化。

需求单包含2部分的信息：
1. 场景信息：什么情况下，遇到了什么问题？如上图中的“订单信息”、“售后类的问题”。

2. 诉求信息：消费者期望接受什么样的服务，实现什么样的服务结果？如上图中的“维修”、“价格保护”、“退货”、“换货”。
对于用户需求的梳理，要做到：相对标准、不重不漏、用户语言、及时更新。

• 相对标准：为了更好的进行服务设计，要对用户用不同方式、不同语言表达出来的相似需求，进行归纳总结。

• 不重不漏：虽然我们要对用户需求进行相对标准化的总结，但在梳理的过程中首先要保证需求和需求之间的边际尽可能清晰，这样才能提高用户表达出来的需求的准确性。同时还要允许用户表达差异性的、长尾的、非标准化的需求。因为公司业务、外部市场是在不断演变的，因此用户需求也是在不断变化的。只有允许用户表达“其他类”的需求，企业才可能不断地贴近用户、跟上市场。

• 用户语言：在归纳总结用户需求时，要使用用户听得懂的语言表述。这样做的目的，同样是为了提高需求表达的准确性。比如说淘宝的举报中心，中有两个举报类型，分别是“滥发信息”和“破坏清朗环境”；这样的表述，对于一般用户而言，理解成本是非常高的。

• 及时更新：刚刚有提到公司业务、外部市场是在不断变化的。因此我们对于用户服务需求的梳理，也需要不断调整、更新。
有同学可能会问：那存不存在一次服务作业，解决用户的多个服务需求的情况呢？

当然是存在的。还是以修冰箱为例，可能一次服务作业解决了2个故障。比如说既解决了冰箱门密闭性的问题，又修理了制冷管道结霜的问题。
但对于这种一次服务作业，能够解决服务需求的场景。解决了多个需求，其实只要将这多个需求，作为作业单的一个标签属性存储起来就好，并不需要新建“需求单”这样的实体。“最小可用”是系统构建中非常重要的原则。

通过需求单+作业单的“两级工单系统”，我们就能够很好的将求助类服务需求，描述清楚。

（二）客户之声

接着，我们来解决下一个问题：如果用户遇到了问题，不来求助怎么办？

换言之，如果用户不通过正式的服务渠道，来表达他们的服务需求，我们应该怎么捕捉到这个需求，进而提供服务。

通常来说，用户不来找客服解决问题的原因，可以归为两大类：一种是“我不知道怎么跟你说”，也就是服务难找的问题；另一种是 “ 我跟你说了也没用”，也就是服务溢出的问题。

图7：用户通过非正式渠道表达服务需求的原因

举两个例子——

服务难找：小红在网上买了一件连衣裙，可能在商品评价时留言“衣服褪色，把一锅衣服全给染了。”，而不是联系商家协商解决。消费者这么做，可能是因为不知道应该通过什么渠道解决这类问题。

服务溢出：亦或是在网上买了一件羊绒衫，到货后消费者严重怀疑“衣服的材质不是羊绒”，在申请退款无果的情况下，直接通过小红书吐槽“商品质量问题、服务态度差”，而不联系平台客服。消费者这么做的原因，可能是觉得既然都无法退款了，那平台肯定也解决不了我的问题。

从中长期而言，服务难找的问题，要通过服务可得性和易用性来改善；服务溢出的问题，要通过提升服务的解决能力来预防。

但处置问题的前提，是发现问题。因此，我们要找到用户可能表达服务需求的非正式渠道，然后通过技术手段将用户表达的非形式化的诉求转化为形式化的诉求。

以电商平台服务为例——

• 非正式渠道包括：12315、微博、小红书、商品评价、在线语聊、热线语聊等。

• 技术手段包括：内容采集接口/爬虫/接口人、语音转文本、语义/意图/情绪识别、槽位填充、预警工单自动生成等。

比如说，对于上述羊毛衫材质问题的服务溢出，平台可以通过在小红书上追踪笔记中的品牌关键词与负向语义/负面情绪的方式，捕捉到小红书上用户表达出的服务需求，进而主动联系客户解决问题。

这样一套捕捉用户非形式化求助需求的产品，我们将其称之为“客户之声系统”。

（三）障碍缺陷
现在还剩下一个问题：如果消费者遇到了问题，都不表达出来怎么办？

“1次投诉背后，有X个不满的消费者。”—— 这句话，好好不止在1个地方，不止3次，不止听到过5个版本。而且每个版本里面，X都大于等于10。
这句话想表达的事实其实很简单：当问题发生后，联系企业求助的消费者是少数，绝大多数消费者保持沉默，然后用脚投票，转身离开。因此，仅仅追踪消费者的求助是远远不够的。我们必须向前一步，追踪消费者遇到的各类问题，这些问题也被称之为“障碍缺陷”。

比如说，大家网购的时候肯定或多或少的都遇到过商家延迟发货的问题。但只要商家最终发货了，其实我们很少因这类问题投诉商家或平台。“延迟发货”其实就是一类障碍缺陷，它会显著的影响用户的购买体验。 当用户多次在A平台购买商品，感知3天才发货，7天到货；而在B平台购物时当天就发货，3天就到货时。TA就会在B平台买的越来越多，而在A平台买的越来越少。 因此电商平台就会将“延迟发货”定义为一类缺陷。当消费者遇到这类缺陷时，给予帮助和补偿；当商家将要产生这类缺陷时，给予预警。

图8：障碍缺陷追踪示意

通过“障碍缺陷追踪系统”，企业可以充分的挖掘机会类服务需求。进而实现：

• 主动的去帮助遇到缺陷的用户解决问题，从而挽回客户体验；

• 对缺陷发生原因进行定位，从而不断的降低缺陷率。

图9：服务需求与数字化系统

简单小结一下，服务需求可以划分为3类：
① 用户发起的求助，这类需求通过服务工单系统实体化；
② 用户表达的求助 ，这类需求通过客户之声系统追踪；
③ 用户遇到的障碍 ，这类需求通过障碍缺陷系统实体化。

二、策略数字化

需求数字化的目的，在于看清“消费者者遇到了那些问题？有什么样的诉求？”

当我们完成需求数字化之后，紧接着要做的就是策略的数字化。

所谓服务策略，其实包括2部分的内容：一部分是服务流程，一部分是解决方案。

• 服务流程，回答的是“消费者的问题诉求，应该去哪里解决？”的问题

• 解决方案，回答的是“消费者的问题诉求，应该以什么方式处理？”的问题

图10：服务策略 = 服务流程 + 解决方案

举个例子，小红网购了一件衬衫。收到货后发现衬衫的扣子掉了2颗，通过手机APP申请退货，商家以商品拆封为由拒绝退货，并提出可以赔付30元，让消费者找个裁缝修一下。小红非常生气，打电话联系到了平台客服，平台客服根据小红提供的凭证，支持了小红的退货退款诉求。 在这个案例中，APP申请退货、打电话联系平台客服，这都属于开启了“服务流程”。拆封后无法退货体验赔付30元、依凭证退货退款，这两者都属于“解决方案”。
有同学可能会问：拆封后无法退货赔付30元，这并没有让消费者满意，也算是解决方案吗？

好好认为，不能让用户满意的方案，也是一种方案。因为严格来说，服务所能提供的解决方案，是受到成本和效率制约的。企业不可能满足所有用户的所有诉求，因此也就不可能让所有的用户都感到满意。我们可以说这是一个不好的解决方案，但它确实根据用户的客观情况和主观诉求，给出了对应的方案。

对于消费者的服务需求，企业首先要从无方案到有方案，再在成本效率允许的情况下，将有方案变成好方案。

（一）服务流程

以“ATM无法取现，致电咨询”为例：

● 小红因为ATM机无法取现的问题，致电银行，系统后台根据来电信息创建了一个需求工单N1。

● 路由系统根据这个需求单的属性，创建了第一个作业单W1，并分配给了某个一线客服E1。

● 客服E1在和小红的沟通中，发现无法取现的原因是因为银行卡芯片失效，他无法帮小红处理该问题。因此他将这个问题转交给了负责给用户制作、发放银行卡的专员E2，与此同时创建了一个作业单W2。（此时W1结束，而N1因为需求未被响应因此未关闭。）

● 在E2帮助用户办理完重新制作、寄送银行卡的业务后，E2结束了作业单W2，并关闭了需求单N1。

如上案例，对于大多数的服务流程，都有3个非常重要的要素：

1. 入口：热线电话就是一种入口

2. 转交/升级：一线客服无法解决卡芯片失效问题，转交制卡转交升级的过程就是转交。

3. 完结：制卡专员完成重新制卡业务就是一次需求完结。

因此数字化服务流程，最核心的就是要记录清楚这3个要素。首先梳理清楚有多少个服务入口，并做好埋点，这样让每个需求单、工单都有源头。

图11：服务入口示意

紧接着，梳理工单的状态（待分配、处理中、完结等）以及完结原因（问题已解决、升级处理、问题未解决超时），让每个工单是否完结、何时完结、因何完结都有清晰的记录。

对于无法当下完结的工单，要记录清楚服务的流转过程，例如转交的原因、转交的对象、转交的时间等。与之对应的要建立起《转交的规则与规范》。

图12：转交规则示意

对于简单的业务，服务流程信息可以被记录在作业单或需求单上。而对于复杂的业务，可以专门创造一个实体（工作流程 – workflow_id）来记录整个服务的流转和作业过程。

典型的转交例如：智能转人工、自动化转人工、跨业务域转交、在线转热线、在热线转离线、升级处置等。

（二）解决方案

服务流程的目标，是帮助用户找到正确的办理柜台；而解决方案的目标，在于给用户提供合适的解法。

好好之前在回答《如何建立完善的售后服务体系与制度？》时有提到：一个企业的服务解决方案，其实是生长出来的。

图13：解决方案的“生长过程”

• 策略渠道一体：一开始企业还很小，老板既是销售，也负责售后服务，老板就是售后服务人员。当客户来求助时，提供什么售后服务，怎么提供售后服务都是由老板决定的。这时，服务人员与服务策略是一体的。

• 建立知识库：后来随着企业做大，逐渐有了专职的服务人员。提供什么样的服务和怎么提供服务的规则与制度由老板决定，具体的服务是由服务专员来提供的。因为规则与制度需要被记录下来，所以有了服务规范、手册、知识库、平台规则等概念。

• 梳理FAQ：在服务运营的过程中，我们逐渐发现客户的求助中，有很多共性的问题，因此服务团队沉淀出了一套《常见问题库》，也就是FAQ。FAQ可以帮助我们极大的提升服务效率。

• 建立SOP：随着业务的扩展，求助量逐渐上升，服务团队也逐步扩大。不同客服提供服务的一致性，越来越难以保证。对于同样的售后问题，A给出的解决方案可能是维修，B给出的解决方案却是退货。这对用户体验而言是很糟糕的，对企业的服务成本而言也是重大的风险。因此我们要建立标准的服务流程，来保证服务的一致性，也就是SOP。

• 服务智能化与产品化：与此同时，我们发现有一些简单的服务需求，可以通过智能机器回复，或者是服务产品的形式来满足客户，从而实现降本增效。因此，企业开始实施服务的产品化和智能化。

• 建立服务原则与服务文化：在标准服务流程运营一段时间后，服务团队一定会遇到的一个问题是：总有意外发生！FAQ和SOP总是无法覆盖客户的所有需求。由于客户的服务需求是紧迫的，而FAQ和SOP的生产需要一定的时间，所以为了满足意料之外的服务场景，企业会出台指南性的原则，用于覆盖那些规则未能覆盖的区域，避免出现服务真空。这就意味着企业开始建立服务原则与服务文化。

图14：解决方案的核心要素

在上述的“生长过程”中，其实就蕴含了解决方案的6个核心要素：

• 首先解决方案是为了满足服务需求的，因此方案的起点是用户的需求，这里就包含了2个核心要素①场景 和 ②诉求。

• 服务渠道（e.g. 客服）所提供的服务，其实是有依据的，无论是外化的公告，还是不外化的服务规范、服务手册，这些都属于③规则。是企业对客户的承诺。

• 有承诺，就要有履约。解决方案通过所蕴含的④能力，给消费者最终提供的⑤方案，以及方案给出后服务工单⑥完结的标准，来保障履约过程。
企业在“建立服务知识库”的阶段，就可以开始按照以上6个要素来梳理服务方案。在“建立SOP”和“服务产品化”的阶段，再将以上6个要素实体化，从而实现服务资产的可运营。

至此，我们可以将“需求数字化”与“策略数字化”两套产品结合起来，从而看清每一个用户需求的服务轨迹：

图15：服务轨迹的概念示意图

用户的每一个需求，由一个需求工单承载；需求工单的创建有3类来源：客户求助、障碍缺陷、客户之声。这个需求由n个作业工单承载；每个作业工单都有对应的：作业流程、服务渠道，与调用的解决方案。

从而实现服务运营的精细化——从场景运营，走向流程运营、解决方案运营。从解决方案运营，走向诉求运营、规则运营、能力运营、完结标准运营。

三、渠道数字化

上述服务轨迹中，有一个非常重要的要素，我们之前没做介绍，那就是“服务渠道”。

企业通过服务渠道，向客户提供服务方案，从而满足客户的服务需求。通常意义上的服务渠道，包含3大类：人工客服、智能客服与服务产品。

图16：服务渠道 = 人工客服 + 智能客服 + 服务产品

比如说京东的服务渠道就是非常典型的由这三个部分构成的：

● 服务产品：订单详情页面的退款按钮，就是“退换售后”这个服务产品的入口。

● 智能客服：点击客户图标后，接待用户的是“京东智能客服助理”。

● 人工客服：让我们在在线客服聊天框呼叫“转人工”之后，接待我们是“京东到家客服311339”。

图17：“服务产品”、“智能客服”、“人工客服”示例

（一）人工客服

有人说：“服务过程中，最难量化的就是客服。”这句话对，也不对。说“对”是因为人是非常复杂的对象。说“不对”是因为，如果学过人力资源的同学一定听过另外一句话“用工的要诀只有4个字——人岗匹配”。

而且客户服务是一个相对比较标准化的工作。 所以只要我们抓住“人岗匹配”这四个字，将“岗位”和“人员”这两个对象的核心特征数字化，我们就可以实现人工客服的数字化。

图18：“岗位”与“人”的数字化

岗位的核心要素有3个：职责、服务对象与权限。

• 职责的来源是工单，这个岗位负责处理哪些服务工单。

• 服务对象的来源是客户，这个岗位负责接待哪些客户。

• 权限的来源是服务策略，这个岗位给客户提供解决方案的时候，需要具备哪些权限，或者说能力。
快问快答：一位JD Plus会员，在京东购买暖气片后，通过APP的在线服务入口进线求助，申请7天无理由退货。这个案例中，大家可以抽炼出哪些职责

信息、服务对象信息，以及权限信息呢？

职责：电器类目、在线客服、售后场景、……

服务对象：JD Plus会员、……

权限：订单查询、售后处置、……

图19：“岗位三要素”示例

将职责、服务对象、权限梳理清楚，我们就完成了人工客服的“岗位画像”。紧接着，我们要做的就是“人力画像”。

客服人力的核心要素，也可以分为3类：胜任力、服务结果与收入留存。

• 胜任力的标准源自于岗位。

• 胜任力与岗位的匹配程度，就决定了客服小二的服务结果。

• 小二的服务结果，又决定了TA的收入留存情况。

图20：“人力三要素”示例

有同学可能会问，这么多信息，怎么获取？以下表格供大家参考：

图21：“人力三要素”的量化方式与运营手段

有一说一，岗位的数字化与人力的数字化，其实是一个资源投入挺大的工作。那“唯利是图”的企业，自然就会问完成了岗位的数字化与人力的数字化后，有什么样的价值呢？

好好在此简单列举几个应用场景：

1. 资源方案的生成：对于特定任务，圈选合适的客服人选。

2. 人力资源管理（WFM）的提效：排班、调控、互备、路由、支援

3. 服务品质效率的运营：从站点运营，走向小二运营；从小二运营，走向胜任力运营。

4. 远程管理：针对性的智能培训、管理干预

5. 信息反哺：招聘要求、培训设计、薪酬设计

（二）智能客服

过去智能客服主要是作为辅助的角色，回答简单的信息咨询类的问题（FAQ）。我们可以把智能客服，视作为一个执行力100% 的人工客服，从这个角度而言，智能客服的数字化，要比人工客服更简单。但随着近年来AI能力的不断提高，智能客服能提供越来越复杂的服务。对用户意图的识别，不再是简单的基于关键词，而是基于对自然语言的理解（NLP）。甚至在用户没有发送信息之前，就基于用户的订单信息、行为信息，提前给出答案（猜你想问）。在和用户交互的过程中，既包括流程式的引导，又包括了语聊文本、后台信息的预填。交互的模式也不再局限于文本，还包括语言、视频，同屏引导，甚至数字人形象等。

但万变不离其宗，评价智能客服最终的是2项核心的能力：理解客户、解决问题。

• 理解客户：所谓理解客户是指正确的识别/预判客户的意图，具体而言就是能够准确的标记客户求助时的场景和诉求。这项能力的提升，既依赖于算法能力，又依赖于大量的优质的训练数据。

• 解决问题：所谓解决问题，就是根据对客户意图的理解，快速的找到最优的解决方案，并顺利的将方案发送出去。而且在这个过程中，要尽可能的降低用户费力度，具体而言就是减少交互轮次，降低操作难度（e.g. 能点选的，不要输入）。

（三）服务产品

对于需求有一定体量，且策略可以相对标准化的服务需求，企业会将这些服务产品化，从而提升服务的效率，降低用户的求助成本。
对于网购而言，“退货/退款/维修”等售后类需求，就是一个非常典型的有一定体量，且相对可以标准化的服务需求。因此所有的服务平台都会有售后服务产品，帮助人工客服去承接大量的、高度类似的、可以自动化处理的售后类服务求助。

线上的服务产品，本身就是高度数字化的，每一个节点其实都可以被追踪和衡量。服务产品的数字化运营，其实和其他线上产品的运营是类似的。
比如说 ——

入口可得：产品的潜在用户有多少？入口是否易得？承载多少DAU、MAU？

高效解决：产品是否能真正解决用户的问题？用户在使用的过程中，费力度是不是可接受的？

产品的数据化运营，是一个非常大的议题，因此本文暂不做赘述。

简单小结一下~

我们可以通过以下17个实体，实现对于服务需求、服务策略、服务渠道的基本数字化：

图22：实现服务数字化的17个实体

1. 需求单（req_id）由用户、场景、诉求为主体构成。

2. 用户（user_id）包含：年龄、性别、城市、会员等级、信用等级、风险等级等信息。

3. 场景（situation_id）包含：订单号、业务域、障碍缺陷类型等信息。

4. 诉求（appeal_code）例如：退款、退货、发货、送货上门等。

5. 作业单（service_id）承接用户的需求（需求单），由服务渠道、调用流程、解决方案为主体构成。

6. 服务渠道（channel_id）可以分为3大类，人工客服、智能客服，以及服务产品。

7. 人工客服（service_id）包含：胜任力（基本信息、素质、能力、服务过程行为、经验）、过往服务结果、职级收入、所属岗位等信息。

8. 岗位（role_id）是将作业单分配到人的关键实体，包括了：服务人群（高客/普客/国际等）、权限（信息查询、处置账号、处置商家、升级、赔付等）、职责（业务线/渠道/业务技能/语言技能等）等信息。

9. 智能客服（robots_id）同样包含：服务的人群、权限、职责、所具备的能力（类似人工客服的胜任力）、过往的服务结果等信息。

10. 服务产品（product_id）通常蕴含着一个大量调用的流程、规则，或者是流程规则的组合。

11. 调用流程（workflow_id）包含：入口信息、转交/升级信息、完结状态、完结时间、完结原因（问题已解决、升级处理、问题未解决超时）等信息。

12. 入口（entrance_code）例如：在线、热线、主动服务工单等。

13. 转交/升级（transfer_id）包含：转交原因、转交对象、转交时间等信息。

14. 规则（rule_code）例如：交易管理规则、争议处理规则等。

15. 能力（ability_code）例如：退款、赔付、商品处置等。

16. 方案（solution_id）是指：对于特定的场景、诉求，基于平台规则，调用能力，给到用户的方案。

17. 完结标准（complete_std_code）例如：退款到账、赔付到账、商品下架等。

而这17个实体对象，需要8个系统模块作为承载：

图3：服务数字化的8个核心系统模块

越是抽象的东西，越容易放之四海皆准；越是具象的东西，越有时间、空间、场景的局限性。

以上内容，是好好对于平台型互联网企业客户服务的一些浅薄理解。若有纰漏，还望各位批评斧正。

 

作者鄢维凡,淘天集团。

本文刊载于《客户世界》文集2023第四辑•数据与智能。

转载请注明来源：如何落地服务三角？从需求、策略、渠道数字化出发

本文链接地址：https://www.ccmw.net/article/189420.html