这一个周末再次被滴滴刷屏了......

说再次，是因在100天时间内，第二个女孩因滴滴平台顺风车事件遇害。朋友圈都被滴滴事件刷屏了。短短的两天，事件新闻被互联网平台也传达到4线、5线城市。社会各界都开始纷纷转发针对【滴滴事件】的朋友圈，表达了各自的意见。

本次事件的特殊在于事件发生前已经有乘客给予平台举报司机有违规行为，但因平台未有处理造成司机继续接客，最终导致惨剧发生。

抛开这次事件对滴滴平台的影响外，作为产品人我认为更应该思考一个问题，滴滴平台的客服系统产品设计是否有可以再优化的地方？滴滴的客服系统甚至是否有产品设计的问题？

曾经，也带着团队落地过客服系统的产品设计。就滴滴的客服系统优化与业务流程的问题今天我们来聊几点

客服系统，前端面向的使用用户，后台面向的使用用户是客服人员、内部运营管理人员。在客服系统的设计上，基本的模块如工单处理、质检处理等；都是基于从客服人员、客服组长、客服管理人员不同角色。

先进企业对于客服的管理都会有两种方式

• 企业自身的客服体系，因为业务的复杂性客服属于企业内部人员

• 企业外包，将客服人员或部分客服业务移交给第三方（常见的例如运营商等）

相比服务的管控，自身的客服质量和权限都会比第三方好，但其资源的占用与成本也是较高的。

关于客服系统的设计案例，曾经有分享过一篇

客服系统的出现极大的降低了企业的人力成本，也提高了对用户问题答疑的效率。

功能的入口页面设计，传达了这个功能所解决的需求对于用户来说的重要性。那我们看看滴滴的客服系统入口在哪里呢？

这里我是用的英文版，中文也是一样的。点击进入了客服入口后对于用户的页面是如何的？这里做了一个简单的gif介绍客服进入页面

在线客服的入口放在了页面最后，点击在线客服，通过选择需要客服服务的订单再进入客服IM界面，将常见的客服faq问题以标签形式放在输入框前面。在线客服的入口（链接人工客服）常见的faq标签是可以帮助降低客服资源成本，也在一定层度上提高了客服问题解决。

客服系统在前端设计上，一定是需要整理出产品业务下，常见的faq系列问题知识库。比如滴滴的：扣费问题、车子未到问题.....，建立用户日常问题最多的问题，将其放在标签中。快速让用户进入对应的服务流程

滴滴在客服模块中，用户进入客服IM聊天页面后，用户进入后仍然不是直接与客服建立联系。而是先于机器人进行回答交流，通过点击切换人工或人工服务关键词，才可以链接到人工客服。

这样的产品设计流程，也是客服系统标准规范的前端页面流程。具体大体梳理的用户路径为

用户进入客服，可以通过2次的客服指引页面进入问题快速解决知识库，如果再解决不了的问题，用户也可以选择链接人工服务。（这里要注意的是，人工服务时间是有限制的）

但是！在这样的常见问题标签中，并没有出现我所期待的迅速报警、马上求救这样的标签。都是一些日常服务问题类似：计费问题、司机绕路等大概率事件

在发生第一次夺命事件后，如果仍然处于整治期，平台产品经理应该在客服页面提供快捷求救的入口

除此之外，关于滴滴平台客服的服务在线时间

作为一个用户随时可能在24小时内使用的服务类产品，他的人工客服在线时间如何呢？下图为截图

也就是说，滴滴的人工客服时间还是有时间限制的。这里的理由有可能是人力成本，也有可能是其他原因，最终减少人工成本。将用户问题在非人工时间给予系统解决。解决不了的问题，那就只有等别人上班来......

虽然是可以理解，但就滴滴“夺命事件”的发生。从产品业务场景下，24小时的人工服务其实是非常有必要的。因为我也相信大多数犯罪的案例都发生在凌晨或晚上

用户使用打车服务的时候，想找人工服务求救产生这样超高优先级的工单，平台应该能保证这样的重要类型工单是可以被对接的。

若设置按上面滴滴平台给予的人工服务时间段，显然犯罪分子还是会有机可乘。

对比携程、去哪儿网这样的服务类平台，虽然不同于滴滴平台的打车业务。但却在退票换票中，提供了晚上人工客服。

记得曾经在晚上1点钟到了旅游目的地点，却想升级已经定好的酒店，咨询已酒店房间更换问题。当初在拨号前还担心人工客服不在线，结果顺利的解决了酒店更换问题。体验极好

客服系统都会有一套完善的后台管理来控制、监督客服业务。这里以客服系统小能客服系统为例，每个客服的权限可以根据账号配置的角色来定。工单生成后，系统会有一套工单流转的路径。

流程路径是依靠不同的角色来判别。并在后台中，有一套工单列表，不同的角色对工单有不同的处理权限。

显然，滴滴的角色与权限，在工单处理中可能是有问题的。对于一线客服（面对用户的人员），给予的权限配置过于保守或太低，导致工单的流转到下一步的时候卡住，甚至一线客服人员可能已经认识到是一个重要且紧急的问题，但却没办法操控用户的订单信息。

上面圈出来的微博截图，可以看到是工单的创建角色权限导致工单无法流转。因为角色的限制，一线客服人员可能也无法查询到司机用户的基本信息。

需要流转到下一级才可以解决或查看对应信息。但可能因工单催办的提醒并不警醒，导致优先级高的工单生成了却无法立即解决。

在知乎中，也有同学提出这样的客服系统是否有问题？

作为产品经理来说，的确这样的权限与角色设计是有问题的。尤其是在服务类行业中，一线客户对于优先级特别高的问题应该是有权限去帮助用户解决。系统只需要提供记录即可，哪怕这一次操作是因“不讲理”司机或“野蛮”用户的作假，平台也应该尽可能解决当前优先级最高的问题。

导致了这次夺命事件在前天有人举报的情况下，仍然没有解决。猜测大体的理由除了对于工单优先级的处理有问题外，还有可能是工单的流程有问题。系统应该增加对于优先级高的工单，可以考虑开放提供给予一线员工操作的权限。

曾经和一个朋友聊起了麦当劳的点餐系统，我认为有个机制是滴滴平台在客服系统中是借鉴的。收银员点餐中遇到客户想取消订单或撤销食品的情况下，是需要店长（注意店长是随时在店里的）输入操作许可密码，才可以取消点餐或订单。一台系统在每个工作时间段支持5次的操作取消许可码输入。

一旦超过，店长的绩效会收到惩罚记录。

相对的，滴滴平台开放一线客服员工的工单或数据查看甚至操作权限，以这样的次数限制。既可以作为客服服务质检的筛选绩效之一，又可以保证紧急工单问题的解决。

当然上面的纯粹猜想和建议，迭代优化还是要基于滴滴客服系统中的具体部门也业务场景。

这是在朋友圈看到一个产品朋友给出的“夺命”事件解决方案之一，我认为是比较有趣的。利用siri的语音

siri通过语音可以进行呼救，拨号码110。当然这样的场景是否能够经得起犯罪现场的考量，还有待验证。不过这是可以在产品中设计让用户快速联系报警的入口之一。滴滴是否可以考量在系统中增加语音及时呼救？

我们都知道，在微信聊天中支持将位置发送给好友。对方授权后，可以即时的查看到自己的地理位置。

那设想一下，当做顺风车的你，系统默认会把你的位置给你信赖的滴滴朋友或其他你信赖的滴滴用户。

整体的搭车路途中，保持共享位置时刻与对方好友共享。一旦失联，好友与系统将第一个成为知情者

收到你协同行程的用户，也可以通过系统提醒立刻判断朋友是否安全到达目的地，还是真的遇到了意外导致共享失败。

在今天写这篇分享的时候，已经看到滴滴已经8月27号全面下线顺风车业务和免去了2位高管

我认为滴滴是需要时间的，第一个系统迭代的设计与开发事件，第二个是公众对于他的接受态度，第三个 如何设计出一套完善的客服系统业务流程

顺风车业务，我个人认为仍然是一个很好的产品，因为它解决了生活中的确打车难、打车不可控、打车价格黑等问题。还记得曾经没有滴滴顺风车的时候，打车从成都东站回家，那真的只有司机叫多少，你就得给多少，才能打车回家。

顺风车的出现，的确解决了用户在打车中的痛点。但这个产品考量的不仅仅是把打车这个路径跑通就行了。更重要的是这是在服务行业，服务行业中安全、质量、优质等关键词标签，是你需要给予客户的曾诺。

产品经理在考量这样的产品问题中，一定会有2个问题，是一个商业价值、一个是用户的利益。很多时候两者是矛盾的，在某个场景下，只能去之一。

身份为产品经理的你，你又会如何考量滴滴的客服迭代呢？还是说，一举关闭顺风车？欢迎聊聊

好的，今天的原创就在这里。我会坚持每周原创2篇～

另外Kevin建立了【坚持1年每天快速体验1款app知识社群】，每天快速体验1款app产品经理知识社群。进入该社群的同学除了学习别人每天的app快速体验分享外，还要坚持分享48个app（至少每周1个）坚持1年。