商品訂單是各種經濟業務中最常見、重要的憑證，是會計核算的依據，是經濟交易雙方是否履約的證明。因此，在電商生態系統中，訂單管理模塊尤其重要。本文將以B2C平台為例，從業務的角度分別講述電商訂單模塊中，客戶端和後台設計的要點。

業務模式

不同的電商的模式有不同的業務內容和業務流程。在設計訂單模塊的第一步，是要明確企業的商業模式。根據是否有第三方商家，可以分為平台型、自營型等；根據是否交易雙方的身份角色，可以分為 C2C、B2C、B2B、F2C、C2M，還有經常聽到的分銷電商、網紅電商、社交電商等。

• F2C/M2C：factory/manufacturers to customer，指生產廠商對個人消費者的電子商務，如網易嚴選。
• C2M：customer to manufacturers，指個人對生產廠商的電子商務，強調個性化工業定製，如必要商城。
• 分銷電商：在法律允許範圍內，每個人都可以成為分銷商，利用社交圈進行商品銷售傳播，如雲集。

不同商業模式的訂單有著天然的差別，如C2C電商一般不涉及大型倉儲管理系統，在整體流程上比B2C電商簡單一些，具體表現為欄位信息不同、後台訂單無需拆單等。具體的訂單模塊需要針對企業具體業務需求來進行規劃。

業務流程

一次商品交易業務包括：購買商品和售後服務，售後服務包括換貨、僅退款、退貨退款等。

一張訂單中包含用戶信息、商品信息、優惠信息、支付信息、物流信息、訂單信息、其他信息（發票、保險），對應的需要從後台管理系統的用戶中心、商品中心、促銷中心、支付中心、物流中心、訂單中心等獲取數據來支持服務。

根據購買的商品類型，可以將訂單分為實物商品訂單和虛擬商品訂單，虛擬訂單沒有物流信息。以下描述全部是有關B2B電商平台實物商品交易的業務流程。

用戶下單（客戶端）

以京東的結算頁面作為用戶端訂單信息的例子：

• 訂單狀態：待支付、待發貨、待收貨（或部分發貨）、已完成、已取消、售後中。
• 收貨信息：收貨地址關聯到運費的計算、商品庫存（商家存在多倉庫），生成訂單後，發貨前可以允許用戶在限定的範圍內修改收貨信息，如在同一倉庫的運送範圍內，允許修改收貨地址，這樣會帶來良好的用戶體驗。
• 支付方式：支付方式有線上支付和線下支付兩種方式。常見的線上支付方式有第三方支付、餘額抵扣、虛擬幣抵扣，朋友代付，線下支付有貨到付款、便利店充值、銀行匯款等。用戶在支付過程中，可能會因為密碼錯誤餘額不足等情況導致支付失敗，支付失敗返回後的訂單應該處於待付款狀態。
• 商品信息： 生成訂單時，一般只允許修改商品的數量。生成訂單後，不允許用戶修改商品信息。
• 優惠信息：電商商家為了促進用戶消費，時常有優惠活動。優惠信息包括活動優惠、優惠券優惠、金幣抵扣等。如果有優惠疊加的情況，需要注意優惠金額分攤的順序和金幣抵扣的順序。假設商品不包郵，用戶使用金幣抵扣後，抵扣掉訂單的一半金額，如果系統先抵扣運費的話，分攤到每個商品上優惠後的價格會增加，當用戶申請退貨時，商家的最終利潤就會受到影響。所以含有優惠活動的平台，一定要做好優惠規則策略。
• 匿名購買：用戶選擇匿名購買後，商品評價中的用戶暱稱會按照一定規則顯示。
• 訂單備註：如果訂單中存在多個商家的商品，下單後系統會對訂單進行拆單，因此應該允許用戶對每一個商家填寫備註內容。

商家接單（後台管理系統）

一般電商台會在用戶下單後系統自動幫助商家立即接單，也可以這是自動接單的時間。商家在後台看到用戶下單後，可以根據實際的商品庫存，而非平台上的商品庫存（假設商家在多個平台上銷售同一件商品）判斷是否繼續交易。允許商家手動接單從另一個角度看，給了商家一定的自由度。

鎖定庫存：商品的庫存鎖定有兩種方案：一種是「下單後支付前」鎖定，一種是「支付後」鎖定庫存。「下單後支付前」鎖定庫存可以保證良好的用戶體驗，但是可能會導致商品一直處於占用狀態，使有緊迫需求的用戶無法購買。「支付後」鎖定庫存因為時間差，可能會導致下單時庫存與支付時庫存不一致的問題，特別是像秒殺類營銷活動的商品。解決方案可以是普通商品和活動商品分別採取兩種鎖定庫存的方法，或者限制待付款訂單的支付時間和支付數量等。

訂單信息：訂單管理系統中應該按照商品來管理數據，而不是訂單。從兩個方面考慮，假設一張訂單中包含多個商品，當用戶只對其中一個商品申請取消交易時，這張訂單的狀態不應該收到影響，而是另外生成一張服務單。只有當訂單中的全部商品都取消交易時，訂單才會被更改為取消交易狀態。因此訂單管理中，實際上時同時記錄了商品的狀態和訂單的狀態。

訂單拆單：電商行業中，經常會接觸到「拆單」這個詞，拆單的原因並不難理解，以兩個常見的業務場景為例說明：

• 場景一：用戶A在某平台上同時購買B、C兩個商家的商品，為了簡化用戶付款流程，平台在客戶端寫成一張訂單。用戶付款後，平台需要分別告訴B、C兩個商家用戶的購買信息，但是又不能讓兩個商家看到對方的數據，平台將原來的一張訂單拆分成兩個子訂單發送給兩個商家。
• 場景二：用戶A在B商家購買了兩件商品，但是兩件商品分別在兩個不同的倉庫，平台需要分別告訴這兩個倉庫的人員進行發貨，為了避免數據混亂，平台將原來的一張訂單拆分成兩個子訂單分別發送給兩個倉庫。

由以上場景可以看出，訂單拆單的最常見的原因是進行數據隔離，避免數據混亂。除此之外，品類（易碎品需要分開發貨）、物流（按體積重量計算運費的商品分開發貨）、政策（跨境商品報關金額限制）也是訂單拆單的重要影響因素，並非所有電商訂單系統都要拆單，也並不是每一張訂單都要拆單。

修改商品信息：商家修改了商品的SKU信息或者下架商品，待支付狀態的訂單系統應該自動取消，特別是商品金額發生變化的，否則就會引起商家與用戶糾紛。

商家發貨（後台管理系統）

物流信息：常見的物流方式有四種：商家自有物流、平台自有物流、商家自己聯繫第三方物流、平台聯繫第三方物流。如果是商家自己負責聯繫物流公司的話，則需要自己是手動添加物流信息。如前文所言，訂單中心是根據商品來管理數據的，因此商家發貨的時候也是按照商品進行發貨，如果商品數量太大，可能會分開幾次發貨，因此一張訂單可能會對應多張物流單信息，會存在部分發貨狀態。

系統自動收貨：即系統在商家發貨一定時間後，自動幫助用戶收貨，結束訂單。系統自動收貨算是保障商家利益的一種手段，因為如果用戶一直不確認收貨，平台則無法與商家結算帳單。

修改信息：在商品正式發貨前，商家可以修改有限的訂單信息，如收貨人信息、部分商品信息、部分費用信息等。

用戶收貨（客戶端）

此時訂單中的商品已經在運送中，用戶可以進行延長收貨時間、查看物流、確認收貨、申請售後。以天貓的商品待收貨狀態訂單詳情作為例子：

延長收貨時間：前文所說的「系統自動收貨」是保護了商家，延長收貨時間則是為了保障用戶的利益，因為只用當用戶確認收到貨之後，平台才會跟商家結算。這兩個功能互相照應。為了避免由於物流等因素的影響，在用戶真正收到商品前系統自動結束訂單，用戶可以選擇延長收貨。但是需要事先確定好延長收貨的規則，如天貓限制必須在距離訂單自動結束前三天才能申請，並且只能申請一次。

售後服務

當商品發貨後，用戶無法直接取消訂單，如果想申請退貨、退款，只能走售後服務流程，另外生產售後服務單。售後服務具體可以分為僅退款、退貨退款、換貨等。以下是商品售後服務的流程圖：

退款金額：涉及到優惠價格分攤的商品，退款時只退實際分攤的金額（遵循或者其他退款規則）。

商品庫存：售後服務全部結束後，商品庫存才發生變化。

數據統計

訂單的數據統計主要分為兩個維度，一個是統計訂單中的商品，一個是統計訂單的相關數據。商品維度包括訂單中的下單商品數、成交商品數、下單率等，訂單維度包括訂單銷售額、客單價、訂單來源、下單率、下單支付率等。

重點總結

• 不同的業務模式，訂單模塊設計也不同，具體情況需要具體分析；
• 實物商品訂單管理實際是同時記錄訂單和商品的狀態；
• 並不是所有電商訂單系統都需要拆單。

本文由 @Chloe 原創發布於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議