在整个事件中，滴滴客服扮演了举足轻重的角色，他们的工作方式将滴滴推上风口浪尖，直接暴露了滴滴运营和产品侧的重大问题。那么作为一名产品经理，我们可以做点什么来避免再次发生类似悲剧呢？

最近网上甚是热闹，滴滴顺风车事件、四川德阳女医生被逼自杀事件、龙哥KO事件、成都抖音小甜甜…各种社会热点在近半月相继发生，让人应接不暇……Who can tell me这到底是肿么了……于是百忙之中抽出时间也来凑凑热闹，就聊聊这次“滴滴顺风车事件”吧。

相信网上铺天盖地的消息已经让各位看官对整个“滴滴顺风车奸杀”事件有了充分了解，简单回顾一下：

8月24日赵某搭乘顺风车途中被残忍的司机先奸后杀，整个过程中赵某在危急时刻给好友发送了求救信息，好友收到信息后第一时间联系了滴滴客服，然而客服很磨叽，不以为然，完全一副事不关己高高挂起的态度，没有及时联系嫌疑人司机，也没有报警，最终导致了惨案的发生。

试想如果滴滴客服尽责尽职，及时联系嫌疑人司机给予相应震慑，也许这样的惨案就不会发生了。作为一名产品经理，我们可以做点什么来避免再次发生类似悲剧呢？

在整个事件中，滴滴客服扮演了举足轻重的角色，是她们的工作态度和工作方式导致了这场悲剧，是他们将滴滴推上风口浪尖，直接暴露了滴滴运营和产品侧的重大问题。作为出行服务平台的滴滴怎能不重视客服问题？如果您是滴滴的运营负责人、产品负责人或者CEO，您会怎么来加强客户服务部门的能力呢？

也许您心中有您自己的答案，倘若还没有，一起探讨~

探讨之前，先来了解一下“客服”是什么？

客服是“客户服务”的简称，在百度百科中是这样定义的：

客户服务（Customer Service），主要体现了一种以客户为导向的价值观，它整合及管理在预先设定的最优成本——服务组合中的客户界面的所有要素。广义而言，任何能提高客户满意度的内容都属于客户服务的范围。（客户满意度是指：客户体会到的他所实际“感知”的待遇和“期望”的待遇之间的差距。）

乍看这张结构图，是不是觉得客服这个工作在我们心中变得高大上了，有举足轻重的作用，根本不是和用户聊天儿这么简单一回事儿（相信大部分的童靴之前是这样认为的）。

透过上面这张图，笔者发现滴滴事件的客服在客服分类中属于语音人工客服。咱不聊深了，就聊聊这个语音人工客服在滴滴公司如何从运营侧和产品侧进行改造。

运营侧

产品方案源于用户需求，首先聊运营侧：

为了让各位看官更直观了解笔者的想法，先上图：

上图是基于此次滴滴事件所能考虑到的几个整改方面，欢迎各路大神进一步指正和交流。

简单梳理一下，如果我是滴滴的运营负责人，首先会明确客服部门职责和目标：使用一切合理、合法、高效的方式让用户满意；再结合这个目标，采取以下几方面的手段来达到目标：

（1）客服培训

职业素养：要求客服人员面对用户时必须有热情认真的态度，耐心倾听和解答客户问题。

专业技能培训：

• ①建立滴滴用户常见问题库，整理成册，供客服人员学习和掌握相关话术及应答策略，提高客服人员的服务效率；
• ②建立滴滴用户紧急事件处理流程，紧急事件用户安抚话术，紧急事件嫌疑司机震慑话术；
• ③紧急事件常识普及（如：各种紧急电话）；
• ④普通话培训。

（2）客服部门内部管理制度建立和完善

建立24h轮班制，全年无休为用户提供贴心便捷服务。

制定突发事件预备方案，成立方案小组，设组长及组员，明确具体流程责任人。一旦遇到紧急事件，一线客服人员可以第一时间联系到负责人，以便快速获取解决方案，降低不必要的危险和损失可能性。

（3）客服绩效考核制定

客服培训完成后进行考试，并将考试成绩计入绩效考核的一部分，占比30%。用户满意度评分作为最重要的绩效评估板块，占比50%。定期对用户进行满意度抽查回访，占比20%。

（4）客服相关软硬件系统的完善

违规司机黑名单功能：

110、120、119等紧急电话通过专线接入其内部系统，以便有关部门能及时收到来自滴滴客服的请求。

提高软硬件系统稳定性，降低客服和用户通话过程中的断线率。提高呼叫系统的通话质量，避免通话效果差，造成双方沟通不畅。通话过程自动录音保存，以便必要时作为重要证据。客户满意度评价功能（滴滴出行app用户端已有此功能）。

绩效考核功能：

• ①所有客服人员的培训考核均通过线上作答，并计入系统。
• ②用户满意度评价系统自动计算平均分。
• ③上级领导回访用户并记录回访结果，同时给对应客服打分。

建立滴滴平台用户常见问题知识库，以便客服和用户沟通时更高效。同时当数据量积累到一定量时，可引入智能客服自动应答系统，减少人力成本。

开发客服服务结果记录功能：每当客服和客户完成沟通完成后可及时在系统记录处理情况和处理结果，这样可以记录整个客户服务的过程，形成闭环，为后续客户分析提供大数据依据，有助于后期调整客服战略。

结合上面整理的客服部门运营整改思路，假如时光倒流回到2018年8月24日赵某遇害前的那一刻，整个故事也许就会按下面的流程发展了。

按照以上客服流程进行处理，如果滴滴司机不是真正的亡命徒，赵某基本就获救了。

产品侧

运营聊完了，接下来就得处理来自运营的需求。

关于滴滴客服产品整改我会以《用户体验要素》的五个层级来阐述设计思路。

客服系统架构分析图：

上图我分别从战略层、范围层、结构层、框架层、表现层五个方面分析了整个客服系统的产品规划，除了上图的规划外，其实客服系统是一个很庞大的体系，这中间还涉及了和各种企业内部其它系统的衔接，比如：CRM系统、呼叫中心系统、第三方（或自主开发）IM系统的数据互通互联。

在此不再赘述，我只对滴滴此次事件涉及的客服系统中，关于紧急求助功能的产品升级方案，结合自己多年的开发和产品经验进行具体方案的分析和设计。

通过上面的产品规划图，紧急求助功能涉及改造的系统或功能包含：人工客服语音功能、用户端紧急求助入口、工单系统的改造。

接下来进行具体紧急救助产品使用场景分析，流程图：

由于时间关系，具体的原型图我就不画了，原型图只是表面功夫，背后的流程和逻辑只要梳理清楚了，原型手到擒来。

关于设计中的一些边界条件和细节必须考虑，如以下几点：

• 如何避免用户乱用“紧急求助”功能，惩罚措施和规则如何制定？
• 和紧急机构对接系统，如果政策上行不通，怎么办？
• 是否可以在司机每次接单后，在乘客端和司机端app设置对应的安全提示、警示弹窗功能以提示乘客和司机，将不坏好意一方的坏念头扼杀在摇篮之中，减少类似事件的发生，降低紧急求助事件的发生？

……

如果继续深入思考，还有很多很多需要完善的地方，不再赘述，留给各位慢慢思考吧，也欢迎各位留言和我进行深入讨论和交流！

恰好在昨天2018年9月5日，滴滴上线了“安全中心”功能，咱顺便来看看：

以上为滴滴昨日日上线的“安全中心”功能，其中包含两个重要功能：行程分享和一键报警。

首先赞一下滴滴推出了此功能，态度和速度还是不错的，至于功能，还需要进一步深入完善。

接下来关于这个功能我提出几点可用性和实用性的疑问：

1. 滴滴此次奸杀事件受害人为24岁的成年女性，难道她自己不知道遇到危险了可以拨打110？那为什么她不打？我想可能她根本没有机会打，时机不行。那么可想而知，即使当时滴滴就有这个“安全中心”的功能，女主也不能自主完成呼救，所以我认为这个功能使用场景对紧急情况下的被侵害用户来说要求有点高，各位同意吗？
2. 相信大家都知道110也存在接通率的问题，如果用户即使打通了110的电话，但是一直占线怎么办？人命关天的关键时刻那么几分钟，甚至几秒钟都非常宝贵。

那借此机会对比一下笔者的方案使用的场景会不会更好？

此次滴滴奸杀事件中有一个细节就是当时受害人在被害前曾给朋友发送过求救短信，那这就意味着受害人没有机会打电话，但是有机会使用手机的其它功能。假设事件发生时，滴滴app已经有类似方案的紧急求助功能，那么女主抓住机会悄悄按了一下这个按钮，那么接下来会发生什么神奇的事情呢？

神奇的事就这样发生了，滴滴客服会做以下工作：

1. 立刻收到紧急救助电话提醒；
2. 立刻在后台客服系统能看到乘客基本信息（姓名+联系方式）、司机基本信息（姓名+联系方式）、车辆信息（实时定位+车牌+其他车辆基本信息）；
3. 立刻拨打乘客电话，未拨通，立刻拨打司机电话，也未拨通，果断通过专线报警并将以上客服所见信息同步给警方。

通过以上的几个操作，客服人员尽最大可能为受害者节约了宝贵的时间，争取到了可能的一线生机。

当然滴滴能在这么短的时间紧急上线安全中心功能也实属不易，相信未来滴滴会不断完善安全方面的产品功能和运营策略。

以上是笔者的浅见，欢迎各位大佬指正批评。

作者：Steven

校对：阿英

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

题图来自网络