外卖员和用户的问题没有优先级
这是仙人JUMP的第332篇原创
1
外卖行业今天又出现了一个很魔幻的事情。
一个外卖小哥送外卖，用户因为正在打电话没有接到，于是外卖小哥直接点击了确认收货然后离开。
后来用户致电要求配送，小哥表示明天再送，收获了一个差评。
然后第二天小哥果然再送了，上门砸门威胁用户，表示不取消弄死你，收获了一个报警和居留10天。
这人有这砸门的功夫为啥第一天不直接东西放门口呢。
而用户自己为了防止报复收获了搬家。
大家都有光明的未来。
这个事情到底是谁的问题我觉得不用多说了。
都知道是平台的问题。
一个是没有保护好用户数据，能让外卖员直接锁定差评用户。
一个是差评与惩罚机制不合理，按照道理应该是没送的先送完，不送再讨论罚款。
一个是算法给出的时效性有问题。
一个是针对用户无法接电话的场景，应该有相关的流程，不管是拍照无责还是短视频验证无责。
最后是由于骑手都是外包所有人家根本就没有约束力和恒心。
外卖员是有问题，但平台也逃不脱问题。
讲白了就是应该居中作为调解方的平台做了拱火方，让用户和外卖员产生了直接的冲突，该浇水的时候浇了汽油，整个机制就离谱。
之前还有一篇关于算法如何控制外卖员的文章，同样是平台逐利的问题。
但这次的事件还不太一样。
很简单，算法来催着外卖员加速，这是非常简单直接获取收益的问题，送的越快，运力越强，竞争力越强。
所以动机是很明确的，资本不逐利不如做公益，好歹公益还能减税呢。
这次的事件，当然是平台各种不当人导致的，但大家搞算法竞赛比外卖员陆地飞仙好歹是有收益的，这次或者说类似的外卖员与用户的冲突，对于平台而言并没有什么收益。
损了名声，也赚不到什么钱。
这种事情出现太多的话，可能还会有更大的问题。
从技术上说，这些事情的改进其实是不难的，以国内各大互联网公司的聪明才智，这都是小问题。
大家连大数据杀熟都玩儿得转，玩点儿这种大数据友谊促进，那是分分钟的，毕竟各种社交平台上充满了各种深入交流的友谊。
那么问题来了，为啥不做？
还真不是所谓的资本嗜血那套，原因很有可能非常魔幻。
因为过不了内部的排期与部门间的KPI扯皮。
不要笑，很多时候互联网公司没有大家想的那么全知全能。
很多问题也真的是只有在出现问题的时候大家才会意识到这是个问题。
并且实际上，一家公司并不是一个整体，而是不同部门之间的分工协作。
这个协作要加个引号，实际上大家并不是那种一起努力的样子，而是互相影响互相扯皮。
一个外卖平台，每天要做的事情都是茫茫多的，内部的研发资源是有限的，尽管从大老板的角度当然明白平台声誉和用户体验的重要性。
但是没办法，下面执行侧的人，一定会因为KPI而导致操作变型。
不同部门的KPI是不同的，大家对不同的数据结果负责，但是研发资源又是有限的，那大家就要抢资源，以及甩锅。
好了，问题来了。
现在你是负责用户体验侧的产品经理，你想到了一系列方法来优化双方的体验，现在到了排期会，你提出了一系列改进方案，这时候你会感受到现实。
首先，如果你的改进是从直接扣款，变为先敦促执行，再来扣款，你以为这是一个小改动对么？
这其实是一个非常大的改动，可以说是整个业务流的重构，影响整体业务。
大家都指着这个干饭呢。
那么问题来了。
当前的业务流是确定性的，大家都知道会发生什么事情，现在要让业务流发生变化，可能结果会好，也可能结果不会好，这是不确定性的。
在一件不确定性的事情上投入资源，这个优先级其实是不高的。
而且，如果变好了还好说，如果没有变好，谁来承担开发资源的损失？
如果变得更坏了，谁来背锅？
这个问题不解决，任何对于流程的改动，都过不了项目排期会。
即使我们不考虑变好变坏的背锅问题，我们再来看其他的。
假如这个东西或许会让客诉下降，会降低外卖员和用户的摩擦，是个好事儿，并且也不会导致流程效率下降。
那么一定会优先开发吗？
不会的。
因为业务部门的KPI不是这个。
业务部门的KPI只会是日活，是GMV，是利润率，是商家数，肯定不是客诉。
客诉是只有用户体验部门才负责的KPI。
隔壁部门的KPI，管我什么事情？
这时候问题来了，业务部门自己有一堆活动设计的开发要搞，运营有一堆券要发，还有各种开脑洞的活动准备上，这时候用户体验部门跳出来说需要资源做点事情，这些事情还会影响主流程，业务部门会笑着把他们请出去，然后吐上一口痰。
你说客户体验部门也有自己的研发不行吗？
不行。
因为只要涉及主流程的改变，业务部门也要出研发资源对接，有限的资源不会被用于这种修修补补的业务的。
而且，这种改动也要影响业务部门的流程。
客服部门的需求影响业务部门的流程，客服是不是太把自己当回事儿了？
用户投诉和我拿年终奖又没有关系，而且我还可以把事情归类为客户不理智以及外卖员素质低，你没法把锅扣在我头上，我就不做，你能怎样？
没有共同的KPI，大家只是塑料一家人。
很多公司都在讲用户体验，但实际情况中，业务部分根本不在乎用户体验。
他们只在乎GMV，因为关乎年终奖。
甚至于，就连研发同事都不愿意开发客户满意那边的需求。
因为研发想要升职，想要吹牛逼写PPT的时候，只有2种东西最有用。
1个是所谓的平台技术迭代，要么是开发一堆很新很流行，但是卵用没有的所谓中台，所谓智能算法，所谓创新工具，这东西对业务一点帮助都没有，但是特别能拿来吹牛。
1个就是帮助业务提升了多少，例如开发了一套算法，精准优化了外卖员的送餐时效，提升了外卖员的平均单量，例如启用了新的服务器调度策略，承担了多少多少的并发，例如开发了一套卡券系统，智能卡券让补贴更有效，节约了多少钱。
只有这两个东西，才是技术同事升职加薪的第一驱动力。
至于什么客诉，这东西怎么拿来吹牛逼？
根本不在老板眼里。
开发客服系统在任何一家公司都是鄙视链的最底层，最没有前途。
这就是职场现状。
那么问题来了，如果你现在是负责客户满意的产品经理，你要不到研发资源，你的项目排期永远会被更新的活动需求或者业务需求插队，你要怎么做？
正确的做法当然是所谓上诉，所谓给老板写信之类的。
但这都是梦里的事情。
现实中，大家都是打工人，混工资而已，自己提了意见，提了需求，没有研发资源，能怎么办呢？
真正最流行的做法是，躺平，期待着出事儿。
你没看错，是期待着出事儿。
期待着出事儿不是说幸灾乐祸，而是只有出事儿的时候，大家才能在短时间里意识到用户满意和安全的重要性。
讲话是没有力度的，只有出事儿才有力度。
每当出事儿的时候，负责安全，客诉的产品经理第一反应是难过，第二反应就是我的需求终于可以推进了，得趁着这时候赶紧把需求插进去，赶紧开发掉。
不出事儿，公司永远意识不到痛。
一定要快，这时候不快，赶明大家又忘了疼了。
说句政治不正确的话，不流血，公司永远不知道安全和用户满意的重要性。
当年网约车要不是连续出现恶性事件导致公司差点完蛋，安全合规永远没有机会压在业务和GMV前面。
从这个角度来讲。
当前的各大公司。
都缺一场真正的社会教育。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
本文禁止转载，侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
评论
评论
推荐评论
暂无评论哦，快来评论一下吧！
全部评论（0条）