訂單號碼、下單時間、支付方式；是必須展示的要素，便于用戶核對訂單。

2. 訂單狀態(tài)：

待支付訂單：

已下單但未支付的訂單，針對此類訂單，平臺會設(shè)置一個自動取消的時間，比如未付款（美團和餓了么都是15分鐘后）自動取消，平臺就會取消用戶的此訂單。用戶在15分鐘內(nèi)可以選擇取消訂單或者去支付訂單。

已支付但商家未接單：

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

商家已接單：

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

騎手接單：

訂單狀態(tài)為“騎手已接單”。

騎手配送訂單：

訂單狀態(tài)為“騎手還剩xxx分鐘到達”。

騎手送達訂單：

訂單狀態(tài)為“騎手已到達”。

用戶取餐成功：

訂單狀態(tài)為“訂單已完成”。

下單到收餐的業(yè)務流程

前端系統(tǒng)雖然會對訂單信息和狀態(tài)進行展示，但這些訂單信息和狀態(tài)在后臺業(yè)務中是如何有效進行的，各個場景下各個角色如何高效合作，最終展示在前臺，是非常重要和復雜的。

下圖是用戶從下單到收餐的一個業(yè)務流程泳道圖：

我們可以看到：用戶在前端可見的幾個訂單狀態(tài)變化，其實在后臺經(jīng)過了很多角色的協(xié)助。

下面介紹各個角色之間需要重點注意的流程狀態(tài)點：

1. 平臺系統(tǒng)

用戶在下單支付成功后，平臺需要提醒商家app信息通知，商家得知訂單消息，才能接單確認訂單，平臺在用戶和商家下單、接單。

商家如果接單狀態(tài)，就要考慮是否將接單通知同步給騎手，然后騎手如何選擇？

上面業(yè)務流程圖只考慮了系統(tǒng)派單的情況，如果有商家自己的騎手，那么優(yōu)先派單之后就進行搶單模式。

平臺派單騎手的選擇：首先確定騎手是否超載（最高6單），然后對騎手進行選擇，比如騎手信譽、個人積分、用戶評價、騎手類型（自營騎手還是加盟騎手）、騎手距離等因素多方面考慮，確定騎手。

騎手取餐時間的選擇：騎手取餐時間一般是接單后和備餐完成之前取一個中間值，那我們利用平均值（均值）算法來確定騎手的取餐時間，考慮商家平均出餐速度和騎手平均送餐速度。

用戶催單：平臺就要判斷應該催商家還是騎手還是平臺。當用戶下單商家未接單之前催平臺，當商家接單之后騎手取餐時間之前催商家，當騎手取餐之后催騎手，所以當騎手取餐之后應該給用戶和平臺都有一個通知，提醒騎手已取餐，這樣用戶催單的時候，平臺可以判斷出來應該是催騎手還是商家。

用戶取消訂單：首先平臺規(guī)定一定時間內(nèi)（10分鐘）用戶可以免責取消訂單，原路線返回付款金額。10分鐘以后，用戶選擇取消訂單，平臺就要通知商家，判斷商家是否已經(jīng)開始制作，沒有制作且商家同意取消原路線返回金額，如果商家已經(jīng)制作了，用戶就要選擇取消原因，送餐時間慢等就進入催單催促商家或騎手盡快送達，如果是其他原因，就要多方面（比如用戶歷史取消訂單次數(shù)，用戶是否為會員，用戶訂單次數(shù)等）考慮，進行處理。

用戶投訴：用戶選擇投訴原因，就要考慮是商家還是騎手的原因。我們可以規(guī)定一個商家出餐的平均值時長，如果商家出餐超過這個時間，我們就判定為投訴商家，否則斷定為投訴騎手。

2. 商家

比如用戶下單之后，要考慮商家是否接單（接單狀態(tài)與不接單狀態(tài)），如果商家選擇接單，就要考慮是否直接同步通知給騎手。

3. 騎手

騎手在商家確認收餐后，注意要確認收餐，傳給后臺消息，一方面平臺可以更新前端展示信息“騎手已接餐，距您xxx公里”給用戶；另一方面平臺在收到用戶催單消息時，可以判斷出來是應該催促騎手了。

總結(jié)

本文只是簡單介紹了用戶下單到收餐的整個業(yè)務的各個角色在各個場景下的流程，對于實際的用戶下單到收餐來說，肯定不是這樣簡單地邏輯簡單地算法，希望各位前輩批評指正。

本文由 @抓馬小姐姐 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載