• 生成訂單

• 使用者確認訂單

商品資訊：商品資訊屬於訂單系統的上游端，所有訂單都是從商品演進而來，從商品到訂單，訂單系統必須蒐集相關的商品資訊，包括店鋪資訊，商品id，商品規格，商品數量，商品價格。獲取到的商品資訊將在訂單詳情頁內展示，形成訂單資訊後供倉庫方便揀貨，包裝。

使用者資訊：使用者資訊包括購買使用者的ID，收貨人，收貨地址，聯絡方式。有些平臺的使用者成長體系是基於使用者對平臺的活躍度來計算的，例如京東，它有會員等級及積分卡等類似的成長標識，此時獲取到的使用者資訊除了普通的資訊欄位外，還需要獲取該使用者的等級，該次購買後所獲得的積分，以及該使用者所在等級能在該訂單上扣除的優惠等資訊，具體怎麼操作取決於公司的業務方向。

金額資訊：因為金額資訊的特殊性，所以獨立出來講，理論上金額資訊應歸屬商品資訊。金額資訊的特殊性在於其不止一種金額，其涉及到商品金額，優惠金額，支付金額。而優惠金額中涉及到的資訊較複雜，像有自營和第三方入駐的電商平臺，都會有商家優惠和跨店優惠，而這些優惠又分不同型別，例如現金扣減，消費券扣減，積分獲取，禮品卡扣減，或者以上幾種的組合使用。想要涉及好這一塊內容，需要根據目前自己公司的業務情況，列出所支援的優惠型別，再枚舉出各種組合下的優惠型別，才能保證流程的完整性。

時間資訊：記錄各個卡點下的時間，一是記錄，二也是方便售後驗證和客戶分析。訂單時間是根據訂單狀態改變而改變的，比如：我們常見的使用者。

• 下單未付款：即展示訂單建立時間、下單時間；
• 待發貨狀態：展示訂單建立時間、下單時間、支付時間；
• 待收貨狀態：展示訂單建立時間、下單時間、支付時間、發貨時間；
• 交易完成狀態：展示訂單建立時間、下單時間、下單時間、支付時間、發貨時間、完成時間；
• 待退款狀態：展示退款訂單建立時間、申請退款時間；
• 交易關閉-使用者取消：展示訂單建立時間、下單時間、使用者取消時間；
• 交易關閉-僅退款：訂單建立時間、下單時間、支付時間、退款申請時間、退款成功時間；
• 交易關閉-退貨退款（包含部分僅退款）：訂單建立時間、下單時間、支付時間、交易完成時間、退款申請時間、退款時間。

訂單資訊：訂單資訊在訂單系統最為核心，訂單資訊最重要的又是訂單狀態。

電商購物中，訂單狀態分別有以下幾種：【待付款】、【待發貨】、【待收貨】、【待評價】、【交易完成】、【使用者取消】、【僅退款】、【退貨退款】。而我們一般會將後三種統一放在訂單售後獨立呈現，去方便平時商家操作的便捷性。

• 訂單流程

訂單流程是指從訂單產生到完成整個流轉的過程，其中包括正想流程和逆向流程。正向流程就是一個正常的網購步驟：訂單生成–>支付訂單–>賣家發貨–>確認收貨–>交易成功。

1、正向流程

訂單生成：使用者下單後，系統需要生成訂單，此時需要先獲取下單中涉及的商品資訊，然後獲取該商品所涉及到的優惠資訊，如果商品不參與優惠資訊，則無此環節。

接著獲取該賬戶的會員權益（這裡其實需要注意的是：優惠資訊與會員權益是有區別的，就好比商品滿減是優惠資訊，新人立減是會員權益，一個是針對商品，另一個是針對賬戶）。

庫存扣減是指可銷售庫存數量-1，嚴格來講庫存扣減目前分為兩種：

• 一種是下單減庫存；
• 另一種是付款減庫存。

個人覺得中小創業者也許競爭者不比淘寶中的賣家，在電商這個存量市場，需要精細化的運營才能存活下來，如此說保證使用者體驗才是根本。所以我這裡的觀點是生成訂單扣減庫存，這種做法會避免使用者支付成功商家卻沒貨的情況。然後計算運費，訂單生成成功。

支付訂單：使用者支付完訂單後，需要獲取訂單的支付資訊，包括支付流水號、支付時間等。支付完訂單接著就是等商家發貨，但在發貨過程中，往往還有一種情況存在，很正常卻也比較複雜，就是訂單拆單。

• 訂單拆單分兩種：一種是使用者挑選的商品來自於不同渠道（自營與商家，商家與商家），此時就需要拆分訂單，並分開結算，這裡還涉及父子訂單的說法，這裡不再贅述。
• 另一種是在SKU層面上拆分訂單：不同倉庫，不同運輸要求的SKU，包裹重量體積限制等因素都需要將訂單拆分。比如：商品A只在甲倉庫有，商品B又只在乙倉庫有，此時會將商品A與商品B拆分成兩個訂單。或者有些企業的做法是將商品A/B調撥到另外一個倉庫統一發貨，也方便了使用者。

訂單拆單看起來簡單，其實裡面涉及到底層的系統支援，如你需要對每一個倉庫的貨品進行相對準確的盤點，且做到實時同步（涉及到倉庫精細化管理），對商品進行準確分類與擺放，對商品資訊記錄準確無誤等。

這其中哪一模組都是一個浩大的工程，PM一般進入一家公司都會在原有（半成品）的基礎上進行優化，大家不妨多思考一下底層業務，只有在底層做好精細化管理，才能支援線上豐富的使用者需求。

商家發貨：商家發貨過程也有一個標準化的流程，上面也有講到，訂單拆分時會涉及到倉庫間調撥，然後倉庫會對商品進行打單、揀貨、包裝、交接快遞配送。這套標準化流程如果優化好，也是一個大工程，這裡不再贅述，建議大家看看庫存與倉庫管理方面的書籍，詳細瞭解。

確認收貨：商家發貨後，就是等快遞配送了，訂單系統需要接入一些常用快遞企業的介面，方便使用者與商家在站內查詢快遞資訊。

交易成功：收到貨後，不是一個服務的結束，相反是一個服務的開始。訂單系統需要在快遞被簽收後提醒使用者對商品做評價，這裡要注意，確認收到貨不代表交易成功，交易成功是指在收到貨X天的狀態，此時訂單不在售後的支援時間範圍內。到此，一個訂單的正向流程就算走完了。

目前我也沒有研究過，不過我的經驗告訴我訂單系統對售後訂單的處理並不比正產訂單少，身為電商PM，我們的工作就是去優化這些流程，提高使用者粘性。本身售後訂單的出現，在某種程度上已經傷害到了使用者，如果流程還一團糟的話，我們根本沒有機會等到使用者的復購。

2、逆向流程

取消訂單：使用者提交訂單時，在跳轉至支付前直接退出，此時使用者原則上屬於取消訂單，因為還未付款，則比較簡單，只需要將原本提交訂單時扣減的庫存補回即可。

支付失敗：使用者進行支付時退出，或者取消支付，我們將其列為支付失敗狀態，此時處理同上，將扣減的庫存補回可銷售庫存即可。

付款後退款：使用者支付成功後，商家還未發貨，支援使用者申請退款，此時如果倉庫與客服是分離的，則需要先檢查倉庫是否已經發貨，若已發貨則應與客戶溝通是否可以收到貨後再進行退款，如果倉庫還未發貨，則可直接同意使用者退款。或者企業接入菜鳥物流，實行截件功能，不過這種操作還不成熟，成本會比較大，不適合中小創業型公司。

缺貨退款：使用者支付成功後，商家發貨時發現倉庫缺貨（如果提交訂單扣減庫存，則會減少缺貨情況，為什麼是減少而不是避免？因為倉庫管理商品時沒辦法做到100%精準，所以資訊有時候會不準確，導致線上的可銷售庫存顯示有庫存而倉庫已經售空的狀態），則需要與使用者協商是否退款。

這個流程訂單系統可以做到流程化、自動化，連線訊息中心和倉庫管理系統去實現，難點在於訊息的實時性。我就遇到過在淘寶買過一件上衣，一天過去了，商家跟我說沒貨了，我當時殺人的心都有了。

待收貨退款：這個問題目前還沒有特別完美的解決方法，商家發了貨之後，使用者還未收到貨，此時貨在路上。

我曾經在一些交流群裡提出過這個問題，大家的看法都不一樣，大體上分為兩種做法：

• 一種是使用者收到貨後重新寄回；
• 另一種是使用者直接拒收包裹，包裹直接退回原地址。

我個人傾向於第一種，第一種比較靈活，因為使用者未收到貨就退款的原因一般與商品質量關係不大，所以如果允許使用者直接拒收退回，相當於商家需要承擔回退運費，而本身可能與商家並無太大關係。

另外一個原因就是，有些商家發貨地址與退貨地址不在同個地方，不支援直接退回。儘管如此，在到處強呼叫戶體驗的今天，增加使用者的售後成本也是在消耗使用者對平臺的耐心，大家不妨去思考一下，有沒有更好的解決方法。

訂單推送

訂單推送的觸發依賴於狀態機的改變，涉及到的資訊包括：

• 推送物件（使用者、商家、倉庫）；
• 推送方式（站內訊息、push、簡訊、微信）；
• 推送節點（狀態機）。