從0到1,學習訂單管理體系
訂單系統是看似簡單,實際上是一個邏輯復雜的系統,具體的流程設計,應與自身的業務緊密結合,同時涉及到與其他各大系統的緊密配合,需要不斷的去優化,讓各個系統的配合更加流暢多樣。
一、概述
接受客戶訂單信息,以及倉儲管理系統發來的庫存信息,然后按客戶和緊要程度給訂單歸類,對不同倉儲地點的庫存進行配置,并確定交付日期,這樣的一個系統稱為訂單管理系統。
訂單管理是物流管理的一部分,是電商體系的核心部分,它承載著服務與客戶交互的整個過程記錄。本文是近段時間的學習和總結,希望通輸入-計算-輸出的模式,加強對內容的理解。
二、訂單系統與其他系統的關系和架構
訂單系統的作為整個電商體系的中游,對上承接用戶信息,將用戶信息轉化成產品訂單,同時管理并跟蹤訂單數據;對下與各個系統配合協作,實現整個電商體系的閉環,在整個電商平臺起著承上啟下的重要地位。
三、訂單管理解構
1. 訂單信息
由支付信息、商品信息、訂單基本信息、優惠信息、收貨信息、用戶信息、物流信息和其他信息,這些信息來源于其他系統的信息,一起構成全面的信息記錄。
2. 訂單狀態和狀態機
訂單狀態是交易進展的反饋,是訂單流程的一個個連接點。不同業務類型的訂單狀態,例如機票、服務訂單、商品服務訂單等,和最常見的純實物商品的訂單狀態會有所區別,但訂單狀態總體有以下幾種類型:(下圖是來源網絡)
狀態機是訂單狀態邏輯的工具。狀態機可以分為三個要素:現狀、動作、次態。
- 現狀:指當前所處的狀態;
- 動作:指狀態發生轉變的操作;
- 次態:動作滿足后新產生的狀態。
狀態機是流程的一種補充,其設計也需要結合平臺的實際業務場景,以一個商品訂單為例:
通常,訂單的狀態的變更伴還隨著訂單的推送,涉及到的信息包括:
- 推送對象(用戶,商家,倉庫)
- 推送方式(站內消息,push,短信,微信模板消息)
- 推送節點(狀態機變更)
3. 訂單流程
訂單流程是指整個訂單從產生到完成的整個流轉過程。不同的服務模式對應的訂單流程都會根據自身的業務進行調整。
從典型的電商訂單流程切入,拆解為:正向流程、逆向流程。
(1)正向流程
正常下單,下圖為訂單完整的的流程:
拆單流程:拆單,指客戶在下單之后,出于發貨和結算的角度,對訂單進行拆分。
1. 拆單的影響因素
- 商家:商品不屬于同一家商家,需將訂單拆分,便于商家的結算、和發貨管理。如淘寶多家商品一起結算,會以商家為基線,拆成不同的訂單。
- 倉庫:同一商家,不同倉庫,發貨配送不同,商品物流信息和到貨時間不一致。
- 品類:產品為特殊品類的,如易碎品,需與其他商品分開包裝。
- 物流:不同的物流公司對單個包裹的重量或體積有特殊要求,需要根據sku的毛重和體積計算包裹重量和體積,超出物流公司限制的也需要拆單。
2. 拆分規則
- 父單必須拆凈,即父單商品數量等于子單商品數量之和。
- 父單商品金額、運費、支付金額、虛擬幣金額、優惠金額要與子單金額相等。
- 子單實付大于0。
- 第三方訂單按商家維度拆分、自營(不包括虛擬和廠商直送、線下交易等特殊訂單類型)按庫房維度拆分。
- 贈品不分攤優惠,延保必須跟主單。
3. 拆單流程圖
(2)逆向流程
在訂單生成之后,訂單在各個狀態的流轉過程中,都可能會出現逆向流程,分為:僅退款和退貨退款。
在不同節點發生,系統的處理方式不同。
1. 待付款取消訂單
當用戶提交訂單后主動取消訂單或者用戶超時未支付時,訂單的狀態變更為“已取消”,無需經過客服審核。
2. 待發貨取消訂單
當訂單在“待發貨”狀態時,用戶申請取消訂單,如下圖所示,由于用戶在支付訂單后,發貨單可能已經推送至倉儲系統,甚至已經交接發貨,狀態未及時回傳更新。為避免貨款兩失要進行訂單攔截,若攔截失敗,則拒絕“取消訂單”申請,回復原因“訂單已庫”;若攔截成功,“取消訂單”申請通過,進入退款流程,同時通知調度中心該訂單取消,訂單進入返庫流程。
3. 待確認收貨/交易完成
在待確認收貨中申請退款,一般商品已經進入物流配送環節到達用戶手中,此時的逆流程分為退款/退貨退款,下面分別就兩種情況進行說明:
退款
這種場景一般是:物件損壞、快遞丟件、錯發漏發。
退貨退款
在待收貨或者交易完成后的退款,流程如下,賣家同意退款前的流程與退款的流程類似,但在同意退款后,買家端會看到賣家的退貨信息,包括姓名、地址、電話等退貨相關信息,用戶在寄出商品后,商家會進行驗收確認,確認無誤后再進行退款,如果在驗收環節有問題的話,一般會走線下協商,要么將貨品發回給用戶,要么退部分款項。
以上為主要的售后場景流程,但訂單的逆向流程復雜多樣,需要兼顧業務場景。期間涉及到與倉儲系統、財務系統的配合協作。保證數據變化的可追溯性,每一次數據的變化,都不能直接在原數據上直接修改,而需要生成相應單據憑證。
4. 訂單數據
訂單沉淀下的數據和信息,對平臺的運營和產品的改善起著關鍵的指導作用??煞譃槌R幗y計和流量分析統計。
(1)常規統計
常規統計,一般指財務數據方面的統計,主要包括銷售額、毛利、成本、純利潤、客單價等。
(2)流量分析統計
側重于指導平臺運營的數據,如訪客數、瀏覽量、支付轉化率等。
在訂單流量分析中又分為三個維度,分別從訂單交易緯度、商品緯度、訂單來源等三方面來分析。
- 訂單交易維度:訂單銷售額、訂單數量、客單價、下單用戶數與支付用戶數、訂單金額分布梯度、地域分布;
- 商品維度:被下單商品數、被支付商品數、被訪商品數、商品收藏次數、商品銷量統計;
- 訂單來源:訂單的來源媒介和用戶端,記錄每個訂單的產生流程,追蹤訂單來源。
四、總結
訂單系統是看似簡單,實際上是一個邏輯復雜的系統,具體的流程設計,應與自身的業務緊密結合,同時涉及到與其他各大系統的緊密配合,需要不斷的去優化,讓各個系統的配合更加流暢多樣。
經過這一段時間的學習,也只能了解到一些基本的要素和流程,希望通過整理和輸入,幫助自己更好的學習和掌握,也希望對他人有所幫助。
參考資料:
《電商經理產品寶典》
《訂單系統:從0到1設計思路》
百度百科
本文由 @土豆仙人 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pexels ,基于 CC0 協議
寫的很詳細,從標題的目的來看,從0到1的認知,絕對滿足了,
請問泳道圖是用什么工具畫的,謝謝。
一個地方不是很了解,為什么拒絕取消訂單,就直接到結束了呢,不是訂單按照正常發貨流程走嗎?
那里指的是取消訂單流程的結束
沒有確認訂單環節嗎?不是確認下單前要檢查庫存。確認訂單后再一下檢查庫存,若無庫存,下單失敗,有庫存下單成功。
要結合商品看,有些場景可以不用校驗庫存的, 常規的一般都需要校驗庫存。庫存的校驗,是訂單能否生成的關鍵因素,題主可能沒怎寫這塊,更多都是訂單履單層面的東西
什么場景下不用校驗庫存呀
在線教育虛擬產品,不需要校驗
訂單發生狀態改變時。需要記錄動作?場景如下審核點單是,點開訂單后查看,并沒做出審核同伙或者駁回,狀態要記錄為審中嗎?這就結束了?
你們的商家結算規則會在訂單中提現嗎?比如結算價的計算規則、傭金的計算規則
這個不是財務系統的內容嗎
先分清什么系統做什么事情。兩個系統交互。唯一標識符是什么