B端平臺產品建設手記-訂單中心篇（上）

導語：訂單中心是很多B端平臺都不可缺少的一個模塊，本文作者結合自己多年的B端產品項目工作經歷，將自身的平臺建設經驗與反思進行總結，希望可以與大家一起分享交流。

訂單中心是多數B端平臺都會涉及的一個模塊，本質上為單據管理，而銷售訂單是單據管理內的一個類目，其分析邏輯可拓展到其他類目，如訂貨單、意向單等。

筆者之所以選擇訂單中心作為第一篇總結，也是由于訂單中心業務實際上牽涉到平臺內多方業務人員參與，如銷售、市場、庫管、財務、物流團隊、商家甚至領導團隊，具有更廣的普適性與討論價值。

從訂單業務層面上，本人將訂單數據流轉過程總結為四個階段，分別是訂單創建階段、訂單支付階段、訂單完成階段和訂單售后階段，這四個階段將串聯起訂單業務的整個生命周期，涵蓋商品中心、營銷中心、庫存中心、財務中心和物流中心五個業務模塊。

一、訂單創建階段：狀態與庫存的處理邏輯

首先是訂單創建階段，從用戶開始進入平臺購物界面開始，訂單業務便開始了。商品展示界面通過商品中心和營銷中心拉取信息，并將信息運算結合后展現到用戶眼前，供用戶挑選。

用戶在選中商品加入購物車后，圖中有一步校驗商品庫存是否充足的邏輯，該邏輯目前在市面上存在多種缺貨處理方式，如京東商城是在用戶進入界面上便提示用戶已缺貨，禁止用戶加入購物車，而淘寶/天貓商城是提示無貨后，依然支持用戶加入購物車，本人則更偏向于后者，因為京東商城在缺貨商品無法加入購物車的情況下，用戶想要保留下次快速找到商品的途徑，大部分都是通過收藏商品來實現。

而實際情況下，大部分用戶對購物車的關注度普遍高于收藏夾，這也就相應減少了缺貨商品后續的曝光頻率。

如果用戶可將缺貨商品加入購物車，那么用戶下次看到商品到貨，即可直接在購物車界面發起購買操作，而不需要像收藏夾一樣，進入商品詳情頁發起購買，這也可以減少操作環節，增加成交幾率。

用戶發起支付后，訂單中心將根據最新的商品信息和營銷信息，計算實際支付價格后生成未支付訂單，有些朋友可能疑惑訂單為何還要區分未支付和已支付兩種狀態，而不是在支付成功后直接創建已支付訂單。

我的理解是這樣的，首先是用戶發起支付動作后，到支付成功存在時間間隔，用戶可能在這個間隔內完成支付，也可能在這個間隔內由于各種原因（卡機、接電話、余額不足等）退出支付界面導致支付失敗。而此時為了讓用戶在支付中斷后可以找到原商品進行支付，則需要保留一條未支付的訂單。

這個時候有的朋友可能又會疑惑，為何用戶不直接重新購買商品呢？

我認為主要原因是優惠，優惠一般來源于平臺、商家或商品的促銷策略，且該策略具備時效性。用戶在挑選商品時可能由于優惠而下單，如果支付失敗，那么用戶下次找到商品支付，則可能面臨促銷失效而支付價格提升的情況，用戶將大概率不再繼續購買該商品，如果支付失敗為平臺責任，甚至會導致用戶對平臺的體驗感直線下降。

另外，在下單到支付的時間間隔中，用戶都有可能面臨促銷策略已失效的情況，若等到支付時再計算優惠生成支付訂單，將可能導致用戶支付金額與下單金額不匹配的情況，最典型的便是用戶晚上12點前下單，12點后支付的場景。

講完未支付訂單，這里將來到訂單創建階段的最后一個業務環節-鎖定庫存。

鎖定庫存的概念是，商品的物理庫存數量不變，但該庫存數量已被鎖定為不可變更移動的狀態。通俗的說就是，這個庫存被預定了，不能賣給別人。他的作用在于防止訂單支付數大于商品庫存數，導致最終無法出貨的情況。

另外，并非所有平臺商家都會加入鎖定庫存的概念，該概念是由于訂單未支付狀態的存在而設計，而部分商家為了避免競爭對手惡意制造大量未支付訂單導致正常買家無貨可買的情況，也會對該鎖定庫存策略進行一些限制，如鎖定庫存比例告警、非強制無貨狀態等。

二、訂單支付階段：訂單的拆分和財務記賬

用戶支付完成訂單后，訂單中心將同步該訂單為已支付狀態。與此同時，若用戶單筆訂單內存在多個商家，且商家之間為獨立運營，那么訂單會做拆分處理，拆分一般為母訂單根據各商家的商品價格與促銷活動，對商品和支付價格進行拆分，此處需要注意的是，拆分過程中可能遇到優惠金額無法直接整除的場景，需要明確好余數應如何處理。

如用戶購買A商家商品共10元，B商家商品共20元，且使用了1元優惠券，那么簡單的按比例劃分優惠額即為A商家優惠1*10/（10+20）=0.333…元，B商家優惠1*20/（10+20）=0.666…元，若直接去尾數，將直接導致0.3333…=0.33，0.666…=0.66，總優惠=0.33+0.66=0.99的情況，與實際優惠不符。

那么四舍五入行不行呢，上面的案例是沒問題的，但若遇到三個商家各10元，優惠1元的場景，就會遇到同樣的問題，最后的優惠額會等于0.33+0.33+0.33=0.99元。因此，在這個時候，一般會引入盈虧池的概念。

盈虧池的概念即為，不論你采用的是直接去尾數、向上下取整還是四舍五入的算法，如果算出來的實際優惠額大于訂單優惠額，那么平臺將承擔該部分損失，記為虧損；如果實際優惠額小于訂單優惠額，那么平臺獲得該部分差價盈利。

總體上，總的盈利和虧損是不大的，只是為了保證實際財務收入與單據保持一致而已。

而在不引入盈虧池的情況下，一般會這么處理，當存在多個商家享受同一個優惠時，系統將計算前兩個商家的優惠額，并將最后的差額作為第三個商家的優惠額，如此便可保證用戶支付金額總和等于總商家收入金額總和。

如上面案例A/B/C三個商家，共同享受1元優惠，那么A/B商家享受的優惠額為0.33，C商家享受的優惠額則為1-0.33-0.33=0.34。

說完拆單，另外一個需要注意的便是財務記賬，一般來講，用戶支付完訂單，財務中心將會增設一筆收入數據，該收入數據一旦確認，便不可再次更改，原因便是為了保證財務數據與流水數據保持絕對一致。

流水數據常見于第三方支付場景，如財付通、支付寶和銀聯等，用戶通過第三方支付，支付完成后第三方服務商將提供與該筆訂單相對應的流水單號，因此流水單號也是財務對賬中，出現差異時可依賴的重要校對手段。

另外，訂單在財務模塊還涉及到另一個分支-手續費，目前大部分第三方支付服務商會收取收款商家一定的手續費用。那么該部分費用在用戶支付完訂單的時候，系統也會同步根據手續費率計算該筆訂單手續費，并登記到支出項。

需要注意的是，手續費需要先明確由平臺方還是商家承擔，若商家承擔，也會遇到按比例平均后，實際總費用高于或低于登記費用的情況，這時候也可以引入盈虧池進行處理。

那么本篇文章主要總結了訂單創建階段和訂單支付階段的流轉過程與相關概念，要點包括：

• 缺貨狀態下的交互處理
• 訂單狀態的定義邏輯
• 鎖定庫存的基本概念與作用
• 訂單的拆分與記賬
• 優惠額拆分的處理方式（盈虧池/按整額取余數）

那么，B端平臺產品建設手記-訂單中心篇（上）就到此結束，下篇將就訂單業務中的完成階段和售后階段進行論述，歡迎大家提出意見與問題，進行更深層次的交流。

 

本文由 @RB產品手記 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議