我们试着给滴滴顺风车设计了一套防风险策略

　　欢迎关注“创事记”的微信订阅号：sinachuangshiji

　　文/张成翼 赵键

　　来源：三节课（sanjieke01）

　　又有一位女孩在滴滴遇害了，又是顺风车。

　　8月24日，赵某乘坐滴滴顺风车，从虹桥镇前往永嘉。14：10，赵某向朋友发送消息“司机开的山路没有一辆车，好怕怕。”并在5分钟后向另一朋友发出“救命”、“抢救”的求救信息。

　　15：42，朋友多次联系赵某未果之后，开始向滴滴平台（4000000999）拨打电话。其后又曾15：42、16：00、16：13、16：28、16：30、16：36、16：42七次联系滴滴，未果。

　　16：00左右，考虑到事情紧急，赵某朋友X某于永嘉上塘派出所报案，期间警方通过X某手机在表明警察身份的情况下，与滴滴平台沟通要求获得司机具体信息（电话、车牌等），但无果。直到一个半小时后，17：35分，赵某的母亲向乐清派出所报案，然后滴滴方面才向乐清警方提供了必要的信息。

　　17：42分，滴滴客服称已联系到司机（嫌疑人），并称，乘客并没有坐上车。

　　8月25日凌晨4时，警方抓获犯罪嫌疑人钟某 。同一日，滴滴发布道歉公告，称“有不可推卸的责任”

　　8月26日，滴滴发布自查公告，称“27日起全国下线顺风车业务，并开除顺风车业务部总经理黄洁莉，客服副总裁黄金红。”

　　案件本身并不复杂，案件的处理也没有出现纰漏，整个过程中最大的问题在于，滴滴作为一家日交易单数上千万，肩负着相当一部分公共出行需求的企业，它的表现和作为在外界看起来实在太差——

　　1、在“空姐遇害案”之后，滴滴并没有真正提出切实可行的解决方案，它甚至重新上线了明确提出要彻底封禁的乘客头像。

　　2、在案件处理过程中，滴滴客服系统的低效和推诿，滴滴的风险防范机制的疏漏，实在是触目惊心，很难想象这是一家估值5000亿的互联网企业应该有的表现。

　　3、滴滴在整个过程中，是有可能预防事故的发生，最起码是能够部分降低悲剧发生可能性的，但遗憾的是，整个过程中，大家看到的不合理和纰漏太多。比如说，那个杀害了女孩的司机，前一天刚刚被另一位乘客投诉过，但滴滴官方却未有任何处理。

　　于是，舆论哗然。

　　诚然，“网约车”作为一种新兴的业务，也一定程度上客观存在着其监管和运营上的难点，如果我们要回过头去看，“黑车司机抢劫谋杀事件”其实在过去也一直存在着，且始终都是监管上难以覆盖到的盲区。

　　只是，作为滴滴，既然已经在事实上成为了一家全国性的企业，每天要面对全国几千万甚至上亿人的公共出行的需求，其在事实上就必须要担负起巨大的社会责任，并且，“顺风车”作为一个“社会闲置资源价值最大化”理念下的产物，我们也不能一巴掌打死，全盘否定其存在的价值。

　　从这个角度来说，“滴滴顺风车”的关停，可能并非是最佳结局。

　　所以，假使滴滴顺风车不是关停，我们是否有可能通过产品设计和运营策略上的调整，有一些更优的机制和方案可以来最大程度规避其“乘客安全风险”的问题？至少，让本文前面提到的几个问题不再存在。

　　从三节课官方本身的立场来讲，身为一所“互联网人的在线大学”，我们也总是更愿意从指导业务实践，如何才能更好解决具体问题的角度来进行思考，而非一味站在高处来进行指责和质疑。

　　因此，我们在三节课内部进行了一些思考和讨论，然后，我们结合内部讨论成果与三节课的策略产品经理课程中提到的产品策略设计工作方法，试着为滴滴设计了一套“司乘风险防范机制”方案框架，就我们所了解到的信息，我们觉得这套机制或许会有助于改善滴滴在本次事件中暴露的一系列问题。

　　需要特别说明几点——

　　1、我们所设计的这套方案框架，仅基于我们当前对于滴滴产品结构、顺风车业务形态以及技术水平的理解来完成。在整个讨论思考过程中，我们始终在尽力保证这套防范机制的合理性和可实现性，但即便如此，由于并未身在滴滴公司内部，有很多信息和困难仍然是无从得知的，以及，如果考虑到滴滴拥有数十亿条的出行数据积累，也完全有可能存在比这一方案更优的方案。

　　2、参与本方案讨论的三节课同学，多为工作经验不足5年的产品或运营同学，包括笔者本人，其实也仅是一名1年经验的内容运营。所以，我们整个方案的设计和思考一定存在诸多缺陷和局限，还请大家能够针对我们思考的不足不吝赐教和拍砖。

　　3、我们认为，对于“顺风车”的安全风险，很可能是无法完美解决的——就如同你无法保证婚恋交友网站上不会出现酒托婚托一样，但，站在产品设计和策略的角度，我们应该做的是想办法在现有的技术和工具下，尽可能降低事故的概率，提高作案的成本，让事故发生的可能性尽可能减小，这也是我们的方案设计的基本出发点。

　　4、我们仍然要强调，我们认为，关闭顺风车其实并未真正解决问题。关停，只是把问题以某种方式暂时掩盖住了，不代表大家就没有使用顺风车的需求了，也不代表在未来某一天，它不会以别的形式出现。因此，对于滴滴，也包括对于身处其中你我而言，坦诚的接受不幸的发生，认真思考一个真正在现实世界可行的方案才是更加重要的事情，这也是唯一一种可以让世界变得更好的方式。

　　下面，我们正经来分享下我们所设计的这一套“司乘风险防范机制”。

　　要解决问题，必须先清楚定位问题的本质。

　　在我们看来，滴滴本次事件前后表现出的问题有很多，包括客服的滞后，对于违规处理的判罚过于低效，以及对于警察的响应速度过慢等等。但回溯起来，问题的真正关键在于，滴滴在整个业务中，并没有完整的对于司乘之间可能会发生的安全风险进行预防、监测与应急处理的方案。

　　因此，我们认为，如果要把风险再次发生的概率降到最低，关键就在于设计出一套有效的，动态的、评估风险的系统。 这套系统，可以实时支持大量业务的自动化处理，风控系统将承担打车前、打车过程中和打车结束后的风控评估、处理及预警的角色，极大地解放人工处理的瓶颈与效率，并且结合一些产品功能的设计，降低风险出现的可能性。

　　而在“顺风车”这样的业务中，业务运转的核心单元其实是“订单”，无论风险的产生还是交易完成，都是基于“订单”来完成的。

　　因此，我们或许可以参考金融系统的方法，为滴滴顺风车业务的全部订单都设定一个动态“安全系数”，并依照安全系数的变化去判断每一单当下存在的风险程度。

　　当有“安全系数”之后，我们就可以依靠整个安全系数去设计一整套相应的应对方案。

　　举例来说，我们假设安全系数的满分是100分，80分是及格线。

　　当分数在80分以上时，就可以认为这一单是安全的；

　　当分数低于80分时，判定可能存在风险，但并不紧急，软件自动推送消息提醒乘客或司机关注；

　　而当分数低于70分时，判定可能风险较为明显，或许我们就可以给司机或乘客做出风险提示，相应订单在滴滴客服团队处的处理优先级会得到提升。同时，客服将有权限调取乘客与司机一些个人信息和数据，进行判断；

　　当分数低于60分，或出现“紧急求助”事件时，安全系数降为0，该订单升级为最高优先级事件处理。这时，可能就需要滴滴对警方做出提醒，可能有风险出现，并且，滴滴需要人工主动关注情况。而且，客服的数据调取权限可能将进一步提高，以备配合有关部门调查。

　　当然，如上只是举个例子，实际在滴滴内部，不同风险级别的订单，可能涉及到的权限和处理流程等，也许还会复杂得多。但无论如何，原理和原则大体应该是这样的。

　　有了系数，接下来就需要去定义到底哪些因素会影响这个系数的变化。

　　直观来看，可以想到的一些显性因素包括：单个用户个体的安全系数（或称可信任程度），司乘双方匹配的安全系数、行程实际路线与最优路线或目的地之间的偏离程度，等等。

　　我们也许可以分别针对以上几个数值进行监测，并赋予每个数值不同的权重，这样，我们就可以做到：每个订单的风险系数是动态变化的，且能够最接近真实的反应出该订单的风险状况和风险等级。

　　我们不妨对上述提到的几个影响风险系数变化的因素再做些解释。

　　▌ 单个用户个体的安全系数

　　我们猜想，这一部分数值也许与司机、乘客个人的基础信息和过往所获评分、评价相关。

　　比如说，对于司机，可能的参考标准有——

　　●基本的个人信息，如性别，年龄，籍贯等；（并无地域歧视的意思，但在某些地区，籍贯、年龄等可能会是预设一个人风险系数高低的参照因素之一）

　　●是否有违规行为受到过投诉，这里最极端来看，或可采取红线制度，一旦有违规行为出现，则立刻采取封号或暂停派单的处理；

　　●乘客的综合评分；乘客对于司机的所有历史评分，都会成为对于司机的评分标准；

　　●总接单数，接单数越高，评分就越高；

　　●单一手机号码使用的时长；

　　●社会信誉，诸如芝麻信用，社会征信体系，都有可能成为重要的参考标准。

　　同样，对于乘客也要有相应的评判标准，乘客的信誉程度也会很大程度影响到整个“安全系数”的判断。这里，我们可以参考的标准有——

　　●基本的个人信息，同上；

　　●乘车次数（总交易金额），次数越多，说明ta更信任滴滴，也侧面说明ta的判断更有价值；

　　●司机评分及投诉记录，同样，司机对乘客的评分，也会成为乘客行为的评估；

　　●手机设备

　　▌ 司乘双方订单匹配的安全系数

　　当我们有了对于司机和乘客的评分之后，就需要设定一些规则对于司机和乘客进行匹配。基本思路应该是这样的——

　　首先，对于司机和乘客的分数分别给定不同的权重，并且将双方评分进行加权平均，得出对于这一单的基本安全系数值。

　　依照我们的判断，可能需要司机端的权重比较高，这意味着，司机的评分高度将会更大程度影响的成单可能性。也就是说，评分更高司机，就更有可能成单，相反，评分更低的司机，成单可能性也更低。

　　其次，对于一些特殊情况我们要设定不同的分析系数。

　　最典型的代表就是，当男司机和女乘客，或者反过来，男乘客和女司机匹配的时候，就需要调低“安全系数”值；

　　最后，得出一个综合判定的“安全系数”值，并要求，凡是低于某个安全系数的时候，一律不允许成单。

　　以上这些措施都是确保，当某个单达成的时候，基本是安全的。但是这还只是预防措施，当行车过程中，也有可能出现风险，这可能就需要在行程中动态分析了。

　　▌ 订单完成过程中对于安全系数的动态调整

　　在前往目的地过程中，所有异常的情况，都应该纳入考虑，动态的调整安全系数。

　　这里的基本思路是搭建一个数据监控体系，监测道路中发生的可能的异常情况，遇到问题就及时上报。

　　比如说，可能的情况有几条——

1. 观察车辆的行驶路线与滴滴系统推荐的路线是否有大幅度的偏离，一旦有偏离，就立刻关注相关情况，并对司机和乘客进行提醒，并降低安全系数；

2. 观察车辆的是否在无拥堵的情况下长时间在某地停留，如果超过某个时间，这个情况也会成为可能的风险点上报提醒，并降低安全系数；

3. 乘客或者司机点击“紧急求助”按钮，安全系数降为0，升级为最高优先级事件处理；

　　▌ 到达目的地

　　到达目的地之后，也需要获得顾客对于这一单的评价。对于过程中，出现的问题也需要追踪，比如说，如果出现70分及以下单，可能就需要人工电话关注有关的情况，判断如何处理。

　　以上，可能就是整个滴滴的司乘风险防范系统的基本设计框架。

　　由于篇幅、信息量与思考深度所限，我们只能给出一个基本框架，无法深度结合滴滴顺风车的很多业务实际情况和数据来进行推演。

　　但如前所述，这套方案的核心思想，其实借鉴了策略产品经理工作的一些核心方法，以及目前许多金融系统对于风险的防范和处理方案，其中许多细节在现在的金融相关企业及互联网金融公司都已经实现了。所以从技术和可实现性上讲，我们认为作为一家国内一流的互联网公司，滴滴是完全有可能做到的，甚至我相信，滴滴可以做的更好。

　　然而，我们想说，对于滴滴来说，策略终究只是工具，工具是为了解决问题而存在，而用工具解决怎样的问题、如何解决问题是由拿工具的人决定的。

　　1954年，管理学大师，彼得·德鲁克先生在他的管理学奠基之作《管理的实践》说过这样一句话：“企业是社会的器官，企业的行动对于社会也会产生决定性的影响。当管理者由于他所具备的特殊能力而拥有了职权时，就应该负起相应的社会责任。”

　　对于滴滴来说，就是如此。当作为一家商业组织的滴滴，面向的是全国几千万甚至上亿人的公共出行的需求，它就已经具有一种“特殊能力”，并获得了某种“职权”。也因此，用一个相对合理的成本，换取整个社会的安全系数的提高，是他义不容辞的社会责任。

　　而无论对于在互联网行业做产品还是做运营的所有人来说，我们工作的最大意义，不正是在于那种“我们在运用着自己力所能及的一些方法和工具，一点点在让这个世界变得更加完整和美好”的可能性吗？

　　诚愿滴滴无论在公众回应还是产品策略设计上，都可以做得更认真、更诚恳、更及时、更好。

　　也再一次认真说，针对本文思考上的不足和偏颇之处，还请大家，尤其是滴滴官方的同学可以不吝指正。

（声明：本文仅代表作者观点，不代表新浪网立场。）