外賣(mài)產(chǎn)品下單到收貨參與到的角色有用戶(hù)、商家、騎手、以及平臺(tái)系統(tǒng)；這四個(gè)角色和角色各個(gè)對(duì)應(yīng)的場(chǎng)景活動(dòng)構(gòu)成了外賣(mài)產(chǎn)品的業(yè)務(wù)流程。

用戶(hù)從下單到收貨的整個(gè)業(yè)務(wù)場(chǎng)景的流轉(zhuǎn)需要多個(gè)角色的支持配合。

下單到收貨參與到的角色有用戶(hù)、商家、騎手、以及平臺(tái)系統(tǒng)，想清楚各個(gè)場(chǎng)景對(duì)應(yīng)的關(guān)系。下單到收餐的流轉(zhuǎn)主要依靠這些角色的完美供應(yīng)。

我們來(lái)具體分析這幾種角色：

第一：對(duì)應(yīng)的C端用戶(hù)的角色，用戶(hù)的相關(guān)權(quán)限為下單、支付、催單、退單、評(píng)價(jià)。

第二：商家、出餐者，店鋪的相關(guān)權(quán)限為通知騎手來(lái)取餐、出餐。

第三：騎手，騎手的權(quán)限為送餐。

第四：平臺(tái)系統(tǒng)，平臺(tái)系統(tǒng)的功能為短信服務(wù)、獎(jiǎng)懲機(jī)制、運(yùn)力分配等相關(guān)功能。

前端訂單展示

前端訂單系統(tǒng)主要包括2大塊的展示：訂單信息和訂單狀態(tài)，其實(shí)用戶(hù)更多的是關(guān)心訂單狀態(tài)。

1. 訂單信息：

配送信息：

配送服務(wù)、配送騎手、騎手距離、預(yù)計(jì)到達(dá)時(shí)間、期望時(shí)間、配送地址；是必須展示的要素，來(lái)提升用戶(hù)體驗(yàn)，便于用戶(hù)查看，實(shí)時(shí)準(zhǔn)確得知食物信息。配送地址、聯(lián)系方式是騎手送達(dá)的根據(jù)。

訂單信息：

訂單號(hào)碼、下單時(shí)間、支付方式；是必須展示的要素，便于用戶(hù)核對(duì)訂單。

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

待支付訂單：

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

已支付但商家未接單：

界面提示用戶(hù)“正在通知商家”。

商家已接單：

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

騎手接單：

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

騎手配送訂單：

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

騎手送達(dá)訂單：

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

用戶(hù)取餐成功：

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

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

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

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

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

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

1. 平臺(tái)系統(tǒng)

用戶(hù)在下單支付成功后，平臺(tái)需要提醒商家app信息通知，商家得知訂單消息，才能接單確認(rèn)訂單，平臺(tái)在用戶(hù)和商家下單、接單。

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

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

平臺(tái)派單騎手的選擇：首先確定騎手是否超載（最高6單），然后對(duì)騎手進(jìn)行選擇，比如騎手信譽(yù)、個(gè)人積分、用戶(hù)評(píng)價(jià)、騎手類(lèi)型（自營(yíng)騎手還是加盟騎手）、騎手距離等因素多方面考慮，確定騎手。

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

用戶(hù)催單：平臺(tái)就要判斷應(yīng)該催商家還是騎手還是平臺(tái)。當(dāng)用戶(hù)下單商家未接單之前催平臺(tái)，當(dāng)商家接單之后騎手取餐時(shí)間之前催商家，當(dāng)騎手取餐之后催騎手，所以當(dāng)騎手取餐之后應(yīng)該給用戶(hù)和平臺(tái)都有一個(gè)通知，提醒騎手已取餐，這樣用戶(hù)催單的時(shí)候，平臺(tái)可以判斷出來(lái)應(yīng)該是催騎手還是商家。

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

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

2. 商家

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

如果商家不接單，平臺(tái)規(guī)定一段時(shí)間（根據(jù)商家平均接單速度確定一個(gè)時(shí)間）內(nèi)商家不接單，自動(dòng)取消用戶(hù)訂單，app提醒用戶(hù)訂單未受理，需要重新下單。

3. 騎手

騎手在商家確認(rèn)收餐后，注意要確認(rèn)收餐，傳給后臺(tái)消息，一方面平臺(tái)可以更新前端展示信息“騎手已接餐，距您xxx公里”給用戶(hù)；另一方面平臺(tái)在收到用戶(hù)催單消息時(shí)，可以判斷出來(lái)是應(yīng)該催促騎手了。

總結(jié)

本文只是簡(jiǎn)單介紹了用戶(hù)下單到收餐的整個(gè)業(yè)務(wù)的各個(gè)角色在各個(gè)場(chǎng)景下的流程，對(duì)于實(shí)際的用戶(hù)下單到收餐來(lái)說(shuō)，肯定不是這樣簡(jiǎn)單地邏輯簡(jiǎn)單地算法，希望各位前輩批評(píng)指正。

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

題圖來(lái)自Unsplash，基于CC0協(xié)議