起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識外賣產品思考
外賣產品下單到收貨參與到的角色有用戶、商家、騎手、以及平臺系統；這四個角色和角色各個對應的場景活動構成了外賣產品的業務流程。
用戶從下單到收貨的整個業務場景的流轉需要多個角色的支持配合。
下單到收貨參與到的角色有用戶、商家、騎手、以及平臺系統，想清楚各個場景對應的關系。下單到收餐的流轉主要依靠這些角色的完美供應。
我們來具體分析這幾種角色：
第一：對應的C端用戶的角色，用戶的相關權限為下單、支付、催單、退單、評價。
第二：商家、出餐者，店鋪的相關權限為通知騎手來取餐、出餐。
第三：騎手，騎手的權限為送餐。
第四：平臺系統，平臺系統的功能為短信服務、獎懲機制、運力分配等相關功能。
前端訂單展示
前端訂單系統主要包括2大塊的展示：訂單信息和訂單狀態，其實用戶更多的是關心訂單狀態。
1. 訂單信息：
配送信息：
配送服務、配送騎手、騎手距離、預計到達時間、期望時間、配送地址；是必須展示的要素，來提升用戶體驗，便于用戶查看，實時準確得知食物信息。配送地址、聯系方式是騎手送達的根據。
訂單信息：
訂單號碼、下單時間、支付方式；是必須展示的要素，便于用戶核對訂單。
2. 訂單狀態：
待支付訂單：
已下單但未支付的訂單，針對此類訂單，平臺會設置一個自動取消的時間，比如未付款（美團和餓了么都是15分鐘后）自動取消，平臺就會取消用戶的此訂單。用戶在15分鐘內可以選擇取消訂單或者去支付訂單。
已支付但商家未接單：
界面提示用戶“正在通知商家”。
商家已接單：
界面提示用戶“商家正在努力制作中”。
騎手接單：
訂單狀態為“騎手已接單”。
騎手配送訂單：
訂單狀態為“騎手還剩xxx分鐘到達”。
騎手送達訂單：
訂單狀態為“騎手已到達”。
用戶取餐成功：
訂單狀態為“訂單已完成”。
我們可以看到：用戶在前端可見的幾個訂單狀態變化，其實在后臺經過了很多角色的協助。
下面介紹各個角色之間需要重點注意的流程狀態點：
下單到收餐的業務流程圖
我們可以看到：用戶在前端可見的幾個訂單狀態變化，其實在后臺經過了很多角色的協助。
下面介紹各個角色之間需要重點注意的流程狀態點：
1. 平臺系統
用戶在下單支付成功后，平臺需要提醒商家app信息通知，商家得知訂單消息，才能接單確認訂單，平臺在用戶和商家下單、接單。
商家如果接單狀態，就要考慮是否將接單通知同步給騎手，然后騎手如何選擇？
上面業務流程圖只考慮了系統派單的情況，如果有商家自己的騎手，那么優先派單之后就進行搶單模式。
平臺派單騎手的選擇：首先確定騎手是否超載（最高6單），然后對騎手進行選擇，比如騎手信譽、個人積分、用戶評價、騎手類型（自營騎手還是加盟騎手）、騎手距離等因素多方面考慮，確定騎手。
騎手取餐時間的選擇：騎手取餐時間一般是接單后和備餐完成之前取一個中間值，那我們利用平均值（均值）算法來確定騎手的取餐時間，考慮商家平均出餐速度和騎手平均送餐速度。
用戶催單：平臺就要判斷應該催商家還是騎手還是平臺。當用戶下單商家未接單之前催平臺，當商家接單之后騎手取餐時間之前催商家，當騎手取餐之后催騎手，所以當騎手取餐之后應該給用戶和平臺都有一個通知，提醒騎手已取餐，這樣用戶催單的時候，平臺可以判斷出來應該是催騎手還是商家。
用戶取消訂單：首先平臺規定一定時間內（10分鐘）用戶可以免責取消訂單，原路線返回付款金額。10分鐘以后，用戶選擇取消訂單，平臺就要通知商家，判斷商家是否已經開始制作，沒有制作且商家同意取消原路線返回金額，如果商家已經制作了，用戶就要選擇取消原因，送餐時間慢等就進入催單催促商家或騎手盡快送達，如果是其他原因，就要多方面（比如用戶歷史取消訂單次數，用戶是否為會員，用戶訂單次數等）考慮，進行處理。
用戶投訴：用戶選擇投訴原因，就要考慮是商家還是騎手的原因。我們可以規定一個商家出餐的平均值時長，如果商家出餐超過這個時間，我們就判定為投訴商家，否則斷定為投訴騎手。
2. 商家
比如用戶下單之后，要考慮商家是否接單（接單狀態與不接單狀態），如果商家選擇接單，就要考慮是否直接同步通知給騎手。
如果商家不接單，平臺規定一段時間（根據商家平均接單速度確定一個時間）內商家不接單，自動取消用戶訂單，app提醒用戶訂單未受理，需要重新下單。
3. 騎手
騎手在商家確認收餐后，注意要確認收餐，傳給后臺消息，一方面平臺可以更新前端展示信息“騎手已接餐，距您xxx公里”給用戶；另一方面平臺在收到用戶催單消息時，可以判斷出來是應該催促騎手了。
總結
本文只是簡單介紹了用戶下單到收餐的整個業務的各個角色在各個場景下的流程，對于實際的用戶下單到收餐來說，肯定不是這樣簡單地邏輯簡單地算法，希望各位前輩批評指正。
本文由 @逛吃逛吃 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
1.大體的外賣主流程，和界面要素，能想清楚，但是流程圖很亂，邏輯上有待加強
2.在流程中，要區分哪些內容是要放在流程上的，人為觸發的動作，和系統判斷，可用不同的顏色作出區分；流程圖不要往回畫
3.外賣有很多其他分支流程，放在一起很冗余，做分析的時候，可以從某一個小點來出發，讓自己的思路精細化
謝謝，我會在復盤改進的
我最近也在做外賣的產品，剛好看到，給了我一些啟發
確實是個入門外賣產品的好文章，請問外賣思考2在哪里呢？
很贊，邏輯清晰，表達清晰，版面清晰
謝謝哈
1.訂單狀態中，還應該有一種情況“騎手前往取餐中”；
2.流程圖有一些小bug。平臺系統方面，如果判斷騎手超載，此時的選擇應該是選擇其他的騎手，而不是循環回去，如果循環回去就成了一直判斷，無法分配騎手了。同時，用戶在催單后，判斷外賣的位置，判斷完畢之后會有相應的措施，也就是流程圖不夠完整，用戶投訴后同理。用戶方面，如果下單之后，商家選擇不接單（突發情況，或在用戶下單的途中店鋪關閉等），那么是否需要給用戶一個反饋。商家方面，騎手的取餐應該是在商家備餐完畢后進行的，而不是備餐完畢之前。
以上也只是我的一點小看法和小建議。
本人對作者還是非常敬佩的，加油
嗯呢，我繼續改進，不過我還是覺得騎手的取餐是在接單后和出餐前取一個中間值，我認為這樣是合理的。
騎手前往取餐會花費一些路程，到達之后出餐完畢，正好可以進行取餐。如果是備餐結束，騎手在過來取餐，一方面要考慮騎手到店需要的時間，可能導致食品變涼等情況，一方面要考慮用戶投訴的情況。
現實中我們也可以看到，騎手的取餐不是在商家備餐完畢進行的，我們會看到有些情況下騎手會在店鋪等待食物，也就說明騎手取餐不是在商家備餐完畢進行的。
咱們互相交流看法哈
1、有個開始和結束的流程更好；
2、泳道圖可以畫的更清晰些（位置太擠了），能減少線條的交叉盡量減少。
已經很贊了~加油繼續寫下去
謝謝，我繼續去改進一下。
妹子是要去外賣公司面試嗎
還沒找實習呢，就是平常學習思考的寫下來。
商家不接單怎么辦…
文章里面只考慮了商家接單狀態的流程。如果商家不接單，平臺規定一段時間（根據商家平均接單速度確定一個時間）內商家不接單，自動取消用戶訂單，app提醒用戶訂單未受理，需要重新下單。
亂，有待提升，加油！
好的。
在補充一點，
狀態最好用橫向的階段來區分，更明顯些
好的，我繼續改進。
說兩小點吧
1.流程圖最起碼有個開始和結束，否則閱讀者很懵逼。
2.雖然是泳道圖，但是應該有向時序圖一樣的發生的先后順序，不然閱讀者看就像迷宮一樣。
不錯，泳道圖做的有點復雜并且有點小bug，按時序圖對流程順序標注一下應該會更清晰一點
好的，謝謝哦
v
不懂V什么意思，哈哈哈，希望批評指正哦
拿第一個流程圖給老板看？猜老板什么反應！
被瘋狂吐槽??？哈哈，望批評指正
棒棒噠
zan