2024年第一辑
当前位置:首页 - 期刊 2023-25年 2024年第一辑 - 正文

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

发布日期:2024-04-01浏览人数:0

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

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

1.png

开头先抛结论:

2.png

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

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

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

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

一、需求数字化

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

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

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

3.png


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

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

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

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

1-1.png

图4:场景与诉求

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

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

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

(一)服务工单

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

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

1-2.png

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

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

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

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

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

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

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

1-356x768.jpg

图6:提交需求单实例

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

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

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

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

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

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

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

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

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

(二)客户之声

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

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

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

1-3.png

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

举两个例子——

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

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

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

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

以电商平台服务为例——

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

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

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

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

(三)障碍缺陷
现在还剩下一个问题:如果消费者遇到了问题,都不表达出来怎么办?

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

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

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

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

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

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

二、策略数字化

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

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

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

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

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

举个例子,小红网购了一件衬衫。收到货后发现衬衫的扣子掉了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个要素。首先梳理清楚有多少个服务入口,并做好埋点,这样让每个需求单、工单都有源头。

1-7.png

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

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

(二)解决方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

作者鄢维凡,淘天集团。

本文刊载于《客户世界》文集2024第一辑•管理与运营。