外賣產品從下單到收貨的業務流程研究
外賣產品下單到收貨參與到的角色有使用者、商家、騎手、以及平臺系統；這四個角色和角色各個對應的場景活動構成了外賣產品的業務流程。
使用者從下單到收貨的整個業務場景的流轉需要多個角色的支援配合。
下單到收貨參與到的角色有使用者、商家、騎手、以及平臺系統，想清楚各個場景對應的關係。下單到收餐的流轉主要依靠這些角色的完美供應。
我們來具體分析這幾種角色。
第一：對應的C端使用者的角色，使用者的相關許可權為下單、支付、催單、退單、評價。
第二：商家、出餐者，店鋪的相關許可權為通知騎手來取餐、出餐。
第三：騎手，騎手的許可權為送餐。
第四：平臺系統，平臺系統的功能為簡訊服務、獎懲機制、運力分配等相關功能。
前端訂單展示
前端訂單系統主要包括2大塊的展示：訂單資訊和訂單狀態，其實使用者更多的是關心訂單狀態。
1. 訂單資訊：
配送資訊：
配送服務、配送騎手、騎手距離、預計到達時間、期望時間、配送地址；是必須展示的要素，來提升使用者體驗，便於使用者檢視，實時準確得知食物資訊。配送地址、聯絡方式是騎手送達的根據。
訂單資訊：
訂單號碼、下單時間、支付方式；是必須展示的要素，便於使用者核對訂單。
2. 訂單狀態：
待支付訂單：
已下單但未支付的訂單，針對此類訂單，平臺會設定一個自動取消的時間，比如未付款（美團和餓了麼都是15分鐘後）自動取消，平臺就會取消使用者的此訂單。使用者在15分鐘內可以選擇取消訂單或者去支付訂單。
已支付但商家未接單：
介面提示使用者“正在通知商家”。
商家已接單：
介面提示使用者“商家正在努力製作中”。
騎手接單：
訂單狀態為“騎手已接單”。
騎手配送訂單：
訂單狀態為“騎手還剩xxx分鐘到達”。
騎手送達訂單：
訂單狀態為“騎手已到達”。
使用者取餐成功：
訂單狀態為“訂單已完成”。
下單到收餐的業務流程
前端系統雖然會對訂單資訊和狀態進行展示，但這些訂單資訊和狀態在後臺業務中是如何有效進行的，各個場景下各個角色如何高效合作，最終展示在前臺，是非常重要和複雜的。
下圖是使用者從下單到收餐的一個業務流程泳道圖：
我們可以看到：使用者在前端可見的幾個訂單狀態變化，其實在後臺經過了很多角色的協助。
下面介紹各個角色之間需要重點注意的流程狀態點：
1. 平臺系統
使用者在下單支付成功後，平臺需要提醒商家app資訊通知，商家得知訂單訊息，才能接單確認訂單，平臺在使用者和商家下單、接單。
商家如果接單狀態，就要考慮是否將接單通知同步給騎手，然後騎手如何選擇？
上面業務流程圖只考慮了系統派單的情況，如果有商家自己的騎手，那麼優先派單之後就進行搶單模式。
平臺派單騎手的選擇：首先確定騎手是否超載（最高6單），然後對騎手進行選擇，比如騎手信譽、個人積分、使用者評價、騎手型別（自營騎手還是加盟騎手）、騎手距離等因素多方面考慮，確定騎手。
騎手取餐時間的選擇：騎手取餐時間一般是接單後和備餐完成之前取一箇中間值，那我們利用平均值（均值）演算法來確定騎手的取餐時間，考慮商家平均出餐速度和騎手平均送餐速度。
使用者催單：平臺就要判斷應該催商家還是騎手還是平臺。當用戶下單商家未接單之前催平臺，當商家接單之後騎手取餐時間之前催商家，當騎手取餐之後催騎手，所以當騎手取餐之後應該給使用者和平臺都有一個通知，提醒騎手已取餐，這樣使用者催單的時候，平臺可以判斷出來應該是催騎手還是商家。
使用者取消訂單：首先平臺規定一定時間內（10分鐘）使用者可以免責取消訂單，原路線返回付款金額。10分鐘以後，使用者選擇取消訂單，平臺就要通知商家，判斷商家是否已經開始製作，沒有製作且商家同意取消原路線返回金額，如果商家已經制作了，使用者就要選擇取消原因，送餐時間慢等就進入催單催促商家或騎手儘快送達，如果是其他原因，就要多方面（比如使用者歷史取消訂單次數，使用者是否為會員，使用者訂單次數等）考慮，進行處理。
使用者投訴：使用者選擇投訴原因，就要考慮是商家還是騎手的原因。我們可以規定一個商家出餐的平均值時長，如果商家出餐超過這個時間，我們就判定為投訴商家，否則斷定為投訴騎手。
2. 商家
比如使用者下單之後，要考慮商家是否接單（接單狀態與不接單狀態），如果商家選擇接單，就要考慮是否直接同步通知給騎手。
3. 騎手
騎手在商家確認收餐後，注意要確認收餐，傳給後臺訊息，一方面平臺可以更新前端展示資訊“騎手已接餐，距您xxx公里”給使用者；另一方面平臺在收到使用者催單訊息時，可以判斷出來是應該催促騎手了。
總結
本文只是簡單介紹了使用者下單到收餐的整個業務的各個角色在各個場景下的流程，對於實際的使用者下單到收餐來說，肯定不是這樣簡單地邏輯簡單地演算法，希望各位前輩批評指正。
本文由 @抓馬小姐姐 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議