外卖产品思考

　　外卖产品下单到收货参与到的角色有用户、商家、骑手、以及平台系统；这四个角色和角色各个对应的场景活动构成了外卖产品的业务流程。
　　用户从下单到收货的整个业务场景的流转需要多个角色的支持配合。
　　下单到收货参与到的角色有用户、商家、骑手、以及平台系统，想清楚各个场景对应的关系。下单到收餐的流转主要依靠这些角色的完美供应。
　　我们来具体分析这几种角色：
　　第一：对应的C端用户的角色，用户的相关权限为下单、支付、催单、退单、评价。
　　第二：商家、出餐者，店铺的相关权限为通知骑手来取餐、出餐。
　　第三：骑手，骑手的权限为送餐。
　　第四：平台系统，平台系统的功能为短信服务、奖惩机制、运力分配等相关功能。
　　前端订单展示
　　前端订单系统主要包括2大块的展示：订单信息和订单状态，其实用户更多的是关心订单状态。
　　1。订单信息：
　　配送信息：
　　配送服务、配送骑手、骑手距离、预计到达时间、期望时间、配送地址；是必须展示的要素，来提升用户体验，便于用户查看，实时准确得知食物信息。配送地址、联系方式是骑手送达的根据。
　　订单信息：
　　订单号码、下单时间、支付方式；是必须展示的要素，便于用户核对订单。
　　2。订单状态：
　　待支付订单：
　　已下单但未支付的订单，针对此类订单，平台会设置一个自动取消的时间，比如未付款（美团和饿了么都是15分钟后）自动取消，平台就会取消用户的此订单。用户在15分钟内可以选择取消订单或者去支付订单。
　　已支付但商家未接单：
　　界面提示用户“正在通知商家”。
　　商家已接单：
　　界面提示用户“商家正在努力制作中”。
　　骑手接单：
　　订单状态为“骑手已接单”。
　　骑手配送订单：
　　订单状态为“骑手还剩xxx分钟到达”。
　　骑手送达订单：
　　订单状态为“骑手已到达”。
　　用户取餐成功：
　　订单状态为“订单已完成”。
　　我们可以看到：用户在前端可见的几个订单状态变化，其实在后台经过了很多角色的协助。
　　下面介绍各个角色之间需要重点注意的流程状态点：
　　下单到收餐的业务流程图
　　我们可以看到：用户在前端可见的几个订单状态变化，其实在后台经过了很多角色的协助。
　　下面介绍各个角色之间需要重点注意的流程状态点：
　　1。平台系统
　　用户在下单支付成功后，平台需要提醒商家app信息通知，商家得知订单消息，才能接单确认订单，平台在用户和商家下单、接单。
　　商家如果接单状态，就要考虑是否将接单通知同步给骑手，然后骑手如何选择？
　　上面业务流程图只考虑了系统派单的情况，如果有商家自己的骑手，那么优先派单之后就进行抢单模式。
　　平台派单骑手的选择：首先确定骑手是否超载（最高6单），然后对骑手进行选择，比如骑手信誉、个人积分、用户评价、骑手类型（自营骑手还是加盟骑手）、骑手距离等因素多方面考虑，确定骑手。
　　骑手取餐时间的选择：骑手取餐时间一般是接单后和备餐完成之前取一个中间值，那我们利用平均值（均值）算法来确定骑手的取餐时间，考虑商家平均出餐速度和骑手平均送餐速度。
　　用户催单：平台就要判断应该催商家还是骑手还是平台。当用户下单商家未接单之前催平台，当商家接单之后骑手取餐时间之前催商家，当骑手取餐之后催骑手，所以当骑手取餐之后应该给用户和平台都有一个通知，提醒骑手已取餐，这样用户催单的时候，平台可以判断出来应该是催骑手还是商家。
　　用户取消订单：首先平台规定一定时间内（10分钟）用户可以免责取消订单，原路线返回付款金额。10分钟以后，用户选择取消订单，平台就要通知商家，判断商家是否已经开始制作，没有制作且商家同意取消原路线返回金额，如果商家已经制作了，用户就要选择取消原因，送餐时间慢等就进入催单催促商家或骑手尽快送达，如果是其他原因，就要多方面（比如用户历史取消订单次数，用户是否为会员，用户订单次数等）考虑，进行处理。
　　用户投诉：用户选择投诉原因，就要考虑是商家还是骑手的原因。我们可以规定一个商家出餐的平均值时长，如果商家出餐超过这个时间，我们就判定为投诉商家，否则断定为投诉骑手。
　　2。商家
　　比如用户下单之后，要考虑商家是否接单（接单状态与不接单状态），如果商家选择接单，就要考虑是否直接同步通知给骑手。
　　如果商家不接单，平台规定一段时间（根据商家平均接单速度确定一个时间）内商家不接单，自动取消用户订单，app提醒用户订单未受理，需要重新下单。
　　3。骑手
　　骑手在商家确认收餐后，注意要确认收餐，传给后台消息，一方面平台可以更新前端展示信息“骑手已接餐，距您xxx公里”给用户；另一方面平台在收到用户催单消息时，可以判断出来是应该催促骑手了。
　　总结
　　本文只是简单介绍了用户下单到收餐的整个业务的各个角色在各个场景下的流程，对于实际的用户下单到收餐来说，肯定不是这样简单地逻辑简单地算法，希望各位前辈批评指正。