《漫谈CRM体系化建设》系列共分五篇，前三篇讨论了企业客户管理的基本业务问题和新客户开发管理问题，以及如何进行客户分析并实现精准营销留住客户。本文是第四篇，讨论客户服务与系统建设相关问题。

四、如何服务客户

如果我们将企业的客户按照下单频次和客单价两个维度切分成四个象限，划分为A、B、C、D、E五个群体，企业的核心诉求之一，便是找到更多的潜在客户群体A，转化为客户群体B，并努力使客户群体B向客户群体E转移，尽量留在E的位置。

本章讨论如何结合系统提升客户服务体验，以保证客户在B、C、D、E的位置不会轻易因为服务问题流失。

1、客户服务综述

客户服务包括售前、售中、售后三个环节的服务，售前、售中服务更多属于销售职责，本文主要讨论售后环节的客户服务。

售后环节的服务有如下要点：

a、问题与责任的界定是否合理

b、赔付与补偿的规则是否合理

c、客服的话术、技能和态度是否合格

d、问题处理、流转是否及时高效

e、问题处理的过程是否透明

a、b、c是业务部门需要解决的问题，d、e需要通过软件技术落地解决。

售后环节的客户服务，本质还是业务问题，对赔付规则的制定，对问题责任的界定，决定了客户对服务结果是否满意。客户服务也涉及到软件问题。合理的软件架构，高效的信息流转和处理机制，良好的客户接触体验和信息透明，决定了客户对服务过程是否满意。

针对售后工作企业还需要思考如下问题：

a、如何引导客户自助解决共性问题或常规问题

b、如何针对不同客户设计差异化的服务标准，合理分配运营资源

c、如何通过事件管理机制识别企业自身管理运营问题并改进解决

a、b是实现精细化客户服务要解决的问题，c是企业识别并解决自身问题最重要的操作方式。

我们一再强调，企业的内部资源是有限的，如何鼓励客户自助服务，如何识别客户的重要程度，实现差异化服务，从而最有效的分配、使用内部资源，是每一个企业都需要认真思考的问题。对售后客服来讲，首先需要通过机器人客服，Q&A推荐，IVR（Interactive Voice Response）技术，鼓励、引导客户自助解决遇到的问题，避免人工介入，节约人力；其次要识别不同等级的客户，对不同级别客户制定并执行不同的服务策略，保证核心客户群体的稳定。

另外，售后客服是企业和客户沟通的最重要窗口，是了解并改进企业自身问题的最好渠道。售后问题表面上是客户反馈的商品或服务问题，背后代表的可能是企业的经营、管理、运营各方面的问题。例如商品近期大量退货，有可能是物流环节出了问题，也有可能是库管环节出了问题，也有可能是采购环节有问题。企业要重视所有的售后反馈，识别问题的严重程度，通过问题的流转处理以及升降级机制，锁定重要问题，不仅要解决售后客诉，更需要彻底解决背后的管理或运营问题。

讨论客户服务管理，就不能不提ITSM和ITIL。如何结合IT技术实现最佳客户服务，伴随着信息化几十年的发展，有了充分的总结和沉淀。客户服务管理是ITSM（IT Service Management）思想中的一个重要板块，ITIL（IT Infrastructure Library）标准是对ITSM思想的具体贯彻和执行。简言之，ITSM是一种IT如何服务业务的理念，ITIL是落地执行标准和参考。ITIL标准包含了事件管理、配置管理、变更管理等方方面面企业IT管理建设规范，以及与业务结合落地的执行标准和指导。全世界所有的大型企业，尤其是500强企业都执行了基于ITSM思想的ITIL标准，实现了IT技术和公司业务的结合落地。ITIL标准有大量的管理软件协助执行实施，比较知名的软件公司有BMC，ServiceNow，Atlassian（Jira就是这家公司的产品），国内的公司和产品更是多如牛毛。大型企业的客户服务体系，包含了基于ITSM思想的ITIL管理软件，结合CallCenter系统，实现对业务尤其是客户服务的完整支持。

ITSM与ITIL涵盖范围太庞大，对于ITIL执行人员有专业的资格考试认证，一般中小型公司没有能力实现全面的ITIL管理，也没有这个必要。对于成长型互联网公司，实现轻量级工单管理以及CallCenter、CRM集成，支持业务已经绰绰有余。

2、信息孤岛与主数据管理

我们首先介绍软件建设中常见信息孤岛现象，信息孤岛会直接造成客户体验问题。

企业的系统建设都是随着业务的发展逐步完成的，受限于当时的业务状况，开发资源，设计的IT架构在当时的时点有可能是合理的，但随着业务的发展，可能会变得越来越不合理。我们来看看下边的例子，某公司最早经营连锁超市，客户资料存储在CRM系统中，客户可以通过微信公众号查询自己在CRM中存储的会员信息。公司后来又开展了线上电商业务，线上客户资料存储在线上电商系统中。公司同时还创建了电销中心，由于有两套客户数据底层，公司为了让电销业务员在CallCenter系统中能查询所有的客户资料，将两套数据底层同步到CallCenter的客户数据库中。此时的系统架构如下图。

可以看到，随着业务的发展，公司出现了三套客户数据库，一套保存在CRM中，提供微信和CRM系统调用，一套保存在在线商城中，提供在线商城调用，第三套是前两套数据库的冗余合并，提供CallCenter调用。

这样的系统架构以及数据流设计，是为了支持当时的业务能够快速开展，但随着时间的推移，弊端暴露无遗：

1. 线下客户使用在线商城需要重新注册
2. 线上客户在微信公众号查不到自己的信息
3. 客服查询的客户数据有延迟
4. 客服无法协助客户修改资料
5. 客户数据冗余，分析人员无法做跨渠道分析

客户数据就像一座孤岛一样存储在企业内部，给其他系统的使用带来障碍，对业务产生影响，这就是应用系统建设中常见的信息孤岛现象。信息孤岛是指因为各种原因，每个应用系统独立建设时，没有和外界系统做良好的打通，导致应用系统之间存在流程或数据的孤立性，最终给业务带来严重影响。解决数据信息孤岛的方法很简单，就是只保留一份客户信息库，这份客户信息库保存最核心的，与业务单元无关的客户属性和资料。至于积分、会员等扩展属性依然由各个应用系统维护管理。调整后的应用架构图如下：

将客户信息库独立，商城、CallCenter、CRM和微信公共号通过统一接口调用Customer Profile存储的核心客户档案，不论客户或业务员从哪个端口查看或修改信息，变化对其他端口都是透明、实时的。实际上这就是客户主数据管理MDM（Master Data Management）的设计理念。

通过主数据解决了数据信息孤岛，可以保证客户在公司的任何系统、任何接触点都能看到自己一致的资料与描述，保证业务员看到的都是最新的客户信息，保证企业内部人员不论在任何系统，任何场景对客户的认识、理解都是一致的。

基于客户主数据，还可以实现360客户视图项目。将客户信息高度集成整合，作为企业级服务，为各个业务部门和团队提供准确、全面的客户信息呈现。

对主数据设计思想更全面的介绍可以参考之前的文章《深度｜从一个故事说起，谈谈企业应用架构的演变史》。

我们对架构图更新后如下。

3、工单与事件管理

工单系统，是管理、维护、跟踪客户问题的平台。在大型企业，工单系统的服务对象包括企业内部员工、合作伙伴、客户，实现对事件的统一化、规范化管理和处理。工单系统加CallCenter系统，是完整的服务台（Service Desk / Help Desk）解决方案，可以实现企业对问题、事件的定岗定责的快速处理与响应。

工单系统能做什么？我们可以举几个例子来方便大家的理解。

例子1：

你购买了某公司冰箱，一段时间后发现出现故障，致电400热线。客服根据你的描述，检索知识库，寻找解决方案。如果无法解决，客服将工单转发给你所在区域的服务网点，服务网点再分配工单给对应的维修人员。维修人员初步判断问题，与你沟通，完成上门维修，你针对服务进行评价。由此可见，完善的工单系统与流转机制，让企业能够及时跟进处理你的遇到的问题。

例子2：

你购买了Oracle的ERP产品，软件出现严重生产故障。你在ERP的知识社区提交事件请求，很快，印度的技术支持工程师在社区回复你，尝试指引你解决问题。你采取方案后发现无效，并且明确表达事故级别严重，需要马上解决。印度的工程师将问题升级，触发流转到中国的Oracle服务团队，中国团队直接电话与您取得联系，确认问题表现，并根据您购买的Oracle服务级别，安排工程师进行现场支持，最终问题解决。由此可见，工单针对问题紧急程度，以及客户购买的对应服务，会进行升降级处理，通过机制和流程实现不同级别的响应。

在以上两个例子中，如果您遇到的问题是新的问题，事后对方企业会将问题和处理方案沉淀到知识库，给下一次问题复现提供参考。如果您遇到的问题，被定级为产品设计缺陷，有可能会引起企业内部的产品或生产制造部门的持续跟进处理。

可见，设计良好的工单系统，能够让企业采取合适的方式，让合适的人员，在合理的时间，有效的处理客户问题。

工单管理，可以设计的非常复杂，也可以设计得非常简单。在ITIL标准中，对事件（Incident），问题（Problem）有不同的界定，例如，服务器宕机是一个事件，表象是多个客户电话咨询问题。对事件、问题的清晰界定，可以让企业实现更准确的精细化运营，但是管理成本比较高，会在一定程度降低工作效率。国内的工单系统，通常不区分事件和问题，统一采用工单的概念，可以方便企业理解和快速使用。

工单系统和CallCenter系统，在不同企业对应的核心业务流程非常相似，市面上有大量成熟的解决方案，不论是轻量级或重量级系统，都可以经过个性化配置支持业务。工单和CallCenter都属于高内聚系统，和外部系统的耦合性低，通过API即可实现与其他系统的轻量级可拔插式对接，因此不建议企业自行开发，通过购买现成软件完全可以支持业务。

一般工单系统作为CallCenter的子系统或子模块管理。对于CallCenter中的质检模块、回访模块等我们不再介绍或标注，只更新工单管理模块。更新后的应用架构图如下。

从软件层面来讲，工单系统和CallCenter系统，在CRM体系建设中，相对而言是最简单的部分，因为涉及到的业务比较成熟稳定，业务模式基本趋同。主要的难点在于呼叫中心的团队管理，以及服务流程和服务标准的制定和落地执行。

作为外呼营销的CallCenter系统，和CRM在任务管理、精准营销上有很多需要打通联动的地方，设计的难点在于营销策略的制定和任务机制的设计，外呼功能都是标准化功能。

针对客户服务和软件系统结合落地的进一步深入学习，读者可以查阅ITIL相关资料，或直接研究相关软件，例如BMC、网易七鱼等。

相关阅读

《漫谈CRM体系化建设1 – CRM与客户管理综述》

《漫谈CRM体系化建设2 – 如何开发客户》

《漫谈CRM体系化建设3 – 如何留住客户》

《漫谈CRM体系化建设5：CRM体系化解决方案》

插播一条广告

插播一条广告

大家好，我是《决胜B端》作者杨堃，曾在VIPKID任产品总监一职。在工作中，遇见有很多优秀的B端产品经理，但缺少体系化、针对B端产品的实操训练，在成长中走了许多弯路。

我努力将自己多年做B端产品的经验提炼总结出来，和起点学院联合打造了一门B端产品体系课——《To B产品实战训练营》希望能给需要的同学一些实质性的帮助。

帮助大家构建B端产品知识体系脉络，掌握B端产品建设，从业务诊断、需求分析，到抽象建模、设计落地的全过程的方法思路，最终直接应用于工作实践。

扫码即可报名，还可为大家争取到的专属优惠~

立即抢座，报名成功后即可领取详细课程资料！

作者：杨堃（微信号公众号goYangKun），9年互联网研发、产品设计经验，曾就职于传统外资保险公司，百度，现就职于vipkid。

本文由 @杨堃 原创发布于人人都是产品经理。未经许可，禁止转载。