自前幾天發布《瞎搞!論當前城市物流APP》一文后，與很多朋友就城市配送問題進行了一系列的探討。在這幾天的思考中，通過對當前過度火熱的互聯網+浪潮的反思，腦子里不斷浮現出關于從城市物流這個角度需要什么樣的功能來支撐，來幫助城市物流的發展。以下，僅從我個人的角度展開，如果讓我來做，我會怎么做。
(注意，如果說還是迷信“滴滴模式”“Uber模式”，那么可以關閉此文，因為“滴滴模式”“Uber模式”并不適用于城市物流。)
目標用戶群體在哪兒?
從嚴格的劃分上來說，主要分為C端用戶和B端用戶兩大類，C端用戶主要以搬家為主(別提同城小件，就對個人而言，APP的價格競爭力永遠比不上專業的同城快遞公司)，B端用戶主要涵蓋物流企業、專業市場、制造企業、電商O2O企業和商貿流通企業。每一類B端用戶面向的收貨市場又不相同，具體為：
但不是每一類企業都有對車輛的需求，對于B端用戶，可以劃分為三類，即增長型B端、平穩性B端和衰退型B端，以企業自購車為例，其每一段所需又不相同，具體為：
因此，可以看到并不是所有的B端用戶都只是簡單的需要車輛。因為對于大多數的目標客戶來說，他們都有一個固定的車輛熟人圈，別提平臺的各種認證，那是APPs認證的事，目標客戶會認為他們自己認證的車輛更加靠譜，因此只有針對快速增長型的用戶，因熟人車輛的限制才需要大規模的引入車輛。就算是處于穩定型和衰退型的企業，他也會優先考慮自己的熟人車輛。而管理功能和消化企業閑置的資源也是用戶的需求點，而這兩點除了重慶本土一家叫“CE貨的”之外，測試過的其他所有的APP都缺失的。
運作模式如何設計?
配送不等同于運輸，配送的復雜程度遠大于運輸，且上文也提到，簡單的照搬運輸點對點的功能是不能滿足整體城市的配送需求，且也毫無競爭力可言，但在該部分又因保有一定的業務量，因此不能割舍。但對于宅配、商超配送應該作為重點產品單獨劃分出來(如果劃分更加細致，則可將家電宅配、生鮮宅配、普貨宅配)。如果說傳統的部分，即直送倉庫部分可以采用傳統APP所具備的點對點匹配的話，那么該部分必須以SOP運作標準為基礎，以專業化的運作團隊、車輛團隊為核心，且該部分必須是實打實的培訓，而不是一紙空文一筆帶過。
目前整個物流市場已經被200多個APP所自稱的“標準”搞得夠亂了，再我看來，他們所謂的“標準”即是沒有標準。APP是產品，輸出的各種形態也是產品，而很多APP忽略到了這一點。家電宅配，生鮮宅配，普貨宅配，商超配送，每一種不同類別的配送方式均涵蓋有不同的服務特性，必須根據每種不同的服務特性去完成不同的服務產品，而不是胡子眉毛一把抓，至于具體的每種產品如何設計，因篇幅原因，這里就不一一細說了。
接單模式如何設計?
在《瞎搞》一文中，我狠批了一下搶單和競價模式，這里聲明一下，并不是該模式不行，而是目前采用的這模式太過于簡單粗暴，正如某些部門懶政一樣，采取頭疼醫頭腳疼醫腳的做法。整體的定價模式采取議價制，讓供需兩端根據市場自行進行商議的方式完成，但僅僅依靠議價機制，會大幅提高準入門檻和流程消耗時間，不利于客戶體驗，容易導致用戶流失。因此需要以大數據為基礎，并在背后加入眾多的參考維度以縮短后臺數據計算時間，能夠快速得到該線路歷史服務價格。這還遠遠不夠，還需再結合發運訂單的時間，天氣情況等眾多實時客觀因素綜合起來后給出最終的價格供用戶進行參考。因整體參考了的是歷史運價，且城市配送具備一定的波動性，因此會設置一個區間范圍讓用戶對價格進行相應的調整。在用戶下單后，同樣系統根據用戶下單的相關參數對符合該條件的車輛進行小范圍的推送，由接收到相關信息的司機進行價格反饋(當然，在界面設計上會趨于人性化的快速反饋機制)，讓貨主選擇他個人認為最為合適的車輛。當然，這里面有需要機制需要進行設置，具體的設置方式因篇幅原因，就不一一細談，如果有興趣，我們可以私下探討。
管理模式如何設計?
我的貨送到哪兒了?怎么貨還沒到?我今天發運了多少訂單，發運金額是多少?我這個月發了多少，及時率如何?每一單耗時多少，我該如何跟我的客戶承諾多少時間送到?等等諸如此類的問題。目前市面上提供的產品大多數僅僅是顯示一個幾個訂單狀態，在歷史訂單做沉淀就完事了。在精細化標準的今天，很多客戶都有對自己物流板塊經營情況的分析需求，但讓他們購買一個信息系統是不現實的，采用手工臺賬是落后的。因此，一些簡單的信息系統功能是應該具備的，對于技術成熟的今天，這些功能要實現不難。
另根據心理特征，人們對未知的事物都是帶有恐懼的心理，當貨離開貨主手中之后，往往需要一個跟蹤信息反饋，讓貨主放心，放心他的貨能夠按時抵達，放心他的貨不會串貨等等。而這一點，我在3月份測試一號貨車的時候，沒有，到7月份測試的時候，還是沒有(第一次測試的時候我是有打客服電話提出這個問題)。
總結
首先從C端用戶說起，C端用戶主要以搬家為主，而我們知道C端用戶對于物流而言是非常不穩定的，其不穩定性在于需求不穩定，忠誠度難以培養(不要提德邦，德邦的主要用戶群是在于企業，而非個人，對于個人，是坑一票算一票，當然這是我一家之言，因為我被坑過，所以借這里吐槽一下)。其向B端的轉化率非常低。而B端，因收貨目的地不同，不能簡單的以車貨匹配為基點，那毫無競爭力可言，點對點的以倉庫為目的地的配送，人人都可以做，無外乎就是比誰燒錢燒得厲害，但毫無收益可言。因此個人認為應該突出專業化的設計來提升競爭力，搞定別人搞定不了的，設立起競爭壁壘。
模式的設計總共只寫了最為關鍵的三個部分，每個部分的設計都本著如何給客戶解決麻煩，而不是去添堵的角度出發的實際問題。其中還想涉入虛擬倉庫集拼之后的共同配送，動態拼車，批量車輛管理等功能設計，如果細化下去肯定是又臭又長，有點類似于產品說明書了，這里就不細說。整體上，想表達的是，產品的設計，要根據實際城市物流上產生的問題進行針對性的解決，而不是運用變質的“互聯網思維”進行簡單的改造。互聯網只是工具，這個工具讓我們的效率更加的快速，而非打著這個旗號忽悠。
以上內容，是我個人的想法，再次聲明，該觀點與我所在的公司寶供物流無關。
最新論文