用户从下单到收货的全体业务场景的流转须要多个角色的支持合营。
下单到收货参与到的角色有用户、商家、骑手、以及平台系统，想清楚各个场景对应的关系。下单到收餐的流转紧张依赖这些角色的完美供应。
我们来详细剖析这几种角色。
第一：对应的C端用户的角色，用户的干系权限为下单、支付、催单、退单、评价。
第二：商家、出餐者，店铺的干系权限为关照骑手来取餐、出餐。
第三：骑手，骑手的权限为送餐。
第四：平台系统，平台系统的功能为短信服务、赏罚机制、运力分配等干系功能。
前端订单展示
前端订单系统紧张包括2大块的展示：订单信息和订单状态，其实用户更多的是关心订单状态。
1. 订单信息：
配送信息：
配送做事、配送骑手、骑手间隔、估量到达韶光、期望韶光、配送地址；是必须展示的要素，来提升用户体验，便于用户查看，实时准确得知食品信息。配送地址、联系办法是骑手投递的根据。
订单信息：
订单号码、下单韶光、支付办法；是必须展示的要素，便于用户核对订单。
2. 订单状态：
待支付订单：
已下单但未支付的订单，针对此类订单，平台会设置一个自动取消的韶光，比如未付款（美团和饿了么都是15分钟后）自动取消，平台就会取消用户的此订单。用户在15分钟内可以选择取消订单或者去支付订单。
已支付但商家未接单：
界面提示用户“正在关照商家”。
商家已接单：
界面提示用户“商家正在努力制作中”。
骑手接单：
订单状态为“骑手已接单”。
骑手配送订单：
订单状态为“骑手还剩xxx分钟到达”。
骑手投递订单：
订单状态为“骑手已到达”。
用户取餐成功：
订单状态为“订单已完成”。
下单到收餐的业务流程
前端系统虽然会对订单信息和状态进行展示，但这些订单信息和状态在后台业务中是如何有效进行的，各个场景下各个角色如何高效互助，终极展示在前台，是非常主要和繁芜的。
下图是用户从下单到收餐的一个业务流程泳道图：
我们可以看到：用户在前端可见的几个订单状态变革，其实在后台经由了很多角色的帮忙。
下面先容各个角色之间须要重点把稳的流程状态点：
1. 平台系统
用户不才单支付成功后，平台须要提醒商家app信息关照，商家得知订单，才能接单确认订单，平台在用户和商家下单、接单。
商家如果接单状态，就要考虑是否将接单关照同步给骑手，然后骑手如何选择？
上面业务流程图只考虑了系统派单的情形，如果有商家自己的骑手，那么优先派单之后就进行抢单模式。
平台派单骑手的选择：首先确定骑手是否超载（最高6单），然后对骑手进行选择，比如骑手信誉、个人积分、用户评价、骑手类型（自营骑手还是加盟骑手）、骑手间隔等成分多方面考虑，确定骑手。
骑手取餐韶光的选择：骑手取餐韶光一样平常是接单后和备餐完成之前取一个中间值，那我们利用均匀值（均值）算法来确定骑手的取餐韶光，考虑商家均匀出餐速率和骑手均匀送餐速率。
用户催单：平台就要判断该当催商家还是骑手还是平台。当用户下单商家未接单之前催平台，当商家接单之后骑手取餐韶光之前催商家，当骑手取餐之后催骑手，以是当骑手取餐之后该当给用户和平台都有一个关照，提醒骑手已取餐，这样用户催单的时候，平台可以判断出来该当是催骑手还是商家。
用户取消订单：首先平台规定一定韶光内（10分钟）用户可以免责取消订单，原路线返回付款金额。10分钟往后，用户选择取消订单，平台就要关照商家，判断商家是否已经开始制作，没有制作且商家赞许取消原路线返回金额，如果商家已经制作了，用户就要选择取消缘故原由，送餐韶光慢等就进入催单敦促商家或骑手尽快投递，如果是其他缘故原由，就要多方面（比如用户历史取消订单次数，用户是否为会员，用户订单次数等）考虑，进行处理。
用户投诉：用户选择投诉缘故原由，就要考虑是商家还是骑手的缘故原由。我们可以规定一个商家出餐的均匀值时长，如果商家出餐超过这个韶光，我们就剖断为投诉商家，否则断定为投诉骑手。
2. 商家
比如用户下单之后，要考虑商家是否接单（接单状态与不接单状态），如果商家选择接单，就要考虑是否直接同步关照给骑手。
3. 骑手
骑手在商家确认收餐后，把稳要确认收餐，传给后台，一方面平台可以更新前端展示信息“骑手已接餐，距您xxx公里”给用户；另一方面平台在收到用户催单时，可以判断出来是该当敦促骑手了。
总结
本文只是大略先容了用户下单到收餐的全体业务的各个角色在各个场景下的流程，对付实际的用户下单到收餐来说，肯定不是这样大略地逻辑大略地算法，希望各位前辈批评示正。
本文由 @抓马小姐姐 原创发布于大家都是产品经理，未经容许，禁止转载
题图来自Unsplash，基于CC0协议
