外卖产品思考

27 评论 12656 浏览 159 收藏 8 分钟

外卖产品下单到收货参与到的角色有用户、商家、骑手、以及平台系统;这四个角色和角色各个对应的场景活动构成了外卖产品的业务流程。

用户从下单到收货的整个业务场景的流转需要多个角色的支持配合。

下单到收货参与到的角色有用户、商家、骑手、以及平台系统,想清楚各个场景对应的关系。下单到收餐的流转主要依靠这些角色的完美供应。

我们来具体分析这几种角色:

第一:对应的C端用户的角色,用户的相关权限为下单、支付、催单、退单、评价。

第二:商家、出餐者,店铺的相关权限为通知骑手来取餐、出餐。

第三:骑手,骑手的权限为送餐。

第四:平台系统,平台系统的功能为短信服务、奖惩机制、运力分配等相关功能。

前端订单展示

前端订单系统主要包括2大块的展示:订单信息和订单状态,其实用户更多的是关心订单状态。

1. 订单信息:

配送信息:

配送服务、配送骑手、骑手距离、预计到达时间、期望时间、配送地址;是必须展示的要素,来提升用户体验,便于用户查看,实时准确得知食物信息。配送地址、联系方式是骑手送达的根据。

订单信息:

订单号码、下单时间、支付方式;是必须展示的要素,便于用户核对订单。

2. 订单状态:

待支付订单:

已下单但未支付的订单,针对此类订单,平台会设置一个自动取消的时间,比如未付款(美团和饿了么都是15分钟后)自动取消,平台就会取消用户的此订单。用户在15分钟内可以选择取消订单或者去支付订单。

已支付但商家未接单:

界面提示用户“正在通知商家”。

商家已接单:

界面提示用户“商家正在努力制作中”。

骑手接单:

订单状态为“骑手已接单”。

骑手配送订单:

订单状态为“骑手还剩xxx分钟到达”。

骑手送达订单:

订单状态为“骑手已到达”。

用户取餐成功:

订单状态为“订单已完成”。

我们可以看到:用户在前端可见的几个订单状态变化,其实在后台经过了很多角色的协助。

下面介绍各个角色之间需要重点注意的流程状态点:

下单到收餐的业务流程图

我们可以看到:用户在前端可见的几个订单状态变化,其实在后台经过了很多角色的协助。

下面介绍各个角色之间需要重点注意的流程状态点:

1. 平台系统

用户在下单支付成功后,平台需要提醒商家app信息通知,商家得知订单消息,才能接单确认订单,平台在用户和商家下单、接单。

商家如果接单状态,就要考虑是否将接单通知同步给骑手,然后骑手如何选择?

上面业务流程图只考虑了系统派单的情况,如果有商家自己的骑手,那么优先派单之后就进行抢单模式。

平台派单骑手的选择:首先确定骑手是否超载(最高6单),然后对骑手进行选择,比如骑手信誉、个人积分、用户评价、骑手类型(自营骑手还是加盟骑手)、骑手距离等因素多方面考虑,确定骑手。

骑手取餐时间的选择:骑手取餐时间一般是接单后和备餐完成之前取一个中间值,那我们利用平均值(均值)算法来确定骑手的取餐时间,考虑商家平均出餐速度和骑手平均送餐速度。

用户催单:平台就要判断应该催商家还是骑手还是平台。当用户下单商家未接单之前催平台,当商家接单之后骑手取餐时间之前催商家,当骑手取餐之后催骑手,所以当骑手取餐之后应该给用户和平台都有一个通知,提醒骑手已取餐,这样用户催单的时候,平台可以判断出来应该是催骑手还是商家。

用户取消订单:首先平台规定一定时间内(10分钟)用户可以免责取消订单,原路线返回付款金额。10分钟以后,用户选择取消订单,平台就要通知商家,判断商家是否已经开始制作,没有制作且商家同意取消原路线返回金额,如果商家已经制作了,用户就要选择取消原因,送餐时间慢等就进入催单催促商家或骑手尽快送达,如果是其他原因,就要多方面(比如用户历史取消订单次数,用户是否为会员,用户订单次数等)考虑,进行处理。

用户投诉:用户选择投诉原因,就要考虑是商家还是骑手的原因。我们可以规定一个商家出餐的平均值时长,如果商家出餐超过这个时间,我们就判定为投诉商家,否则断定为投诉骑手。

2. 商家

比如用户下单之后,要考虑商家是否接单(接单状态与不接单状态),如果商家选择接单,就要考虑是否直接同步通知给骑手。

如果商家不接单,平台规定一段时间(根据商家平均接单速度确定一个时间)内商家不接单,自动取消用户订单,app提醒用户订单未受理,需要重新下单。

3. 骑手

骑手在商家确认收餐后,注意要确认收餐,传给后台消息,一方面平台可以更新前端展示信息“骑手已接餐,距您xxx公里”给用户;另一方面平台在收到用户催单消息时,可以判断出来是应该催促骑手了。

总结

本文只是简单介绍了用户下单到收餐的整个业务的各个角色在各个场景下的流程,对于实际的用户下单到收餐来说,肯定不是这样简单地逻辑简单地算法,希望各位前辈批评指正。

 

本文由 @逛吃逛吃 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 1.大体的外卖主流程,和界面要素,能想清楚,但是流程图很乱,逻辑上有待加强
    2.在流程中,要区分哪些内容是要放在流程上的,人为触发的动作,和系统判断,可用不同的颜色作出区分;流程图不要往回画
    3.外卖有很多其他分支流程,放在一起很冗余,做分析的时候,可以从某一个小点来出发,让自己的思路精细化

    来自北京 回复
    1. 谢谢,我会在复盘改进的

      来自北京 回复
  2. 我最近也在做外卖的产品,刚好看到,给了我一些启发

    回复
  3. 确实是个入门外卖产品的好文章,请问外卖思考2在哪里呢?

    回复
  4. 很赞,逻辑清晰,表达清晰,版面清晰

    回复
    1. 谢谢哈

      来自北京 回复
  5. 1.订单状态中,还应该有一种情况“骑手前往取餐中”;
    2.流程图有一些小bug。平台系统方面,如果判断骑手超载,此时的选择应该是选择其他的骑手,而不是循环回去,如果循环回去就成了一直判断,无法分配骑手了。同时,用户在催单后,判断外卖的位置,判断完毕之后会有相应的措施,也就是流程图不够完整,用户投诉后同理。用户方面,如果下单之后,商家选择不接单(突发情况,或在用户下单的途中店铺关闭等),那么是否需要给用户一个反馈。商家方面,骑手的取餐应该是在商家备餐完毕后进行的,而不是备餐完毕之前。
    以上也只是我的一点小看法和小建议。
    本人对作者还是非常敬佩的,加油

    来自上海 回复
    1. 嗯呢,我继续改进,不过我还是觉得骑手的取餐是在接单后和出餐前取一个中间值,我认为这样是合理的。

      骑手前往取餐会花费一些路程,到达之后出餐完毕,正好可以进行取餐。如果是备餐结束,骑手在过来取餐,一方面要考虑骑手到店需要的时间,可能导致食品变凉等情况,一方面要考虑用户投诉的情况。
      现实中我们也可以看到,骑手的取餐不是在商家备餐完毕进行的,我们会看到有些情况下骑手会在店铺等待食物,也就说明骑手取餐不是在商家备餐完毕进行的。

      咱们互相交流看法哈

      来自北京 回复
  6. 1、有个开始和结束的流程更好;
    2、泳道图可以画的更清晰些(位置太挤了),能减少线条的交叉尽量减少。

    已经很赞了~加油继续写下去

    来自上海 回复
    1. 谢谢,我继续去改进一下。

      来自北京 回复
  7. 妹子是要去外卖公司面试吗

    来自上海 回复
    1. 还没找实习呢,就是平常学习思考的写下来。

      来自北京 回复
  8. 商家不接单怎么办…

    来自重庆 回复
    1. 文章里面只考虑了商家接单状态的流程。如果商家不接单,平台规定一段时间(根据商家平均接单速度确定一个时间)内商家不接单,自动取消用户订单,app提醒用户订单未受理,需要重新下单。

      来自北京 回复
  9. 乱,有待提升,加油!

    来自上海 回复
    1. 好的。

      来自北京 回复
  10. 在补充一点,
    状态最好用横向的阶段来区分,更明显些

    来自江苏 回复
    1. 好的,我继续改进。

      来自北京 回复
  11. 说两小点吧
    1.流程图最起码有个开始和结束,否则阅读者很懵逼。
    2.虽然是泳道图,但是应该有向时序图一样的发生的先后顺序,不然阅读者看就像迷宫一样。

    来自江苏 回复
  12. 不错,泳道图做的有点复杂并且有点小bug,按时序图对流程顺序标注一下应该会更清晰一点

    来自天津 回复
    1. 好的,谢谢哦

      来自北京 回复
  13. v

    回复
    1. 不懂V什么意思,哈哈哈,希望批评指正哦

      回复
  14. 拿第一个流程图给老板看?猜老板什么反应!

    回复
    1. 被疯狂吐槽😭?哈哈,望批评指正

      回复
  15. 棒棒哒

    来自北京 回复
  16. zan

    来自北京 回复