首页>>厂商>>CRM软件厂商>>HOLLYCRM

如何提升呼叫中心的能力与效率

张泽潮 范华云 2009/11/02

　　从“解决客户诉求”角度看制约呼叫中心能力与效率的因素

　　呼叫中心最基本的工作形式是受理呼入，客户不会无故拨打电话，每通呼叫背后都有着客户的诉求。呼叫中心对企业的核心价值就在于通过电话的方式解决客户诉求，呼叫中心IT支撑系统的核心价值则在于帮助座席提高解决客户诉求的能力和效率。

　　中国的呼叫中心IT系统建设经历了三个大的阶段：建设重点从最初的呼叫平台（排队机、CTI、IVR）发展到业务系统（座席应用软件系统），再到如今的客服运营管理系统。客户的每类诉求都有其对应的IT支撑系统：客户咨询对应于知识库、客户投诉对应于工单、客户业务办理对应于营业账务系统、再加上用于呼叫中心内部管理的排班系统、质量管理系统、培训考试系统……，从表面看，呼叫中心的IT系统支撑已经非常完善了。

　　但行业实践表明，无论是客户、还是呼叫中心运营者、还是政府监管者都认为客户满意度还有待提高。根据某电信行业呼叫中心2009年3月全月182万通人工通话的统计数据显示，每天21%的电话号码至少呼叫人工座席两次，这些重复的呼叫总量占总呼叫次数的47% 。其集团总部08年处理2.2万起升级投诉中占全国市场总投诉量的10%左右。究其行业特点，对座席人员的高标准严要求也造成岗位人员的流动较高。数据显示，在整个呼叫中心行业，员工平均离职率竟然达到30%以上，差一些的高达50%。（数据来自第一财经日报）

　　为什么产生上述“消极性”行业现状呢？本文重点分析以下几个原因：

　　第一章：如何准确捕获客户诉求？

　　座席人员为何不能准确捕获客户诉求？原因是多方面的，有座席人员业务熟练程度的原因，有客户表述的原因，但是从企业管理的角度可以发现两个重要原因：

　　一、呼叫中心的知识体系一般以公司的产品/服务为中心展开，座席人员业务培训重点也是产品的理念、功能和特点等。客户诉求的具体场景与企业的产品/服务并不是总能有效匹配，座席人员遇到困惑时用于思考的时间并不能很长，客户的催促，通话时长的考核等因素促使他/她们尽快将客户的诉求对应为内部的某个产品/服务，这种单纯依靠个人判断能力方式难免会出错，决定了部分电话必然解决不了客户的实际诉求。

　　二、部分客户的诉求比较特殊（如部分客户在呼叫之前已经对企业有一定程度的不满），对于这类特殊诉求应该有特殊的应对措施。但是普通座席人员在通话前无法识别这类客户的特殊性，通话中仍尝试用常规措施来应对，加剧了客户不满，最终导致了投诉升级。

　　针对上述情况，IT支撑系统可以在如下三方面有所作为：

  1. 呼叫中心知识体系的建设应该有新思路，要能够引导座席人员定位客户真正诉求；

  2. 电话接通之时，IT支撑系统第一时间能够帮助座席人员分析客户的历史诉求；

  3. 电话接通之时，IT系统要能够识别特殊诉求，主动向管理座席人员预警；

　　下面将分别就上述建议展开论述：

　　呼叫中心知识体系新思路

　　呼叫中心员工的知识结构既要继承企业的知识体系，也要考虑到本部门特殊的工作性质。产品/服务是企业对形形色色的社会需求提炼和归纳后形成的应对措施，已经形成了本企业对客户需求的理论认知。呼叫中心则是要将理论再还原并且应用到具体的服务场景中。所以呼叫中心的知识体系，一方面要面向企业内部的产品/服务，另外一方面要有客户导向，能够识别、整理、归纳出各种典型的客户应用场景，并且将典型的外部应用场景与内部产品/服务建立起有机的逻辑关系。有了这样结构的知识结构，座席人员在识别客户诉求方面就容易多了。

　　呼叫中心的普通座席大多是靠座席人员来判断客户诉求，如果企业业务范围不宽，这个工作比较容易。一些大行业（如电信或金融领域）的呼叫中心，同时要为成百万上千万客户提供服务，经营上百种产品/服务，且部分业务内容相似性或者关联性较大，要想每次都依靠座席人员准确判断出客户诉求是比较困难的，IT系统支撑就可以大显神通了。

　　首先在IT系统中将典型的客户诉求配置进去，注意这里配置的是客户角度的典型诉求，比如客户呼入“投诉通讯信号不好”，IT系统将“信号不好”所有相关的因素都挂载到本客户诉求中，就会发现信号不好可能与网络有关，可能与客户终端可能有关，与客户是否处于特殊状态如周围有超常密集的人群等因素有关，在IT支撑系统中展现如下的分析引导图，从表面现象深入解决客户真实诉求就方便多了。

图一：客户诉求分析流程

　　上述处理流程图直接显示在座席工作界面上，并且关联内容可点击触发跳转，如座席人员与客户通话后排除掉其他因素，判断是手机终端导致信号不好，则点击“客户手机终端故障”，系统将进一步展现手机终端排查的分析流程图，让座席人员继续帮助客户处理问题。

　　客户呼入之后，座席人员要做的第一件事情就在IT系统的支持下先去捕获客户诉求，不用担心座席会混淆相似的业务类型，因为呼叫中心针对典型的业务诉求会做出非常详尽的引导流程，相似的或者关联的业务类型在此流程中会体现出来，座席人员可以点击，快捷地出入于各业务类型的引导图，通过比较、判断，最终定位出客户真正诉求。例如下文客户呼入本来想做“撤机”业务，通过业务引导图，最终定位到了客户的真正诉求，办理了停机保号业务或者移机业务。

图二：逐步引导客户，将隐藏的诉求挖掘出来

　　有了这种面向客户诉求的知识体系，有了针对表面诉求的分解和深入挖掘工具，每个座席人员在正确捕获客户的诉求方面就容易多了。

　　电话接通之时，IT支撑系统第一时间能够帮助座席分析客户的历史诉求

　　上述内容叙述的是利用新的知识体系帮座席识别用户的诉求，目前具有一定规模的呼叫中心已经能够做到每一通呼叫都可记录对应的通话原因，每个客户投诉都有完整的处理流程，IT系统可以充分利用这些资源，在电话呼入的瞬间，启动程序进行如下处理： 


　　这里还可以设计更多的客户呼叫与座席间的关联关系，以至于管理者认为有重要的关联关系可直接推送到管理座席，以提高呼叫中心的预警能力。有了这些提醒，座席人员在客户未开口之前，就能大致判断出本次电话的诉求，从而以更加从容地心态为客户提供服务。

　　电话接通之时，IT系统要能够识别特殊诉求，主动向管理座席预警

　　应该说多数客户诉求，是能够被呼叫中心通用的工作流程解决，但一些特殊身份的用户或者有特殊诉求的用户，很可能不满足于通行的处理流程和处理结果，普通座席因为受到工作能力和工作权限的限制，就需要得到管理座席的帮助。传统的做法是普通座席将通话实时转接到专家座席或者管理座席。

　　这种做法尚有改进的余地，IT支撑系统可以帮呼叫中心做到：

　　除了能预警客户的特殊诉求之外，IT支撑系统还能够发现统计性质的规律，如短时间内某通话原因暴增，某业务办理量异常，这些信息都主动汇集到管理座席的工作界面，提醒管理座席介入。

　　IT系统究竟应该向管理座席预警哪些内容呢？下面是一些建议：

　　依托智能化的IT支撑系统，呼叫中心不但可以依靠管理座席的经验和工作权限去妥善处理个别客户的特殊诉求，同时管理座席可以根据统计规律展现的问题启动对应的应急预案。例如某区域网络故障投诉激增，管理座席需要紧急联系网络管理部门了解基站运行状况，如果基站故障属实并且得到到何时可恢复的反馈，就可下发业务通知，告知所有的座席对于同类投诉的客户做好统一解释口径以提高座席人员效率，避免继续生成投诉工单，对已投诉的故障单做归并处理，避免让后台网络管理部门处理大量雷同的投诉。

　　智能化的IT支撑系统避免了普通座席处理超过本人工作能力和权限的事务，能保证客户的特殊诉求得到呼叫中心最高级别的响应，即使部分客户仍旧不满意，想将问题继续升级到上级部门或者行业主管机构，呼叫中心也已经掌握了这些信息，可提前与上级部门或行业主管机构主动沟通，避免事态继续恶化。

　　第二章：如何改变解决客户诉求过于依赖座席人员能力的局面？

　　前面所描述客户特殊的诉求向管理座席预警的做法，事实上解放了普通座席，让他/她们可以专心解决客户的普通诉求。即使在这个领域里面，也存在不少挑战，不同的座席工作质量和工作效率也大相径庭，所以很多文章重点论述如何提高了员工的沟通技巧，如何改善员工的工作环境，……，所有这一切，都指向一个目的：提高员工的工作能力。反过来，仍然从提高IT支撑系统支撑的角度考虑，如果能将各项工作内容梳理得井井有条有章可循，并转换为IT流程，那么只要普通能力的座席都能够胜任日常工作。

　　要实现此目的，IT支撑系统将高技能座席的处理能力“推送”给普通座席。第一章我们论述了IT支撑系统可以以客户应用场景为核心，通过分析流程分析客户诉求找到客户真正的需求。可以将这一思路推演下去，针对客户的某个具体需求，呼叫中心制定统一的解决方案。我们以下面的“预存话费换手机”为案例。通过先期沟通，座席已经知晓这是客户的真正诉求，只需要选择好“预存话费换手机”的业务类型，IT支撑系统会显示出集成在一个页面中的全套解决方案：处理此诉求可能用到知识库中的三个知识点；需要查询的客户信息，经常给客户发送的短信内容；处理此诉求可能执行的登记任务，…… 有了这样的解决方案，呼叫中心对座席人员的技能就不用有太高的要求。

图三：客户“预存话费换手机”的解决方案

　　这种解决方案思路很好，但是可操作性如何？例如呼叫中心究竟要整理出多少个解决方案？如果数量太多就会影响这个思路的落实效果。作者专门研究了电信级呼叫中心连续几个月所有的通话原因，规律如下： 　

表：某呼叫中心通话原因规律表

　　说明：通话原因个数比通话个数略多，因为一通电话有可能对应多个通话原因

　　也就是说，一个自动呼叫达30万，人工呼叫日平均6万，600个台席，千余员工的大型呼叫中心，只需要整理出50个左右的解决方案，就可以覆盖75%以上的客户诉求，只需要整理100个左右的解决方案，普通座席人员就可以很有信心地处理90%的客户来话。

　　上面是从主工作流程，以解决方案的手段谈了IT支撑系统如何降低对座席的要求，实际IT支撑系统在很多细节上也能够起到同样的作用。例如企业在推出新的销售策略时，通行的做法是将政策文件采编入知识库，供座席人员回答客户咨询。这种做法容易引发的问题是：座席人员遇到客户提问，要先找政策文件，再自我消化，每位座席人员根据自身理解或培训的要求进行解答，使得座席人员对问题的精准性和统一性很难掌握。从管理的角度来说，最好的方法是采编政策文件过程中，提前拆解出各项政策的知识点，形成客户常见问题的标准问答，以“问题--答案”形式采编在知识库中，这样座席人员就只需要在知识库中检索客户问题就能快速给客户以答案。

　　有了这样的IT支撑系统，相信不少呼叫中心的管理人员会认识到培训新员工不再需要这么长的时间了，呼叫中心运营中也不会再如此频繁地依赖专家座席了；相信不少座席会认识到，自己的工作压力比以前降低了不少。

　　第三章：如何提升呼叫中心处理客户诉求的工作效率？

　　任何一个管理者都希望用更少的投入获得更大的效益，那么呼叫中心该如何提高解决客户诉求的效率呢？本文认为客户诉求的标准解决方案会一定程度上提高工作效率。

　　除了引入标准解决方案带来的自然变化外，还有没有方法可以能够提高效率？答案是有的。人与人是有天然差异的，即使在标准解决方案的框架下，仍旧会有人表现得优秀，有人表现得一般，甚至会有人表现比较糟糕。所以想提高效率，可以从个体差异入手，通过IT系统的统计报表，知道某一客户诉求的平均通话时长和平均满意率，然后继续挖掘不同座席在此客户诉求上的表现，从中可以发现表现优秀的员工。 再听取优秀员工的录音，仔细总结他们与客户沟通过程中的要点，就会发现一些可普遍推广的规律和解决本客户诉求的最小通话时长。呼叫中心将通话时长推广到所有座席，成为此客户诉求的标准通话时长；将发现的规律推广到所有座席，帮助他们/她们去达标，呼叫中心在此客户诉求上的效率能有一些提高。再将排名靠前的一批客户诉求用这个方法梳理一遍，整体工作效率就能够上一个台阶了。

　　要实现上面的想法，只需要IT支撑系统中的统计报表支持以客户诉求为统计角度，并且实现一部分数据挖掘的功能，支持客户诉求与具体座席的组合即可。

总结

　　本文从“解决客户诉求”的角度探讨了提高呼叫中心能力和效率的方法，着眼点在于提升IT支撑系统的智能化和人性化，降低对座席能力的要求。实现了文中所述的IT支撑系统，呼叫中心就能够做到：


　　除了前面几个特点外，从人员的角度来说，有如下优点：

　　系统的呼叫中心，大大拓展了骨干员工的发展空间：普通呼叫中心的知识库采编员，在这里可发展为知识管理专员；普通呼叫中心的专家座席受理转接的疑难电话，在这里可成为业务专家，包装解决方案让成百上千个座席受惠；普通呼叫中心的管理座席处理个体客户的现场突发，在这里还可以制定或启动统计规律的紧急预案；普通呼叫中心的人看报表，在这里可以深入探究话务规律，制定工作标准；……

题外话

　　回顾全文，“以时间为维度详细分析员工的每个工作环节、形成科学意义上的工作规范、每个员工的工作完全标准化（这里是通过IT支撑系统实现的）”。这个理念是否似曾相识？没错，这就是管理学奠基人之一弗雷德里克.泰勒在其巨著《科学管理原理》里面的重要思想。管理界这几年提出来“管理要回归泰勒”，提倡通过工作自身的规律去从发现、去提高绩效。本文将《科学管理思想》的普遍原则与呼叫中心的具体实践结合起来，通过成熟的软件技术予以实现。上述通过提升IT系统支撑能力，来提高呼叫中心能力与效率思路，部分思路已经得到初步验证，取得了一定效果。特地将自己的心得总结出来，供同行参考。同时本文要向《科学管理原则》发表一百周年致敬(《科学管理原则》发表于1911年)，虽然过去了百年，这本书所提出的管理问题依然存在，它所总结的管理经验依然可用，它所研究的管理逻辑依然普遍，它所创造的管理方法依然有效。

作者简介：

　　张泽潮:中国联通北京分公司呼叫中心部部门总经理，经历了中国呼叫中心建设的全过程，拥有呼叫中心领域多年的运营管理经验，对呼叫中心的行业规律，IT系统建设有相当深的见地。

　　范华云:毕业于北京理工大学，获理学硕士学位，美国项目管理协会会员（PMP），在金融行业和电信行业工作多年。现任合力金桥软件技术有限责任公司呼叫中心实施部经理，对呼叫中心和项目实施两个领域有颇多心得。

通信世界


相关链接:
合力金桥软件被评为中国最佳人力资源典范企业 2009-10-28
合力金桥软件呼叫中心系统落户招商基金 2009-10-16
SaaS产品好才能发展好 2009-10-12
在线应用型呼叫中心助盖尔玛提升业务管理 2009-09-27
合力金桥软件推出HollyKM知识管理系统 2009-09-08