DysonU.K.的可靠性

    |     2015年7月12日   |   客世原创   |     评论已关闭   |    1155

客户世界|比尔·普赖斯、戴维·贾菲|2009-07-02

Dyson是英国领先的真空吸尘器制造商,它证明了从根源上应对投诉的价值。2006年3月它发布了如下的新闻稿:

韦斯特郡的真空吸尘器制造商Dyson宣布昨天又有42名员工辞职—因为它的产品越来越好了。位于威尔特郡马姆斯伯里的呼叫中心的员工也有可能辞职,公司认为主要原因是尽管销售上升,但是很少有人因为真空吸尘器和洗衣机出现问题而投诉公司。

42名辞职员工中还有一些来自配件输送中心。最近Dyson推出了DC15型直立吸尘器,它具有革命性的球形外观。这种吸尘器和其他产品质量的提升意味着,呼叫中心接到的客户投诉越来越少。

Dyson公司发言人说,“这主要归功于机器的可靠性能和很高的初次维修成功率。Dyson机器变得越来越耐用和美观。我们最受欢迎的机器的可靠性高达98%。这就意味着呼叫中心的来电数量很少,所以我们需要调整客服队伍的规模。”

Dyson提高自己的产品和服务,从而降低服务需求,这是一个很典型的案例。如果在现实当中展示了最好的服务,那么Dyson公司觉得有必要在新闻评论面前捍卫自己的行为。

框架

公司应该如何挑战需求?我们已经介绍了下面四个步骤:

(1)分析今天客户联络你的原因。

(2)通过建立闭合环路系统来挑战需求。

(3)计算能消除、自动化、简化或提高并予以衡量的事情。

(4)培训呼叫中心,使用“融化雪球”方法消除重复联络。

现在应该更为深入地研究“挑战需求”的每个关键步骤了。

步骤一:分析今天客户联络你的原因

第一个步骤就是要理解你的客户拨打电话、发送电子邮件、进行面谈、写信、抱怨或发表评论的具体原因。在这里我们将描述公司努力理解客户联络的原因,解释如何正确地把握细节并决定公司内的责任人。

1. 下拉式菜单

在过去的20年里,客户服务业努力创造方法分析客户投诉的原因,包括使用客户关系管理软件。不幸的是,客户关系管理软件使公司误入歧途,因为它有很多复杂的下拉式菜单如“性格”和“驱动者”,迫使代理在令人眼花缭乱的选项中进行取舍。最多的选项竟达2148个,代理必须在1或2分钟内浏览几百个选项,然后还要整理记录,才能与软件系统设定的情形相吻合。这样就无法保证准确性,而分析员将这些数据视为了解客户行为的线索;此外也影响效率,并耽误了客户的需求满足。

2. 原因而不是内容

此外,多数系统描述客户联络公司,以便能够学习或者抱怨的事情,根本不会首先考虑投诉的原因。例如,收集客户对“运输问题”的投诉,而根本不会关注船只可能带来的问题;记录“承运方延误”比“仓库延误”更合情合理,在通话时代理会查明问题,接着运营部门和执行部门领导就会依此理解令客户感到沮丧的事情。另外,几乎所有客户关系管理原因编码系统提供“其他”或“普通”两个选择,这样所有问题就被归为一个原因,根本无益于理解客户的投诉原因或帮助解决问题。所以公司缺乏足够的数据,不能做出实质性分析和重要的决定,只能试图根据直觉解决问题或开始新行动。

3. 没有理由或笼统的理由

然而,有些公司遭遇客户投诉的原因很多,其他公司却很少甚至没有。我们曾经工作过的很多公司都没有追踪或者报告客户投诉的主要原因。他们也想知道系统正在处理的交易数量,但这是两码事—交易数量忽视了那些与交易无关的询问、争论和问题。其他公司将问题归结于笼统的原因,如开票、付款、信用、召回和运输等。这些笼统的回答根本无济于事。如果对付款的投诉数量上升,那么究竟是些较好的投诉还是不必要的投诉?在这个层面上获得的仅仅是间接数据,无法提供帮助。

为了理解客户投诉的原因,公司需要遵循麦肯锡公司的MECE原理:解释必须相互独立(mutually exclusive)且完全穷尽(collectively exhaustive)。它的含义就是:每个来电只有一个“责任方”,而他的部门或团队直接“导致”客户投诉(第6章将深入讨论这个问题)。例如:

对于“产品已经丢失但是仍被订购”这一原因,责任方应该是供应链或采购部门(其中之一,不是两者皆有,我们马上讨论这一问题)。

对于“余额错误”这一原因,责任方也许就是IT部门。

对于“你是否……”之类的原因,责任方可能是网页设计或营销部门,它们都没有就公司提供的产品或服务做出清晰的解释。

挑战需求而非满足需求的最简单的一个方法就是采用零基策略分析每个来电,抛弃传统的“什么”标准,代之以全新的“为什么”标准,因为它才是较为精确的解释,能够利用典型的六西格玛、精益理论或其他分析技术对其进行仔细研究。

  通常公司专门为每个客户投诉类型设置一个原因编码(见图2-3)。我们发现拥有20~30个编码是最佳选择,易于记忆和区分(MECE),每个编码都使用客户的原话(不是公司的言论),如“我的东西在哪儿”、“密码遗失”、“速度变慢”或“程序错误”。
  
原先亚马逊有360个客户投诉编码,电子邮件投诉有300个,电话投诉有60个,有些是在营销经理、IT或其他法务部门的示意下设置的。公司经常增加或者删除编码,这就需要对代理进行培训,甚至还需要创建一个标准用于追踪“编码使用的规范性”。这些早期编码很少与责任人挂钩,这样公司只能每周公布“十大”编码,这些编码的排名很少发生变化,而且间接忽视了其他350个编码。公司决定委托一家纸巾厂的前任流程经理重新编制编码系统,结果精简为30个编码,可以直接输入客户关系管理软件系统,每个编码按照MECE标准附有责任方,令这些编码不再发生变化……这么多年后也确实如此。

接着公司根据成本的性质,将营业成本分摊到每个编码。例如,有的编码含有很多客户来电,平均通话时间为2分钟或3分钟;而其他通话时间为20或40分钟的来电耗费较多的成本,所以就希望予以核查甚至取消编码。在这个例子中,图2-3说明前37个编码的投诉数量呈下降趋势,但是它们都以编码的行为性质,也就是平均处理时间来划分的。很显然,这家公司需要关注第18和第29至31个的原因,而且需要花费很多时间解决这些问题;第18个原因和第1个原因所产生的成本相当,位居第二位。

步骤二:通过建立闭合环路系统来挑战需求

第二个步骤就是创建一个流程,将公司以及外部供应商与客户服务部门联结起来,从根源上挑战需求并提高服务。与很多闭合环路系统类似,你需要下面五个部分:翔实的报告、明确的责任方、目标、交流以及收益和影响。现在我们深入探讨闭合环路系统的五个基本要素。

1. 翔实的报告

很多公司每月或每周都会公布十大客户投诉原因或投诉编码,同时列出已经处理完毕的电话投诉和电子邮件投诉以及其他参与方的信息。因此管理层就很难看出趋势,无法与主要收入或发货商品进行比较,也无法从整体上分析这些问题。我们试验了很多不同的报告方法,但是最终还是选择亚马逊的Skyline模型:它包含30个编码,根据性质分摊成本。Skyline采用CPX格式清楚地展示了所有的编码(两页的篇幅),融合了所有的联络渠道,保留了过去六周的数据,这样就能清楚地看到最近的趋势(例如在账单循环里,四周的数据无法充分反映每月的影响)。
  
2. 明确的责任方

我们已经发现,10%的客户投诉是客户服务部门“导致”的(如错误的答复导致重复联络,我们将在步骤四讨论这个问题)。是谁导致大量的客户投诉?当然是所有其他部门了,因为它们的流程和输出影响客户。这些部门才是客户投诉的责任方。我们认为,当你创建新的编码系统时,需要确保一个责任方对应着一个编码,原因如下:责任人必须与客服部门通力合作,查找根源,寻找可能的解决方案,然后采取最有效的措施降低CPX。理想情况下,责任方向首席执行官汇报,这样才能领导他的部门寻找解决问题的办法或消除产生困惑的原因。但我们在此提醒你:很多责任方并不愿意承担相应的责任,在第6章将详细分析这个问题。

3. 目标

挑战需求的衡量标准就是CPX—联络比例指数。如前所述,必须使用CPX表示每个编码联络数量的下降,X也许包含很多内容,例如交易或者在途物资、账户或者订阅者。你要确保X最能够代表该行业的业务量。例如,对于一位客户拥有一个账号的公司而言,单位客户联络量也许是有效的指标。但是如果公司的账户、订单或者产品数量的增长与客户基础不一致,那么交易在计算CPX时就是一个较好的分母。

所以公司需要设立合理的衍生目标,以便降低不必要编码的CPX,同时提高必要联络的CPX。(参考下一步骤的价值刺激矩阵图。)每年不必要联络的CPX下降20%是非常现实的目标。但是在追求最好的服务的道路上还有一个不可忽略的事实,它与使用编码追踪不同等级的CPX一样重要—一旦消除了简单的联络(本章)、采用自助服务(第3章)或使用主动信息避免联络(第4章),那么随着时间的推移公司将会欣赏AHT较长的客户联络。客服资源计划人员常常忽略这一点,他们期待相同的平均处理时间(如果他们是快速商人,就会期待这个时间更短),这只会使代理疲于奔命并经常犯错,服务等级更低,客户满意度直线下降。

几乎每家公司都迫使代理更快地处理客户的来电(更高的CPH或更短的AHT),随着通话时间越来越长,这些古老的准则就不适用了,此时就会出现一种或几种情况:①为了符合要求,代理可能设置呼叫转移或者转发电子邮件;②代理会告诉客户,他们将会回电,但是却根本没有记录客户的电话号码,于是就带来无尽的投诉;③为了应付下一个来电者,代理随便给出了一个答案;④代理直接挂断客户的电话。代理们本身并没有多少恶意,这些做法仅仅是“达到指标”这一重压下的自然反应。在关键时刻,客服部门应该努力放松,继续使用AHT安排工作和员工岗位,针对每个互动采取动态个体处理时间(DIHT)。DIHT意味着,对于每个实时联络,公司必须将客户的重要性水平及问题与代理的技能和经验匹配起来。由于没有采用平均处理时间追踪所有客户和代理,在由具有一定经验的代理提供服务时,公司需要考虑评估此类联络和客户的合适方法。这三个变量的交叉关系会告诉公司一个合适的处理时间。我们将在第8章简要论述此种做法的难度。

4. 交流

现在已经讨论了基于活动的成本预算的翔实报告(如Skyline),展示了基于活动的成本预算,明确的责任方(每个编码对应一个MECE)和目标(不必要联络的CPX更低,必要联络的CPX更高,DIHT针对合适的处理时间),接下来我们需要创建最好的讨论会,使整个公司能够追踪结果、共享进度并计划新的解决方案。在我们的经验中,多数公司不会在月度管理层会议上谈论客户经验或客户联络的原因,公司在“前端”(吸引客户并销售更多的产品)或“引擎”(运营或制造)上花费了太多时间。也许公司不太关注客户问题的一个原因就是,十大原因并没有发生变化,或者他们认为自己多少“知道”事情的进展。

我们不敢苟同,因为每周召开的运营会议,由营销主管领导、典型的速度标准以及使用客服时间用来编制的CPX报告,这些并不能视为最好的服务。每周每个编码对应的责任方必须就编码排位上升(坏事)或下降(好事)做出解释;解释进步的原因同样很重要,这能确保正确的行为站得住脚,并且对其前景充满期待。每周五亚马逊公司都会召开这样的会议,但是很快公司就将开会时间提前,以最快地了解客户投诉的问题。在两次会议中间,责任方和他们的分析员与客服团队进行接触,了解客户来电、检查电子邮件内容、对比记录并寻找根本原因、探索可能的解决方案—这些都是周会讨论的内容。也许亚马逊很幸运—从11月中旬至圣诞节每天都会召开两次“假日战争”内阁会议,核查销售订单状态、网站性能、运输状况、客服等级和其他关键问题,并在每个假日结束之后仍然通过密集的会议表达对这些事情的关注。

5. 收益和影响

这个闭合环路系统的秘诀就是:确保公司创造持续收益和重大影响。我们需要打破惯例,在公司内部和供应商之间创造并持续利用合理的收益和惩罚措施,因为他们的行为可能造成不必要的客户投诉。下面是其中的一些观点:

责任方独自承担自己造成的客户投诉所产生的全部营业成本,包括寻求第三方的原因,如运输延误或供应商提供了有瑕疵的产品。我们发现这招确实管用—因为触及到责任方的利益,所以他们必须更多地关注客户问题并帮助挑战需求。

安排责任方参加公司的所有会议,解释他们的编码提高或者下降的原因,如何从客户角度和公司角度予以提高(也就是不要留给客服部门领导承担此责任)。

认可“最佳代理”,因为他们的表现对公司业绩很关键(见第8章的简短分析)。

报道“滚雪球”,识别哪个小组造成更多的重复联络,哪个小组消解了更多的重复联络。

庆祝快速胜利以及在内部备忘录和外部沟通渠道,如年度报告和博客等方面取得的进展。
  
步骤三:计算能消除、自动化、简化或提高并予以衡量的事情

随着挑战而不是满足需求的基础逐渐形成,我们能够决定每种联络类型所适用的正确方法。这就意味着,需要计算能够消除或转为自助服务和其他类型的自动化支持的事情,或进行预先警告,简化或流水线化,衡量并探索持久的收益。这是一门艺术,不是科学,即使理性的经理也无法就每种客户投诉的重要性达成一致意见。进行这种辩论是这个流程的重要组成部分。例如,当营销和产品部门的同事极力劝说他们,针对致电客户进行交叉销售或向上销售时,客户部门员工往往畏缩不前;他们知道很多都是客户的抱怨,需要小心应对,而不能进行额外的产品推销。这不是说电话推销或服务不能带来额外的销售机会—公司需要在四个关联要素之间寻找最佳选项:①客户的性情;②报价;③代理的技术;④原始的客户联络编码。实际上我们可以舍弃CPX转而采用XPC,也就是“我们如何才能提高单位联络的销售量”或销售转化率(促成销售的联络率),这是任何销售与预订服务所面临的热门话题之一。最后很多客户来电都被转接到销售部门,但这与销售部门没有关系,所以建议销售代表提升销售量也许不可能或是不明智的。

为了辨明每个客户联络编码的最佳安排,公司应该采取以下四项行动:

(1)召集一个跨职能团队,讨论其对公司以及各种类型客户的价值。这也许需要包括产品责任人、渠道责任人、流程责任人、客服、财务和其他公司部门,还需要包括提供部件或产品给客户的其他公司(如供应链)。

(2)对于每个编码的问题,采用简单的对错问答进行辩论,讨论激励机制对公司和客户是否有价值。我们认为应该避免1-7里克特等级(1-7 Likert scale),因为会产生分值为4的中立者,或者在价值和激励机制之间选择中间点。

(3)使用基于行为的成本预算评估每个编码的成本(也许暂时无法实施,因为一些客户关系管理系统研究并报告每个原因编码的AHT,而代理成本往往储存在其他的数据库;倘若如此,我们推荐将处理时间和成本划分为高、中和低,或者干脆跳过这一步,直接编写结果)。

(4)阅读2×2矩阵图,我们称之为价值-刺激矩阵,有四项行为可以选择。
  
通过使用这个价值刺激矩阵,公司能够设置一个清晰的路线图,挑战需求并确认特殊方向。一旦确定了联络的原因,就能找到解决方法。下面给出几个例子:

对于“我的包裹究竟在哪儿”的问题,多半是因为外部运输方没有及时递送货品,这对于客户和公司而言都是一个刺激(措施:消除)。解决方案就是分析外部运输方没有完成任务的原因,然后一起合作保证事情取得100%的成功;在价值-刺激这个1/4的方格里面,各方都不会有任何忍耐力。

对于“没有附结算单”的问题,多半是因为公司没有附上带有发票的结算单,这对客户很有利,但是对公司来说确实一个刺激因素(措施:自动化)。解放方案就是提供账户和在线结算单,由客户查看或打印,使公司减少邮寄成本。

对于“客户褒奖”,多半是因为公司出色地完成了某项工作,这对客户(否则他根本无须花这个时间)和公司(就能够吸引更多的客户)来说都是好事(措施:发掘或衡量)。最好的方法就是调查每个积极的反馈信息或来电,如有需要,从客户那里获取更多的细节。

对于“员工忽略我”的问题,从公司角度而言是有价值的信息,但对客户而言却是一个刺激性因素(措施:简化或提高)。解决方案就是安排更多的培训和监管,甚至可以微服私访调查此类行为。

价值-刺激矩阵四个组成部分的综合比例,我们采用联络优化程序设计了这个矩阵;只有22%的联络是对公司和客户有价值的,剩下的78%的联络应该予以自动化或干脆消除,或者进行简化并提高关键运营程序。

我们需要认识到,一刀切的方式有其局限性。你需要深入发掘探究根源,尤其是那些导致刺激性反应的联络。当你开始深入探究这些根源时,如果发现很多问题,那么不要感到惊讶,有些问题可能分散在四个区域内。例如,在一家公司内,我们发现本来可以予以自动化的联络到头来却成为问题的根源,也许自动化是正确的选择。责任方思考根源有助于他们确认积极的解决方案,认识到谁是真正的责任人。

步骤四:通过“融化雪球”消除沟通渠道里的重复联络

客服部门或者技术支持部门的行话就是“一次成功解决率”或“一战告捷”。这个表达意味着客户在联络公司之后满足了自身需求。单方成功解决(FCR)考察第一个人能否自己解决问题而不用移交给其他专家解决。所有这些标准都很合理,但是也有三个不足:①很难从客户角度进行准确的考量;②在压力下代理可能视客户为“猎物”,并提供虚假的解决方案;③他们不会关注或分析其他要素,如重复联络的比例。我们认为重复率是衡量解决方案更好的标准,因为它表明了解决方案的缺失、失败及其影响。

较高的FCR也会产生错误的安全感。即使你的FCR是92%,也说明你还有8%的错误。对于一个200人的呼叫中心而言,这就意味着每月有1.9万个重复联络!其他采用六西格玛的公司努力在它们的制造部门和其他部门实现“4 9誷”的精确度,但这与FCR不同。我们仍借用精益生产的内容—将多数客户联络视为公司产品和服务以及运营的缺陷,关注重复联络会带来很多的收益,我们使用一个简单的类推,类似于众所周知的滚雪球。

当一个雪球沿着山坡向下滚动时,它的速度逐渐加快,体积也越来越大;如果此时你站在山坡底下而且没有让开,那么你将被撞飞(或至少浑身是雪)。其目的就是,当代理接到重复联络后,帮助他们彻底解决问题,防止雪球越滚越大,也就是要学会融化雪球。亚马逊的滚雪球结果令人印象深刻:在四年的时间里,它的重复联络下降了80%,重复联络所占的比例微不足道;心情愉悦的代理无须应对心里不安的客户,而如果客户很高兴,也无须再次沟通或再次收到电子邮件。

我们描述一下滚雪球、雪球比例和能节省的成本总额。第二个(或第三个甚至第四个)代理碰到同样的问题,由于上一个代理没有自己诊断原因或是他先前犯错,那么新代理需要花费同样多的时间融化雪球,这样它才不会继续滚落到山坡底下。这就意味着CRM系统需要有一个“雪球”的旗帜或者标志,这样才能调整新代理的诊断标准。如果新代理认为他已经解决问题,那么需要发送一份“滚雪球报告”给先前代理的上司以及培训和质量控制过程,这样就能分析滚雪球的根源,先前的代理能立刻明白事理,避免再犯同样的错误。

接着公司很方便地计算“雪球比例”—比较代理、团队、小组、中心和公司(如外部供应商),是谁开始滚的雪球,谁最终融化雪球,谁需要更多的关注,收益和影响是什么。亚马逊的第一个外部供应商工作非常努力,确保比内部中心融化更多的雪球;一旦失手,雪球就会滚进公司内部,砸向所有的部门!

你也许怀疑:是否应该额外花费时间融化雪球。放心,这是物有所值的。只有消除重复联络,公司才能有所收益(这就证实了FCR的含义)。通过获取和分析数据,公司能够减少滚雪球的原因,如究竟是个案还是普遍现象(例如员工无法理解或执行的程序)。融化雪球的其他收益包括较高的客户满意度和较好的口碑。

转载请注明来源:DysonU.K.的可靠性

相关文章

噢!评论已关闭。