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

接中篇。

十五、核心指標(biāo)

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

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

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

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

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

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

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

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

本以為會(huì)提效，沒成想又變成降效。

首先這個(gè)功能確實(shí)抓住了痛點(diǎn)，但是沒考慮到，當(dāng)所有人都去這么使用的時(shí)候，方案錯(cuò)了：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十八、消息配置中心

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

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

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

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

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

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

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

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

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

各位母嬰博主，平臺(tái)最新發(fā)布本月母嬰博主榜單，請(qǐng)及時(shí)查收。

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

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

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

十九、訂單中臺(tái)

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

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

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

1. 名詞

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

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

標(biāo)準(zhǔn)通稿就是反過來的——因?yàn)闃I(yè)務(wù)非標(biāo)，導(dǎo)致商品非標(biāo)。

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

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

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

鑒于非標(biāo)業(yè)務(wù)線的特性，也造就這兩條業(yè)務(wù)線在業(yè)務(wù)中的最大差異：非標(biāo)業(yè)務(wù)線會(huì)在下單流程中增收保證金，因?yàn)闇贤ê秃罄m(xù)成本太高了；另一條就不用了，非標(biāo)品轉(zhuǎn)化為標(biāo)品，相對(duì)確定性。

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

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

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

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

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

這是介紹訂單之前的前期概念認(rèn)知。

2. 下單流程

當(dāng)客戶準(zhǔn)備下單的時(shí)候，經(jīng)歷的標(biāo)準(zhǔn)流程是非常長(zhǎng)的，這里詳細(xì)介紹下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 商品評(píng)價(jià)

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

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

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

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

4. 保證金

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

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

5. 訂單元素

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

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

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

6. 訂單邏輯

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

比如：

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

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

最后的下單者即當(dāng)時(shí)登錄博主的下單者，用于后續(xù)的追責(zé)。

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

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

需要交保證金業(yè)務(wù)線的訂單，不支持多個(gè)訂單一起下——因?yàn)楸ＷC金和尾款實(shí)際是父子訂單連在一起，如果也支持多個(gè)訂單一起下，相當(dāng)于父子孫訂單，實(shí)在不劃算。

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

7. 訂單運(yùn)營(yíng)規(guī)則

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

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

8. 狀態(tài)機(jī)

下面說下重點(diǎn)的訂單狀態(tài)機(jī)：

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

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

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

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

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

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

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

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

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

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

所以可以在小中臺(tái)訂單中心去實(shí)現(xiàn)：

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

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

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

因?yàn)槭峭ǜ?，客戶帶著文案來的，你幫忙發(fā)就行；所以博主在規(guī)定時(shí)間執(zhí)行完畢，質(zhì)檢接入，機(jī)器判定執(zhí)行狀態(tài)后，自動(dòng)幫客戶進(jìn)行確認(rèn)，直接變成待評(píng)價(jià)狀態(tài)，評(píng)價(jià)完畢后訂單完結(jié)。

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

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

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

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

再來說一下父子訂單：

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

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

9. 合單

合并訂單的邏輯是：

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

10. 拆單

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

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

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

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

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

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

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

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

11. 投訴

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

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

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

12. 財(cái)務(wù)

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

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

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

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

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

13. 私有化

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

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

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

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

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

二十、項(xiàng)目結(jié)果

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

1. 核心指標(biāo)

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

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

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

2. 小優(yōu)化

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

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

當(dāng)時(shí)就思考如何解決。

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

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

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

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

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

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

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

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

二十一、總結(jié)

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

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

相關(guān)閱讀

兩年后臺(tái)工作，我把這些講給你聽（上）

兩年后臺(tái)工作，我把這些講給你聽（中）

#專欄作家#

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

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

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