針對不同的貨物重量，大件物流公司將自身的產品布局為小票、大票、零擔、整車。物流公司利用自身平臺的影響力，通過整合上下游的車輛資源，為客戶提供全鏈路的運輸服務。

本文詳述了目前市場整車運輸行業的業務流程以及系統搭建方案。整車運輸可以理解為針對B2B的客戶，對原材料、零配件、商品這些大宗貨物進行干線運輸、倉間調貨等，系統搭建則需要建立客戶、平臺、車隊之間的貨物流、信息流和資金流，從而達到互利共贏的結果。

一、描述業務場景

如果你是水果供貨商，你需要將整車的農場的水果從原產地運輸到千里之外的城市銷售。你對運輸過程有哪些需求？

• 時效快；水果屬于生鮮類，銷售價格與其新鮮程度密切相關，作為經銷商，自然是希望越快配送到越好。時效最快的公路運輸就是點對點直發，中途無經停。

• 價格合適；在運輸時效達到的情況下，成本自然是越低越好。可以通過“貨比三家”的方案找到低價的車輛，多找幾個車隊談價格，選擇價格最低的一家去承運。

• 運輸安全；為保證貨物的安全，希望全程能夠監控車輛的位置、路況、車鎖情況。對于冷藏運輸，還有溫度監控的需求。

• 資金墊用；干線貨運的價格數萬元，對于現金流不足的小B端供貨商，希望拿到下游經銷商的回款之后，再支付對應的運輸成本。

對于車隊，希望平臺給他提供什么？

• 提前訂車；由于政策管控和場地限制，貨車一般都停留在城市近郊的停車場，當收到運輸任務時，才前往客戶處接貨；并且，提前預定用車需求，有助于車隊調配車輛，提高車輛的載貨率。

• 穩定的用車需求；車隊入駐平臺之后，希望有訂單量的保證，最好能夠讓自己養活整個車隊。

• 收發貨區域相對固定；每個車隊都有自己的承運范圍，超范圍運輸不屬于自己的業務范疇。

• 資金回款；車隊的指出包括燃油費、高速費、司機工資、車輛貸款以及保養費，快速回款有助于維持滋生的收支平衡。

PS：誰都想資金能夠進得快，出得慢，這個矛盾點無法克服，哈哈，那就只好誰強勢誰說了算。

好了，現在我們知道了客戶需求，現在可以針對每個客戶需求，思考如何搭建這個整車運輸平臺的功能、模塊以及詳細流程。

二、流程以及各模塊的交互關系

圖1 系統流程圖

三、客戶端

公司有維護客戶關系的CRM（Customer relationship management system，客戶關系管理系統），涵蓋了客戶簽約、注冊、維護、退出的全流程。客戶注冊時，需要包含三個層面的信息：基本信息、業務信息、財務信息。

1）基本信息：主賬號和子賬號、客戶名稱、客戶編碼、所屬行業、統一社會信用代碼、法人、注冊資金、注冊時間、客戶經理等。

2）業務信息：作用是管控與公司合作的業務范疇=以及計費方式=等。例如：使用的產品范疇、合作的區域等。我將計費方式歸屬到業務信息而不是財務信息，原因是，我們產生業務單據時，每條運單就能夠前置產生的應收流水，而不必等流轉到結算環節。

3）財務信息：賬期、結算方式、開戶行、銀行賬號、發票抬頭、發票類型等。

CRM系統能夠幫助企業鞏固老客戶的合作關系，通過分析客源結構，有助于幫助企業預測市場的發展需求和尋找潛在的客戶群，從而夯實企業在行業內的地位。我司屬于行業的龍頭企業，比一套完備的CRM系統，這個我在其基礎上開發新需求，然后直接調用主數據就好了。

四、采購競價

采購競價是交易過程的核心環節，競價是目的是為了給客戶提供高質量的價格，從而提高交易成功的可能性。有了承運商報價之后，平臺按照計費規則疊加一定的傭金，向客戶端推送報價金額。為了保證價格質量，系統在設計之初，就給自己定了幾個關鍵指標：

• 首次報價時間：首次報價時間越短，就能越快響應客戶需求，相對其他競爭對手就占有主動地位；

• 平均報價次數：平均報價次數越多，競價就越充分，價格相對越低；

• 報價率：為塑造平臺的能力，我們要保證100%的訂單都能收到報價；每日輸出采購過程的報表，分析每個車隊的合作情況，采用督促、約談、限制單量、懲罰等方式引導其配合交易。

在設計系統方案時，邏輯處理上涉及的細節較多，需要抓住主線進行頂層設計。

我選主線是競價狀態，對于每個競價請求，本質上都是收到在某些外力輸入（主動報價、取消、失效等），觸發一定的邏輯規則，輸出系統所預設的結果（競價狀態、價格等）。

我設計的競價狀態機如下：

圖2 競價狀態機

五、訂單管理

采購完成之后，信息流到訂單管理系統模塊，訂單的全生命周期開始了。訂單管理是整個業務流最核心的內容，只有產生訂單，才能有收入并且盈利，才能證明我們開拓了市場。訂單連接了客戶和車隊，平臺起到中轉和調度作用，讓信息、貨物和資金都流動起來，只有流動才能實現價值增長。

1）計價模型：用戶確認下單時，系統會先調用計價模塊，疊加傭金，計算應收的客戶運費。

2）訂單審核：對于惡意刷單、通過應收和應付賬期差占用平臺資金的行為，系統需要及時識別，避免問題發生。

3）增值服務：如果裝卸、吊裝等此類增值服務，還涉及到拆單的處理。主訂單發送給中標的車隊，然后調度中心會將子訂單分配給具有增值服務能力的供應商去承接任務，系統要做到應收合單計費，應付拆單計費。

4）在途監控：為了保證運輸時效，對于可能會晚點到達的車輛，系統需要及時預警，按照不同的預警等級向對應的運作人員發起提醒。越來越多的客戶期望能實時查看在途的位置，目前常用的軌跡采集方式有三種：司機app、車載北斗模塊、手動安裝GPS定位盒。每種工具的都有其優缺點，大家可以按照自己的需求選擇。另外，對于高價值的貨物，如果客戶有視頻監控、路寬查看的需求，可以購買并安裝一些IoT的終端設備。

訂單狀態記錄其生命周期，幾乎所有的業務系統都會涉及狀態枚舉以及狀態翻轉的邏輯，這也是產品經理的基本功，合理的狀態邏輯有助于系統后續擴展，以及避免意料之外的BUG。

競價狀態下游對接訂單的運輸狀態，運輸訂單的狀態主要有以下幾種類型：

• 審核中：多數訂單會跳過此狀態，及時識別高風險的訂單，啟動OA流程，流轉到相關干系人節點去審核。審核完成之后，才能進行下一步。

• 待付款：客戶可選用月結記賬以及散單現付的方式進行，現付又包括現金支付、掃碼支付、信用卡支付、銀聯支付。注意設置支付的有效期，超時則自動取消。支付完成之后，系統會下發運輸任務給車隊。

• 待發車：客戶下單之后，司機發車之前。司機在手機APP上啟動運輸任務，上傳操作信息到后臺系統。為保證運輸過程的真實性，防止刷單，需要校驗任務啟動的地址與客戶下單地址是否符合。

• 運輸中：司機發車之后，到達目的地之前。此過程需要實時采集司機的位置信息，客戶可在自己的終端查看。

• 已到達：運輸完整，司機到達目的地。此時開始計算應付的費用，向結算管理模塊推送應付流水信息。

• 已取消：客戶發車之前取消了訂單。這里系統沒有允許中途取消訂單，是因為這涉及到設置放空費的收取規則，以及需要客戶、司機、平臺多方審核才能生成此扣費單，對于研發和運營都是麻煩事，所以未建立線上化流程，而是采用又客服統一處理的方式。