2017年入職，2019離職，2年社交產(chǎn)品后臺的工作，讓我對后臺產(chǎn)品有了很多思考與總結(jié)；匯總成這3萬字，分上中下三篇發(fā)布，此為下篇。希望能對大家有所幫助。

接中篇。

十五、核心指標

供給側(cè)的核心指標是：

• 新增注冊數(shù)，成功注冊的機構(gòu)數(shù)；
• 新增入庫數(shù)，成功在庫內(nèi)建博主主表數(shù)；
• 博主審核速度：審核時間-提交時間，刨去夜間因素；
• 人均處理數(shù)，總提交審核數(shù)/工作人數(shù)；
• 新增上架數(shù)：分業(yè)務(wù)線、分平臺、分來源看；
• 動銷率：賣出去的SKU/總SKU；
• 被下單博主數(shù)：被下單數(shù)＞0的上架博主數(shù)總和；
• 被支付博主數(shù)：被支付訂單數(shù)＞0的上架博主數(shù)總和；
• 博主數(shù)量維度的周轉(zhuǎn)率：被支付博主數(shù)/總在架博主數(shù)；
• 博主曝光率：有曝光博主數(shù)/無曝光博主數(shù)；
• 有曝光被訪博主率：被訪問UV數(shù)＞0的有曝光博主數(shù)總和；
• 加購率：被加入購物車博主件數(shù)之和/總的有曝光博主數(shù)。

這幾個指標可以獨立交易線，看供給側(cè)的健康度和效率情況了；如果某天遇到異常，再往下拆解詳細看。

十六、數(shù)據(jù)驅(qū)動

說一個小的數(shù)據(jù)驅(qū)動案例，就是主動渠道入庫的分支里的上述的插件功能。

當采購從爆款博主監(jiān)控工具發(fā)掘了目標博主以后，所執(zhí)行的動作是點擊、打開詳情頁、瀏覽、判定可入庫、貼回瀏覽器的URL。

此時我看到了一個數(shù)據(jù)：從點擊到入庫的平均時長，在7分鐘左右——按理說不應(yīng)該有這么長，詳細拆分數(shù)據(jù)，將這些博主的從打開入庫界面到入庫的時長在5分鐘左右；因為我們處理抓取的任務(wù)優(yōu)先級是先保證對外，再保證對內(nèi)，而兩端的操作、交互行為都是一致的，提交入庫后就要等系統(tǒng)的返回通知，否則這個入庫就可能會失敗，所以5分鐘的意思就是內(nèi)部采購在等待機器返回成功結(jié)果通知。

當觀察到了這個數(shù)據(jù)以后做了一個優(yōu)化，就是在入庫頁面新增了批量入庫的功能，也就是按照一個模板上傳URL，等待入庫結(jié)束的通知。

本以為會提效，沒成想又變成降效。

首先這個功能確實抓住了痛點，但是沒考慮到，當所有人都去這么使用的時候，方案錯了：

• 第一個是抓取的并發(fā)處理出現(xiàn)了問題，大量的任務(wù)堆積，導(dǎo)致失敗率異常高；
• 第二是拉長了處理周期；
• 第三是看似減輕了成本，只不過采購?fù)瑢W由原來的貼近入庫界面，變成了攢著貼進excel，路徑是一樣的。

所以這時候又要重新思考這件事：他們要的是快速的從A到B，而不是一匹馬還是一個汽車還是一個火車的問題——如果交通工具沒有了才好。

以此為思路，開發(fā)了基于主要平臺的瀏覽器入庫插件。

在chrome瀏覽器下，安裝插件，登錄自己的工作博主，當打開微信、微博等博主主頁時，只要右鍵點擊入庫，即可完成傳遞的工作；當真正的入庫抓取流程處理完畢，會推送通知提示采購者及時處理工單，這樣系統(tǒng)并發(fā)也不存在了，處理周期真正縮短，操作路徑真正縮短，完成了目標。

所以，最后觀察的結(jié)果是從點擊博主進入博主主頁，到入庫提交的時間從7分鐘降為3分鐘，達成真正的優(yōu)化目的。

十七、第三方服務(wù)管理

我們在運行當中會調(diào)用很多第三方服務(wù)，比如短信通知，第三方支付服務(wù)（微信/支付寶/云閃付），企業(yè)資質(zhì)校驗的企查查，百度的機器視覺，法大大的電子簽章等服務(wù)，釘釘?shù)臋C器語音外呼。所以這對我們的管理和通用化思維提出了比較嚴格的前瞻性要求。

用短信舉例，我們的短信是有3家服務(wù)商，最初的考慮是避免在注冊收驗證碼，或者關(guān)鍵通知提醒的節(jié)點，因為服務(wù)掛了，導(dǎo)致業(yè)務(wù)進行不下去；可后面發(fā)現(xiàn)這塊不簡單，首先每家短信服務(wù)商的價格不一樣，對應(yīng)的就是到達率和及時率的不一樣，貴有貴的道理，便宜也有便宜的道理，這就要求我們能夠接入并合理運用。

像所有服務(wù)商的接入，必須可管理、可透明化運營場景。

以短信為例，我們除去常見的基礎(chǔ)信息以外，還會要求收集服務(wù)商的業(yè)務(wù)性數(shù)據(jù)。

• 基礎(chǔ)信息有供應(yīng)商名稱、服務(wù)年限、企業(yè)資質(zhì)、營業(yè)執(zhí)照、調(diào)用費用、電子合同、接入人、介入時間、聯(lián)系人信息等；
• 業(yè)務(wù)性數(shù)據(jù)像哪個消息ID，發(fā)送多少個信息，消費多少，成功發(fā)出多少，到達多少，及時率多少；

也會有一個綜合性數(shù)據(jù)，供下一個模塊消息配置中心所承接。

像其它的邏輯和套路也像短信類似，不重復(fù)說了。

相比之下，剛剛說的其它服務(wù)可能就沒有像短信這么復(fù)雜了，像企查查、第三方支付等，都是固定的節(jié)點在接入，其它節(jié)點也沒業(yè)務(wù)場景和需求，我們只要監(jiān)控日常的調(diào)用數(shù)據(jù)是否異常，及時報警。

十八、消息配置中心

我們每一個節(jié)點基本上都是有短信通知的，有通知補全信息，不成功有提示再來一回，提交有等待審核，長時間無活躍的促活召回等等之類的；這些都是運營該去想哪些要提示，哪些不要提示。而我們產(chǎn)品對于系統(tǒng)化來講的意義就在于搭建框架，運營可以在里面隨心用，怎樣的需求基本都能支撐的原則。

短信服務(wù)要收集那些關(guān)鍵信息，就是在于每個節(jié)點對于服務(wù)商的需求是不一樣的。比如注冊時的驗證碼，那就要到達率高的，及時率快的；相比之下，召回短信就不用有此依賴，便宜就行，反正90%多的到達率，我一次發(fā)個萬八千的，也能回來不少。所以這就要求我們在設(shè)計消息中心的時候，盡量提供便利性。

便利體現(xiàn)在兩點：第一是在于節(jié)點識別的便利性，第二是在于服務(wù)商識別的便利性。

節(jié)點的意思是如何能讓運營通俗易懂可視化，哪個節(jié)點需要配置，哪個節(jié)點在業(yè)務(wù)中的進程是什么。

我們當前做的是文字狀態(tài)的展示，但是發(fā)現(xiàn)不太好，因為對于新人來講的接手成本還是有點高。比如，提交后等審核短信，什么叫審核成功，什么叫審核失敗，是哪個節(jié)點的審核失??？你可能問我或者問一個資深運營馬上就能告訴你：是在企業(yè)資質(zhì)資料的階段，可新人并不一定知道。所以，接下來要迭代的一個大版本，就是一個可視化的配置界面。

這個需求的本源來源是來自BI，他們正在開發(fā)基于全系統(tǒng)、全流程、全狀態(tài)的可視化圖表，就像我短信節(jié)點這就是很小的一塊了。

從注冊到上架，到被交易，數(shù)據(jù)都發(fā)生了怎樣的狀態(tài)變更，上下級和分支是怎樣，BI都會納入可視化的范圍，去呈現(xiàn)一個報表，供所有相關(guān)人查閱；看前一天的業(yè)務(wù)情況，卡在哪里，轉(zhuǎn)化率銳減，或者哪里轉(zhuǎn)化率不理想，可以提升，洞察問題，診斷問題很方便。

原始需求再那邊，我這邊只負責梳理狀態(tài)和對應(yīng)的狀態(tài)路徑之類的。

在當前現(xiàn)狀下，輔助運營能相對方便的識別出哪些節(jié)點，可以配置短信，也可以配置靈活的短信策略。比如，最簡單的注冊，那就是當觸發(fā)狀態(tài)，立即發(fā)送；最復(fù)雜的就是在召回規(guī)則里，比如會有某些等級的資源，當非活躍持續(xù)7天后，下周1、3、7持續(xù)短信召回，精細化甚至可以達到某些類別、某些量級、某些單位區(qū)間內(nèi)交易數(shù)量的博主——因為運營很可能會這么寫短信：

各位母嬰博主，平臺最新發(fā)布本月母嬰博主榜單，請及時查收。

也有一些錯誤配置的功能，比如注冊，一般就會開啟“當短信發(fā)送失敗，立即重新發(fā)送”，而召回可能就不用。也會有服務(wù)商優(yōu)先級的配置，剛剛說了，可能最好的是A，優(yōu)先A，但是也可以把B，C列為第二、第三優(yōu)先級。

所以這個消息配置中心是一個大支撐模塊，所有節(jié)點都可以用。

短時間內(nèi)開發(fā)成本確實很高，但是后續(xù)來看，是減輕長期開發(fā)成本了。

十九、訂單中臺

接下來是我負責的另一個比較重要的中臺服務(wù)，就是訂單中臺；是屬于OMS中的底層，偏抽象的，各端的都有各自的訂單管理界面，進行獨立的展示和管理。

訂單中臺這個事情做起來要比采購端容易太多了，因為他是具象目標，收斂的，很明確的目標，就是根據(jù)之前訂單去抽象支撐未來業(yè)務(wù)發(fā)展的訂單小中臺。業(yè)務(wù)剛剛說過了，沒有庫存，也沒有優(yōu)惠營銷，所以偏向虛擬服務(wù)訂單類型，但是相比之下還會稍更簡單一些。但是架不住業(yè)務(wù)本身復(fù)雜，還要兼容各種情況的出現(xiàn)。

公司決定整體重構(gòu)以后，劃分了非常多的系統(tǒng)，借此我們也重新梳理了訂單流程（也就是訂單被創(chuàng)建的標準流程），除去狀態(tài)機有中臺公用的狀態(tài)機以外，系統(tǒng)流程也是，避免各自為政、管理混亂、統(tǒng)計混亂、重復(fù)開發(fā)、成本加大的問題。

1. 名詞

我先介紹下名詞：一個是非標原創(chuàng)，一個是標準通稿，這是由博主的內(nèi)容質(zhì)量分所決定的。

非標原創(chuàng)的意思是客戶帶著需求方向來，需要博主進行自定義的完全創(chuàng)作。比如客戶就要做一個面膜的推廣，品牌是歐萊雅，時間是雙十一，面膜特色是補水、保濕和貴——那可能不同的博主創(chuàng)作出來的內(nèi)容風格和最終交付的內(nèi)容都不一樣，我們把這類定義為非標原創(chuàng)。

標準通稿就是反過來的——因為業(yè)務(wù)非標，導(dǎo)致商品非標。

公司為了改善這個問題，在2017年的時候新增了一條標準化業(yè)務(wù)線，客戶帶著已經(jīng)創(chuàng)作好的內(nèi)容，你幫我發(fā)就可以了，不用管內(nèi)容哪里來的，客戶就是要刷屏效應(yīng)，博主完全不需要二次創(chuàng)作，這叫通稿。

非標業(yè)務(wù)線與標準業(yè)務(wù)線的主要差異在于客戶權(quán)益：

• 非標業(yè)務(wù)線有些會出現(xiàn)差旅、版權(quán)授權(quán)、代言或競品協(xié)議等其它特殊附加費，都是各不相同；
• 標準業(yè)務(wù)線就很標準——博主多少錢就是多少錢，下單、支付、發(fā)布、驗收就可以了。

鑒于非標業(yè)務(wù)線的特性，也造就這兩條業(yè)務(wù)線在業(yè)務(wù)中的最大差異：非標業(yè)務(wù)線會在下單流程中增收保證金，因為溝通和后續(xù)成本太高了；另一條就不用了，非標品轉(zhuǎn)化為標品，相對確定性。

對于保證金，在下單的時候會經(jīng)歷業(yè)務(wù)屬性很強的價格預(yù)估模型，從而根據(jù)此計算保證金，客戶有償下單。而獲取最終確定性的訂單價格以后，也就是博主的反饋后，會生成子訂單——所以第一條父訂單是保證金層面，第二條子訂單是尾款層面，兩筆訂單結(jié)合構(gòu)成完整訂單。

對于業(yè)務(wù)線的大劃分，有微博/微信/抖音/快手/小紅書/B站這幾個平臺，從最上層進行抽象其實就是兩類：文本和視頻。

文本的非標下單流程和視頻的非標下單流程，哪怕都是非標業(yè)務(wù)，業(yè)務(wù)節(jié)點也有不一樣。比如文本可能會有brief確認、大綱確認、圖片素材拍攝確認、軟文確認等流程。而視頻會更為復(fù)雜——會有brief確認、鏡頭確認、腳本確認、視頻確認、發(fā)布詳情確認等環(huán)節(jié)。

每條業(yè)務(wù)線會組合有標品和非標品，所以大體上就是4種最核心的抽象。

當前平臺和業(yè)務(wù)線的劃分情況劃分的情況，是微信有非標原創(chuàng)、標準通稿，微博只有標準通稿，但是會分為直接發(fā)布和轉(zhuǎn)發(fā)，只是交互上不一樣，訂單結(jié)構(gòu)完全相同。抖音/快手/B站，只有非標原創(chuàng)，你做大批量標準通稿，視頻平臺算法就封殺你了。

這是介紹訂單之前的前期概念認知。

2. 下單流程

當客戶準備下單的時候，經(jīng)歷的標準流程是非常長的，這里詳細介紹下：

當客戶進入博主詳情頁，先去調(diào)用我的商品中心，獲取商品的所有信息和屬性；而后會調(diào)用客戶中心存儲的本客戶的客戶畫像；接著就會在估價模型基礎(chǔ)上，結(jié)合客戶畫像的價格模型，輸出估價，這樣對客戶下單前的博主信息標品化工作結(jié)束，等待客戶觸發(fā)下單的按鈕。

當客戶點擊下單，首先經(jīng)過風控中心，檢查客戶的下單行為是否正常（交互行為和端的行為，如果發(fā)生異常，就會下單攔截報錯），沒有問題的話將會進入下一個環(huán)節(jié)。

此時訂單將會被創(chuàng)建，其中訂單上的價格為根據(jù)客戶選用的SKU上（某些業(yè)務(wù)線需要交保證金，保證金為估價模型估算的價格，按照一定比例收取的保證金），此時是父訂單，這類業(yè)務(wù)線的訂單會在后續(xù)生成一條子訂單，也就是尾款訂單；客戶此時需要支付尾款，否則訂單不會被觸發(fā)后續(xù)流程。

子訂單支付完畢后，父子訂單會合并，狀態(tài)會統(tǒng)一（非保證金業(yè)務(wù)線，就不會生成子訂單了，單一狀態(tài)線性向下）。

博主回復(fù)價格后，繼續(xù)經(jīng)過價格模型，根據(jù)客戶畫像和供需模型生成溢價；在客戶看到價格并支付后，支付中心會回傳支付信息和支付狀態(tài)，當支付已經(jīng)完成，會調(diào)用訂單中心進行訂單狀態(tài)的更新，變?yōu)橐阎Ц兜臓顟B(tài)，并訂單下推。

此時訂單會推送至執(zhí)行中心（簡單來說就是訂單將被內(nèi)部接手，開始與博主端勾兌需求、制作、協(xié)調(diào)修改的持續(xù)過程）；當博主可以做需求，回復(fù)訂單價格后，會生成子訂單，同時系統(tǒng)會生成電子合同，供銷售端客戶和博主雙向確認，一個是服務(wù)合同，一個是采購合同，客戶必須在合同確認后，才能再支付尾款，補齊差價，此時服務(wù)合同建立完成（客戶對公司），同時調(diào)用支付中心支付成功，采購合同推送至博主端（公司對博主），此時訂單才算建立，商業(yè)契約達成。

推送采購合同必須客戶確認服務(wù)合同和支付尾款，若客戶只確認合同，則不會告知博主完成采購合同簽署，有毀約風險。所以客戶端如果確認合同不支付尾款，則可判定客戶毀約，按照協(xié)議中一定比例違約金（一般就是保證金的100%）進行賠付。

當客戶支付后，實際對應(yīng)博主的偽庫存已經(jīng)減少（也就是：博主在從下單到最終發(fā)布的這個時間區(qū)間內(nèi)，其它客戶雖然可以接，但是時間盡量不允許與之交叉——本著對客戶負責的態(tài)度，所以這就是剛剛介紹的偽庫存減庫存的概念）。

訂單詳情都詳細記錄了預(yù)計什么時候發(fā)布，這時候會通知到庫存模型：當客戶訪問頁面，調(diào)用報價模型的時候，報價里面庫存模型的這個模塊的作用就發(fā)揮出來了——首先加溢價，我們盡量攔截，如果執(zhí)意下單我們也樂得賺錢，同時頁面去提示客戶換個檔期，可能就好了（頁面這時候也會出現(xiàn)同等博主的協(xié)同推薦，引導(dǎo)客戶去換個博主）。

總之要周知：這個博主這段時間可能沒有檔期了，就要提示這個時候下單是有高風險的；可能博主會不接單，可能價格會很貴，可能出來的內(nèi)容會不滿意，客戶謹慎下單，起到前置提示的作用。

再之后就是相對常規(guī)的溝通、修改，訂單不會再動了；當完成內(nèi)容發(fā)布后，客戶可以進行操作確認（相當于確認收貨）。

在博主提交完成的同時，我們會觸發(fā)機器質(zhì)檢，生成數(shù)據(jù)趨勢圖，用于輔助客戶判斷傳播真假；客戶可以在這個區(qū)間內(nèi)任意時間進行確認，目前是7天；而后就是評價，評價后訂單才會真正完結(jié)。

評價是商品中心必不可少的，既可以用于其他客戶決策參考，還可以供我們更新對博主的評估模型以及推薦模型。

質(zhì)檢主要就是根據(jù)訂單中的關(guān)鍵信息，比如哪個博主，什么時候發(fā)布，標題是什么，這時候機器就會機器介入服務(wù)，在發(fā)布時間區(qū)間范圍啟動抓取服務(wù)，進行內(nèi)容發(fā)布的識別。

產(chǎn)出主要有2個，一是供客戶通知用，當識別到發(fā)布，就會告知客戶之前的訂單發(fā)布了，可以來看看效果了；二是識別數(shù)據(jù)，進行數(shù)據(jù)匯總呈現(xiàn)報表。

這里我們和線下服務(wù)的業(yè)務(wù)還不一樣：線下業(yè)務(wù)的確認收貨節(jié)點是到店核銷，但是我們大多數(shù)沒有明確的確認節(jié)點。

對于非標的創(chuàng)意來講，每個人的理解可能都是不一樣的——你可能滿意，他可能就不滿意，所以這個節(jié)點目前必須客戶手動進行操作，才算結(jié)束。

若客戶沒有點擊確認，點擊投訴（相當于電商中的退貨申請），此時訂單狀態(tài)變?yōu)樘幚碇?，客戶中心將會接手，會進行對客戶、對博主的雙向協(xié)商，直到達成一致；在線上錄入?yún)f(xié)商結(jié)果后，無論是按比例退款還是賠償，都只可以在客服中心修改一次；客戶通過后，訂單同樣記錄完結(jié)，若發(fā)生退款，訂單中心會先生成沖紅訂單，將訂單退款額抵消，同時訂單狀態(tài)變?yōu)椴糠忠淹丝?，實際等同完結(jié)，進入評價環(huán)節(jié)。

3. 商品評價

在交易完成后雙方必須對雙方進行雙向評價，目前包含內(nèi)容評分（客戶端）、客戶評分（博主端）、服務(wù)態(tài)度評分、平臺易用性評分，三大維度，均可以打星或自主評價。

內(nèi)容評分是對博主最重要的，客戶的評價好壞會直接影響博主的等級修正和價格修正，當星級變?yōu)?星或以下時，自主評價為必須填寫，每條評價內(nèi)容人工均會審核，審核通過后會展示在博主詳情頁供下一個客戶參考，同時根據(jù)此評價整理反饋單，直接提交至模型中，進行學習和修正。

至此，整個交易流程結(jié)束。

我們的整體下單流程非常長，也非常復(fù)雜。

4. 保證金

對于保證金制度，主要有2種：按照次付和預(yù)存（相當于押金）。

• 次付就是上述根據(jù)每筆訂單按比例計算出來所需要交付的保證金。這個相對麻煩，要和客戶進行協(xié)商，只有這筆錢變?yōu)橄M金額以后才會開具發(fā)票，也就是最終變?yōu)榻Y(jié)算狀態(tài)。
• 預(yù)存押金制度相對流程友善，對客戶決策成本有較高考驗；比如押10萬，那么每次下單的時候都會檢查保證金是否為正，如果發(fā)生訂單在預(yù)付階段的取消，就要判責后從10萬保證金予以扣減，并給客戶開具對應(yīng)的收款發(fā)票。

5. 訂單元素

接下來說一下我們訂單上的必要元素，包含交易時間，其中下單時間、支付時間、確認時間、評價時間，財務(wù)上的結(jié)算時間、打款時間等，會單獨一套財務(wù)，打款單里有。投訴時間也是在客服中心的，中臺訂單中心是沒有的；交易雙方信息，甲方名稱、乙方名稱；訂單基礎(chǔ)信息，父訂單ID、子訂單ID、訂單ID、訂單狀態(tài)、訂單類型；商品信息，商品名稱、SKU信息、規(guī)格、商品快照、價格。

價格有2個：第一個是模型的預(yù)測價格；第二個是此訂單的實際金額，支付信息，支付方式、支付單號、總金額、實付款金額、券抵扣金額、信用賬戶抵扣金額、總抵扣金額、備注，備注。主要是供API、SaaS形式的下單用的，意為在內(nèi)部走完財務(wù)OA之后，讀取審批通過的那個人信息，也就是支付人。

最后，是其它信息——發(fā)票狀態(tài)、下單平臺、銷售經(jīng)理、執(zhí)行者、博主運營、下單者。整體構(gòu)成了我們訂單的全部信息，最重要的是訂單狀態(tài)，其它的在供給端講解的時候基本都說到了，不重復(fù)了。

6. 訂單邏輯

介紹一下訂單上的一些通用邏輯，這個是不能變的。

比如：

• 當客戶下單后，生成下單時間，客戶支付后，生成支付時間；
• 下單時甲方驗證過的企業(yè)名字就是公司與甲方簽署服務(wù)協(xié)議的甲方公司，下單時選中的博主驗證過的機構(gòu)名字，就是公司與乙方簽署采購協(xié)議中的乙方；
• 訂單編號自增生成，狀態(tài)就是當時的訂單狀態(tài)；
• 商品信息隨下單時選擇的寫入，快照是必須的，避免后續(xù)糾紛；
• 當時的非銷售屬性條款最為重要，價格會有兩個：預(yù)估價和預(yù)付款，子訂單對應(yīng)的就是博主反饋后生成的預(yù)估價和尾款。

支付信息一般從支付中心調(diào)取信息直接使用，其它信息中的發(fā)票狀態(tài)隨最終訂單結(jié)算后，財務(wù)會根據(jù)結(jié)算狀態(tài)的訂單按順序開具收款發(fā)票快遞至客戶端，平臺一般有內(nèi)部平臺和外部平臺的自助、SaaS、API和代理商，以及客戶的銷售經(jīng)理、這筆訂單的執(zhí)行客服、博主的入庫審核的運營人。

最后的下單者即當時登錄博主的下單者，用于后續(xù)的追責。

除支付狀態(tài)和除下單的時間外，所有信息必須在生成訂單的一刻全部完整，否則訂單將創(chuàng)建失??；

訂單執(zhí)行的必要條件為是上述所有訂單信息全部完整，否則訂單將會執(zhí)行失敗。

需要交保證金業(yè)務(wù)線的訂單，不支持多個訂單一起下——因為保證金和尾款實際是父子訂單連在一起，如果也支持多個訂單一起下，相當于父子孫訂單，實在不劃算。

• 所以：需要交保證金的業(yè)務(wù)線，會稍復(fù)雜些：當預(yù)付款支付完畢后，博主響應(yīng)后，隨即生成子訂單，子訂單狀態(tài)是初始狀態(tài)待支付，用于后續(xù)流程；
• 非保證金業(yè)務(wù)線即可多個博主一起下單，父子兩層完全結(jié)構(gòu)復(fù)用。

7. 訂單運營規(guī)則

像一般的訂單運營的規(guī)則就不多說了，比如下單后多久不支付自動取消，我們目前是12天——因為2B平臺的因素，會遇到提前下單鎖檔的客戶，是正常的需求；什么節(jié)點可以取消訂單，目前是隨時可取消；但運營根據(jù)配置的賠償規(guī)則，有一定的有損取消條件，一般情況下在已經(jīng)執(zhí)行后，就不可以全額取消了，客服審核不會通過的，只可以協(xié)調(diào)部分退款。

還有就像執(zhí)行后多久自動確認，目前是7天；投訴目前每個訂單只能有1次，剛剛也說過原因了；確認后多久自動評價，目前也是7天，評價不可為空，如果客戶不填寫，所在的訂單執(zhí)行是要負責補上的；以及財務(wù)接手的，訂單被評價的完結(jié)后，博主什么時候可以提現(xiàn)，目前是隨時可體現(xiàn)，但要支付一定的提現(xiàn)手續(xù)費，原因是我們要盡可能的讓錢趴在平臺上時間久一點，產(chǎn)生相對穩(wěn)定的資金池沉淀，錢生錢。業(yè)務(wù)線不同，免費提現(xiàn)的時間也不同，一般是30-60天不等。

8. 狀態(tài)機

下面說下重點的訂單狀態(tài)機：

我們的目標是抽象小中臺，供以后交易線復(fù)用快速實現(xiàn)，并且能夠統(tǒng)籌管理，對于報表層面也是友好的，所以我們開始做的一件事就是分析訂單的歷史數(shù)據(jù)。

按照業(yè)務(wù)線，無論是微博、微信，還是抖音、快手，首先分成兩大類訂單類型：文本交易和視頻交易，而文本交易又劃分為非標原創(chuàng)交易、標準化通稿交易——這就意味著至少有3大組業(yè)務(wù)線。

文本非標原創(chuàng)不同于標準化，其中需要有大綱往復(fù)確認，內(nèi)容發(fā)布前的最終確認過程；標準化的通稿就沒有，因為本身就是廣告主帶著來的，所以這是一組特征；再看視頻原創(chuàng)交易，與文本原創(chuàng)交易相近的是把大綱改成了腳本，拍攝內(nèi)容，最后還多了一步是發(fā)布詳情，也就是發(fā)布的細則最終確定。

這些基本都是屬于不同業(yè)務(wù)線，屬于自己的狀態(tài)機。

那么這時候就可以按照電商大體的框架去搭建真正的小中臺訂單中心了：

根據(jù)分析歷史訂單結(jié)果去找交集點，發(fā)現(xiàn)和電商非常像。先訂立起止狀態(tài)，訂單起狀態(tài)即創(chuàng)建訂單，狀態(tài)為待支付，訂單止狀態(tài)正常結(jié)束為評價結(jié)束后的已完結(jié)，異常結(jié)束為已取消或部分退款已完成。中間取各業(yè)務(wù)線之間弱耦合的通用狀態(tài)連接，小中臺訂單核心狀態(tài)機大體分為待支付、已支付、待確認、待評價和完結(jié)，以及逆向流程的處理中、部分已退款、已取消狀態(tài)。對應(yīng)的現(xiàn)金流狀態(tài)為支付后的凍結(jié)，產(chǎn)生凍結(jié)流水。當訂單完結(jié)狀態(tài)時，現(xiàn)金從凍結(jié)變?yōu)橄M，并生成消費流水——這是兩條最大的脈絡(luò)。

逐一業(yè)務(wù)線去實現(xiàn)。

先看微信原創(chuàng)訂單：

微信訂單狀態(tài)機一般會分為待支付保證金、已支付保證金、待響應(yīng)需求、待支付尾款（子訂單待支付）、已支付尾款（子訂單支付）、（訂單合并）、大綱確認（次數(shù)會掛在每個訂單的合同中）、內(nèi)容確認（次數(shù)同上）、待執(zhí)行、待確認、待評價、完結(jié)。

對應(yīng)的交互狀態(tài)也就是下單之后的待支付保證金狀態(tài)，客戶進行支付保證金，狀態(tài)變?yōu)橐阎Ц侗ＷC金，博主收到需求，回復(fù)需求的確定性價格，客戶收到待支付尾款，客戶支付尾款，博主開始創(chuàng)作，大綱創(chuàng)作完畢等客戶確認，客戶確認后進行內(nèi)容創(chuàng)作，內(nèi)容創(chuàng)作完畢后等待按照訂單上的約定時間發(fā)布，博主發(fā)布后等待客戶進行確認，客戶確認后客戶評價，評價完成后訂單完結(jié)，推送至財務(wù)準備結(jié)算。

所以可以在小中臺訂單中心去實現(xiàn)：

在中臺訂單中創(chuàng)建訂單，待支付狀態(tài)，支付完畢保證金后，訂單狀態(tài)凍結(jié)，博主響應(yīng)填寫報價后，會在此訂單基礎(chǔ)下生成子訂單，當客戶支付完畢尾款時，調(diào)用中臺訂單中心訂單狀態(tài)變?yōu)橐阎Ц?，并且父子訂單狀態(tài)合并，進入溝通和創(chuàng)作環(huán)節(jié)。

期間內(nèi)的所有狀態(tài)變更都是業(yè)務(wù)線自己的行為，當博主發(fā)布內(nèi)容后，調(diào)用中臺訂單中心變?yōu)榇_認；當客戶確認后，調(diào)用中臺訂單中心變?yōu)榇u價狀態(tài)，當評價完畢后調(diào)用訂單中心變?yōu)橐淹杲Y(jié)狀態(tài)。

微信通稿訂單同樣的邏輯，但是支付環(huán)節(jié)就沒有保證金一說了，跟業(yè)務(wù)線需求和邏輯走，支付后就直接已支付，支付完成后就直接等待發(fā)布就可以。

因為是通稿，客戶帶著文案來的，你幫忙發(fā)就行；所以博主在規(guī)定時間執(zhí)行完畢，質(zhì)檢接入，機器判定執(zhí)行狀態(tài)后，自動幫客戶進行確認，直接變成待評價狀態(tài)，評價完畢后訂單完結(jié)。

除中臺訂單中心以外的狀態(tài)和調(diào)用邏輯、規(guī)則，均可以按照自己的業(yè)務(wù)線自定義，但是訂單中的必要節(jié)點必須要調(diào)用中臺訂單系統(tǒng)，否則訂單就是卡住的狀態(tài)。

微博訂單、視頻訂單基本同理，就不再多介紹了。

說一類特殊的訂單類型——預(yù)充值的CPC業(yè)務(wù)線：

• 客戶會先輸入預(yù)算，提交后，中臺訂單會根據(jù)客戶自己輸入的預(yù)算，建立充值訂單，狀態(tài)為待支付；
• 客戶進行支付后，狀態(tài)變更為已支付，扣費模型會接到客戶創(chuàng)建的需求明細，進行按照click的扣費計算，直至消耗光，訂單自動變?yōu)榇_認和完結(jié)；
• 或者客戶在投放過程中發(fā)現(xiàn)異常，主動進行停止，停止后訂單變?yōu)榻Y(jié)算狀態(tài)，同時生成沖紅訂單退回未消耗的錢款至客戶的充值來源。

再來說一下父子訂單：

和一般電商一樣，我們也是有購物車的，內(nèi)部叫選號車。當從購物車選中多件博主時，并下單進行支付，這次整體的購買行為記錄在父訂單下，針對父訂單進行結(jié)算，其實就是將多個訂單合并的過程；當提交訂單后，系統(tǒng)再更新訂單。

在投訴狀態(tài)、財務(wù)狀態(tài)的時候，針對子訂單，也就是當下多個訂單被合并為一個父訂單后，業(yè)務(wù)上的確認和評價動作是針對父訂單的，每個子訂單是不會再有了。如果子訂單發(fā)生異議，可以在14天內(nèi)（自動確認的T+7，自動評價的T+7）進行投訴，和父訂狀態(tài)單獨不互相干擾——這也就是為什么保證金業(yè)務(wù)線，就不能再多個訂單一起下了，保證金+尾款本身就是父子訂單了，再技術(shù)多做一層不劃算，不如在業(yè)務(wù)端進行攔截。

9. 合單

合并訂單的邏輯是：

• 下單時間就是子訂單合并創(chuàng)建父訂單的時刻，支付時間是支付父訂單的時刻，并會覆蓋至子訂單上；
• 父訂單的確認時間：若子訂單發(fā)生投訴，父訂單還未確認的時候，則子訂單沒有確認時間，當客服處理完畢后的時刻就是子訂單的確認時間；父訂單已確認，則確認時間就是父訂單確認的時刻，處理完畢的時刻也不會進行覆蓋，評價時間也是評價提交的時間，并會覆蓋至子訂單上。
• 交易雙方信息甲方信息就是客戶名稱，主體一致，乙方名稱為所有商品名稱的標題聚合，最多255字；
• 訂單狀態(tài)取所有子訂單狀態(tài)中最慢的狀態(tài)，一般就到待確認，客戶在所有內(nèi)容都滿意以后才會進行確認；
• 同步所有子訂單的SKUID和規(guī)格ID，商品快照可以為空；
• 價格取實際金額的total，預(yù)測金額會以子訂單為維度進行內(nèi)部分析，不會放在父訂單上；
• 支付信息取自支付中心；
• 發(fā)票狀態(tài)會取子訂單中最慢的狀態(tài)，一般發(fā)票狀態(tài)就分為待開票、已開票、郵寄中、已關(guān)聯(lián)——也就是當全部子訂單都變?yōu)橐殃P(guān)聯(lián)，父訂單才變?yōu)橐殃P(guān)聯(lián)，否則就以最慢的狀態(tài)為準；
• 下單平臺、下單者，取任意自子訂單，應(yīng)該每個子訂單都是完全一致。

10. 拆單

有合并訂單，必定會有拆單的維度和邏輯。

拆分訂單的維度主要分為供應(yīng)商（店鋪）、平臺。同一個父訂單會包含多個博主子訂單，可能博主從屬于的供應(yīng)商都是不一樣的，這從業(yè)務(wù)上就必須要拆開。

同一個機構(gòu)的訂單放在一起，主要服務(wù)于后續(xù)的結(jié)算和打款，基本是在父訂單完結(jié)后才會觸發(fā)這個邏輯的拆單；平臺的維度主要服務(wù)于執(zhí)行中心，因為不同平臺的執(zhí)行流程、執(zhí)行組的跟進都是不同的，所以也要進行拆單后推送至執(zhí)行中心。

——這里是支付后立即就要拆，并且要返回前端用于展示；我們也不會像電商不同品類之間要拆，不同貨倉要拆，分箱拆單之類的復(fù)雜，虛擬業(yè)務(wù)相對來講簡單一些。

最初我們還想把業(yè)務(wù)線變?yōu)椴饐蔚木S度，但是通過運營規(guī)則的約束成功把拆單的問題避免了，前端不讓跨業(yè)務(wù)下單。

拆單的邏輯是：在下單后立即觸發(fā)按照平臺維度的拆單，將子訂單中統(tǒng)一平臺的訂單進行拆出，并進行合并生成新的按平臺的父訂單。

“拆合并”的邏輯和上述“合并拆”的邏輯反過來就可以，所有父訂單的字段信息都可以從子訂單取到，拆單后會推送至執(zhí)行中心進行按照父訂單分配的邏輯進行執(zhí)行；后續(xù)的供應(yīng)商維度的拆單合并，推送至財務(wù)中心基本是一致的。

最原始的父訂單和新父訂單會有關(guān)聯(lián)字段進行連接。

11. 投訴

投訴也就是退貨的邏輯，要比電商容易一些，因為我們是非標業(yè)務(wù)，又是虛擬業(yè)務(wù)，沒有實體物品的交付，也就無法口徑、概念認知完全一致，也就必定會有人工的溝通在里面。所以這也就是剛剛說為什么新做了一條業(yè)務(wù)線是CPC，我們就可以三方口徑一致，大家都按真實閱讀扣費、計費，數(shù)據(jù)橫在這就可以減少很多人工了。

所以我們的退貨，都是要經(jīng)過客服中心去人工調(diào)解，在平臺最終進行判罰。也沒有像電商系統(tǒng)需要攔截出庫，暫停發(fā)貨的復(fù)雜流程；更沒有想退貨，上門取件，回倉等復(fù)雜流程；我們只有退錢，所以是相對簡單的。

剛剛介紹過，先要經(jīng)過風控，去判斷是否惡意，后客服中心生成工單，進行執(zhí)行、客戶、博主的三方溝通，調(diào)解，調(diào)解完畢后輸入退款數(shù)額或者比例，客戶端確認即可完成整體的投訴退貨的流程。

12. 財務(wù)

我們的業(yè)務(wù)所有都是預(yù)付，但是對大客戶不得不開放賬期，所以我們的賬戶分為3個：現(xiàn)金賬戶、信用賬戶和返券賬戶。

一般情況下，客戶只會用到現(xiàn)金和返券，也就是充多少就會進入到先進里面，下單、支付、凍結(jié)的所有過程都是在現(xiàn)金賬戶里。對于大客會有信用賬戶去支持賬期的需求，也就是錢沒過來，但是可以先透支下單；最后結(jié)算后報備，客戶就可以充值進現(xiàn)金賬戶從而平賬信用賬戶。

當訂單被支付后，其實訂單就已經(jīng)進入財務(wù)環(huán)節(jié)了（也就是我們作為收款者需要開具收款發(fā)票，供對方查賬用）。會分為2張票：訂單實際金額和服務(wù)費票，兩張加一起為真正的實收。

當訂單完結(jié)后，這筆錢就會進入到博主的可用余額賬戶了。

我們的打款結(jié)算是被動進行的，也就是博主進行申請才會進入后續(xù)。當博主申請后，需要先輸入要提現(xiàn)多少，并確定收款主體等信息，等待郵寄或上傳電子發(fā)票，輸入快遞號；當系統(tǒng)識別發(fā)票已收到后，財務(wù)會第二次介入，收到訂單進行處理，主要是審核發(fā)票與打款主體和訂單信息，是否滿足打款條件；審核通過后會生成打款申請單，多個不同銀行的不同模板進行配置，主要就是打多少錢和對方的收款信息以及票據(jù)，供銀行對公打款使用，將表格直接導(dǎo)入至銀行系統(tǒng)中，完成對公打款流程，整體交易流程就結(jié)束了。

13. 私有化

對于大客，我們還兼容了API形式的接入和SaaS形式的私有化部署，主要體現(xiàn)在流程上有些許不同：

當客戶在自家系統(tǒng)輸入完畢需求后，傳入內(nèi)部的撮合模型，進行結(jié)果集信息的返回，客戶點擊博主詳情后，請求商品中心與價格模型、庫存模型返回詳情頁面數(shù)據(jù)，客戶點擊下單后，通知財務(wù)檢查保證金金額和剩余可用押金（大客一般都是壓一筆）情況，系統(tǒng)判斷可扣減余額后父訂單變?yōu)橹Ц稜顟B(tài)，訂單激活，內(nèi)部執(zhí)行開始介入。

當博主返回確定性價格后，會生成子訂單，并建立相關(guān)合同信息，返回客戶采購平臺，客戶在內(nèi)部決策后，通過或拒絕合同；若通過合同，回傳我司后進入財務(wù)，財務(wù)立即請求客戶OA系統(tǒng)并建立采購單，建立者即為通過合同人員信息，審批采購合同的財務(wù)為固定按規(guī)則分組的法務(wù)；法務(wù)審批通過后，合同回傳至我司財務(wù)，進行服務(wù)合同部分的留存，同時會再次調(diào)用客戶OA下行審批流，將留存的合同文件以附件形式創(chuàng)建，下行審批角色為固定規(guī)則分配的客戶財務(wù)，財務(wù)通過后，支付狀態(tài)返回公司支付中心，后通過支付中心通知訂單中心，刷新訂單狀態(tài)，變?yōu)橐阎Ц叮唵伪患せ睢?/p>

另外，在客戶完成支付后，建立對博主的采購合同，并發(fā)送至博主的郵箱；從而完整建立雙方的服務(wù)、采購合同約束過程，最終完成無縫接入大客戶的內(nèi)部審批流程。

整體流程是一致的，但是實現(xiàn)會更為復(fù)雜，參與的人和系統(tǒng)也會更多一些。

二十、項目結(jié)果

目前重構(gòu)完成后，技術(shù)部提供的量化數(shù)據(jù)中，在中臺訂單上線后，可降低每次新業(yè)務(wù)線訂單開發(fā)約30人/天工作量，主要取決于必要節(jié)點的開發(fā)、接入無需再重復(fù)開發(fā)，主要體現(xiàn)在和財務(wù)、供給、銷售側(cè)的對接上。

1. 核心指標

一般情況下，訂單這里最關(guān)注的數(shù)據(jù)：

• 統(tǒng)計周期內(nèi)的GMV（統(tǒng)計周期可以是日、周、月或自定義）；
• 客單價：統(tǒng)計周期內(nèi)，已支付的訂單平均金額；
• 訂單量：統(tǒng)計周期內(nèi)的訂單量；
• 加購數(shù)：統(tǒng)計周期內(nèi)加入選號車的博主數(shù)；
• 下單客戶數(shù)和支付客戶數(shù)：統(tǒng)計時間內(nèi)，客戶數(shù)去重取唯一；

每個訂單的產(chǎn)生?；鶊D，包括在訂單創(chuàng)建之前的商品瀏覽、加入購物車、提交購物車等關(guān)鍵步驟的轉(zhuǎn)化率。

2. 小優(yōu)化

非常早的時候做過一個優(yōu)化，雖然不大，但是至今非常深刻。

我因為是對公業(yè)務(wù)，導(dǎo)致大部分是充值、記賬，實際是對公業(yè)務(wù)打款。那就有一個問題：錄入充值信息的時候，總會出錯（這個出錯的直接后果就是充錯錢，充別人賬上去了）；雖然頻率不會很高，但是每一次發(fā)生后的處理都是財務(wù)開發(fā)修改數(shù)據(jù)庫，手動將充錯的削掉，加到正確的客戶賬上。資源消耗非常嚴重，而且也是可避免的。

當時就思考如何解決。

我司系統(tǒng)和銀行系統(tǒng)做對接是不現(xiàn)實的，銀行不可能允許。但是銀行的充值流水數(shù)據(jù)是可以接入的，他們可以吐數(shù)據(jù)，我們就想中間缺的就是一個連起來的標記。

當時做的方案是：將每個客戶的打款信息欄，增加一個唯一標記，要求客戶在窗口申請對公打款的時候，務(wù)必將標記填寫至備注列；標記是我們生成的，客戶寫在備注列，打款單備注列也會帶上，我們根據(jù)銀行的數(shù)據(jù)和我們庫內(nèi)的唯一標記對比，就知道哪個客戶充值進來多少錢，直接讀取在平臺上生成充值流水。

這樣的好處是：流程再也沒有人的參與，人工的失誤被避免了。

自此以后，充值錯誤的發(fā)生數(shù)為0，節(jié)省了人工。

還有一個是數(shù)據(jù)驅(qū)動的優(yōu)化，是在之前我架設(shè)新的交易線的時候，發(fā)現(xiàn)一個令我不解的數(shù)據(jù)，就是在博主執(zhí)行以后，需要把執(zhí)行的地址貼回來，系統(tǒng)會參與質(zhì)檢，客戶端也能看到。但是有個數(shù)據(jù)異?！N鏈接的操作人，80%以上都是內(nèi)部的執(zhí)行人員，發(fā)現(xiàn)許多博主很忙，就可能忘記再回來填寫；而執(zhí)行組認為博主不填寫，那么這個工作就是他應(yīng)該做的，也沒人反饋，所以他們就默默做了。

雖然是很小的一個節(jié)點，但是還是能提升效率，畢竟是必要節(jié)點。

我就想到入庫時候的抓取服務(wù)：首先我們知道博主的唯一監(jiān)控ID，意味著這個人我想什么時候監(jiān)控都可以，無非是鑒于成本考慮，我們不可能24小時都去監(jiān)控。

但是好在我們的訂單執(zhí)行細節(jié)都是留存在平臺上的，一是為了避免后續(xù)產(chǎn)生糾紛，二可以進行定制化抓取服務(wù)的開發(fā)，也就變成了從執(zhí)行中心推送一個定時任務(wù)到抓取服務(wù)，抓取只要拿著關(guān)鍵的信息蹲守，把鏈接獲取，更新至系統(tǒng)里就可以了，再一次減少了人工的低價值勞動。

二十一、總結(jié)

以上就是我在這份工作中負責的全部工作和經(jīng)歷，希望可以給正在經(jīng)歷此環(huán)節(jié)的企業(yè)或者老板一些幫助。

最后小廣告：目前還在找坑，有需求的老板隨時騷擾，中后臺方向/供給側(cè)/中臺訂單，謝謝觀看。

相關(guān)閱讀

兩年后臺工作，我把這些講給你聽（上）

兩年后臺工作，我把這些講給你聽（中）

#專欄作家#

吳邢一夫，人人都是產(chǎn)品經(jīng)理專欄作家。5年產(chǎn)品經(jīng)理工作經(jīng)驗，需求、用戶、數(shù)據(jù)有深入研究。歡迎交流想法，拒絕無意義添加好友。

本文獨家發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)本站許可，禁止轉(zhuǎn)載。謝謝合作

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