遭遇百度外卖乌龙事件，产品新人的挖坟式分析

最近笔者使用百度外卖订花送给我姐姐。因为是预定，百度外卖需要通过快递完成配送。于是我便得到了这样一张快递单号的追踪图：

有没有发现很神奇的地方？ 注意， 快递的路线是：顺义---东城---顺义---丰台---顺义---东城。 这是多么奇葩的派送路线！！

好吧，让我来还原一下这个奇葩的乌龙事件全经过吧。

2月早些时候，我通过百度外卖完成了预定。

2月28号，我收到消息，顺丰已收取快递并开始派送。以通常情况下顺丰的效率，我预计次日，也就是2月29日中午这个订单就会被送到。

但是，到了2月29日上午十二点，我在顺丰的订单查询系统中查到了如下的信息：

按照图上的信息，顺丰原本已经送达了东城区开始进入了派送，甚至进入了“准备签收”状态，但此后将近3小时后，这个快件却被打回了顺丰的顺义集散中心。

这让我心很慌。我的第一想法是：姐姐生气了吗？是她拒收了我送的花？于是我和姐姐间有了下面的对话：

跟姐姐聊完，好的是不是因为她生气拒收了花，谢天谢地。但我倒是更迷惑了：这到底是怎么回事？

身为一个产品狗，刨根问底的精神一定要有。于是我给顺丰打电话确认情况。在电话中，我得到顺丰的回复是:我看快递单地址上写的是“北京市丰台区广安路天恒大厦”啊，我们没办法从东城区给你送到丰台区，跨区的要重新打回集散中心分配的。（科普一下，我们提到的天恒大厦事实上在东城区东直门）。

也就是说，事实上，顺丰最早是根据我写的“天恒大厦”这个定位把快件送到了东城区，但在派送过程中，由于快递小哥突然发现快递单号上写的是“丰台区广安路天恒大厦”，觉得是快件分发出现了错误，于是把这个件打回了集散中心。

最让人哭笑不得的是，丰台区广安路其实并不存在一个“天恒大厦”……

那么为什么会出现快递单上写的是”北京市丰台区广安路天恒大厦”这样的乌龙地址呢？

我又给商家打了电话询问，商家的回复是：收到百度外卖给的地址就是这个。

于是，我说明了一下事情经过，并让商家通知顺丰改地址，这一通忙活之后，花总算送到了姐姐手中。但是，本来周一应该收到的花到周二才收到。经过一天折腾，花都干了。姐姐最后收到的花是下面这个样子的，笔者对此表示很不高兴。

整个事件中，元凶毫无疑问是百度外卖。作为一名产品狗，笔者认为我有必要彻底搞清楚这次情况出现的原因。

于是，笔者复盘了通过百度外卖下订单时填写地址的流程和场景。

以上就是百度外卖添加地址的流程。分别存在4个步骤：

是不是看上去很正常，流程上没什么可挑剔的地方？我的答案也是，在用户端而言，使用流程看起来确实不存在什么问题。那么问题在哪里呢？

有趣的地方其实出现在第4个步骤，我们发现，在最后的地址确认页面上，用户能看到的地址只有：天恒大厦A座，而并没有相应的城区信息。

那快递单上的地址为什么是：北京市丰台区广安路天恒大厦？北京市丰台区广安路是哪儿来的？

至此，笔者其实已经很清晰了，真相只有一个：这个地址是我自己位于丰台区广安路时添加的，那是笔者之前上班的地方。所以，“丰台区广安路”这样一个城区和街道的信息是百度外卖依据地理位置定位自动抓取过来的。

在百度外卖的这一地址抓取逻辑下，我添加的地址就变成了：北京市丰台区广安路天恒大厦。而不是事实真正的坐标：北京市东城区东直门天恒大厦。因而也就有了上面快递的乌龙事件。

但是，问题又来了，以百度外卖这样的逻辑，用户在下单购买商品，且送货地址就是自己当前所处地理位置的时候，是不存在什么问题的。但假如所处地理位置与配送地址不一，岂不是就要出事？典型如：

用户还没到公司先定外卖，到了公司正好开吃；

给朋友定外卖或者鲜花蛋糕之类的。

显然，对于上面两个场景，百度外卖上发生的频次应该不低，那为何这样的问题还会在百度外卖中存在？难道此前没有用户反馈过这样的问题？难道百度外卖的产品狗对这样直接关系到用户体验的问题直接选择了无视？

为了搞清楚最终的真相，笔者又开始了新一轮验证。

于是，2月29日，我在自己住的地方，下单购买了一份水果，派送到酒仙桥的三节课实验室，试着通过类似场景的还原来看是否会发生类似的乌龙事件。

在下完订单，水果送出后，我第一时间委托三节课萌妹子冰丹帮忙电话询问配送员地址情况，但得到的回答是：地址没有错！并且，当天水果也如期准时送达。我的验证失败了！

这让我更加困惑了：难道我此前的分析和逻辑判断都是错的？

纠结了很久，为了得到真相，我决定自己出马，再来一次。

3月1日，12点半，我再次下单购买水果，地址使用了昨天添加的同一地址，还是三节课实验室。

随后，我在百度外卖上收到了商家确认订单的消息，笔者这时候学聪明了，第一时间给商家打了电话，以不确定我留下的地址有没有留错为由向商家确认商家手中收到的地址。

到此为止，我有了新一轮的判断。我确信，此前我所判断的百度外卖获取地址的逻辑是对的。

但，这当中，百度外卖后端的派送处理机制很可能是有一些细微区别的，我简要用下图说明。

首先来看我预定鲜花时的逻辑：

而我给三节课实验室买水果处理的流程是下面这样：

这里，为什么会出现截然不同的流程呢？

原因是，预定鲜花这样的订单，百度外卖商家需要通过快递公司来进行配送。 而 快递公司在北京各个区都是有分拣点的，都需要先把快件汇总到分拣点以后再统一配送。所以，接收一个快件前，快递公司必须知道城区、街道这样的信息 。

而，对于即时配送的美食、水果类订单，百度则是使用自家的闪送侠来进行配送的。对于这批闪送侠，他们不需要知道城区、街道这样的概念。 他们接收到的订单通常都不会距离太远，因而只需要使用地图定位，找到附近的该地址进行送达即可。

所以，百度外卖的这一逻辑虽然有问题，但只要不通过传统的快递公司完成配送，可能都不会出事，应该都不会不影响到用户体验的。只有遇到了传统快递公司且出现异地下单情况时才有可能出现这样的乌龙事件。这应该算是小概率事件，很可能还没有被用户反馈和被注意到。

但，既然是问题，最好还是可以避免发生的。那么如何改进呢？

可能有人说：把地址前面的北京市丰台区广安路改成手动输入或者选择不就行了。对！不错！这样是可以的，但是输入起来是不是会变得很麻烦？这听起来更像是12306双图验证码的逻辑！

其实，假如百度地图的数据足够完整的话，完全存在一种成本更低、更好的做法： 直接根据用户在地图上搜索和定位到的地址来确定地址信息，而不考虑用户当前所处的地理位置定位。

以上，就是笔者从遭遇不良体验到刨根问底找到问题根源并试图提出解决方案的全过程。所以，产品上面的一个细小优化，背后都是产品狗们的血和泪啊筒子们！！！

【三节课按】

石磊的这篇观察和分析，是我们眼中一个典型产品狗最应该养成的习惯：试着发现并分析自己身边一切潜在问题的根源，并提出解决方案。

愿有更多新人们可以养成这样的习惯，少空谈，多思考，多实践。