本文將從發單流程、訂單分發、行程風控三方面出發，來和大家一起聊聊旅游行業中的專車業務。

旅游行業是一個比較有意思的行業，上游接洽：旅游公司、出行資源、酒店集團等供應商，下游連接：通過在產品上提供各種綜合便捷的服務進而產生價值。

其中旅游的業務類型也十分繁雜有：出行：機票、火車票、專車租車，住宿：酒店預訂，旅游：景區、跟團游、周邊游等。

今天就專車業務中：發單、派單、安全為主寫一下我淺薄的思考。歡迎業內人士指點補充。

正文前想問一下：為什么在滴滴已經成為國內出行行業的第一時，大多數的旅游公司如：攜程、去哪兒、同城藝龍、航班管家還去涉及專車業務？

個人猜想的原因有：

1. 產品：專車業務在旅游產品中是對出行需求的完善和對余尾流量的轉換。場景如：用戶有了具體的旅游目的后，開始預訂機票，然后預訂酒店，之后預訂專車接駕至酒店。
2. 市場：以前看到過一個數據，滴滴已經是市場幾百億美刀的巨頭，但對的士出行的滲透率還沒有超過50％，說明行業十分巨大，針對具體的細分場景仍有文章可做。
3. 故事：描繪一幅更壯闊的藍圖有利于資本的青睞。

我們可以將網約車業務分為：乘客發單、司機接單、接駕服務三部分，從：發單流程、訂單分發、行程風控三個方面談些思考。

一、發單流程

產品目標：讓用戶以最低的成本完成發單流程。

航班管家送機用車流程待優化點：

1. 用車入口：需要點擊詳情才能輸入航班號或目的地；
2. 送機出發地：需要再次輸入出發地點詳情；
3. 乘車人：必填項未前置默認選擇與選擇歷史乘車人需再度確定；
4. 判斷：支付頁面提示30分鐘后使用車輛但當前頁面無更改按鈕；
5. 流程：入口、選車、乘車人頁、結算頁些許信息冗雜。

同城用車接機流程待優化點：

1. 出發機場：未根據最新支付訂單自動獲取接機出發地；
2. 選擇航站：熱門航站樓未使用卡片式設計閱讀較吃力；
3. 到達地址：未根據酒店訂單與當地熱門景點進行推薦；
4. 到達地址：搜索后無聯想推薦目的地；
5. 訂單結算：行程信息展示折疊。

解決方案：

先說結論：在策略預測的輔助下盡可能讓用戶通過“點擊”完成發單。

首先將乘客端發單元素進行重新組合分為三個步驟：發單頁、服務頁、結算頁。

1. 發單頁：在N時我有用車需求從A地到B地

如果專車業務在旅游產品中定位是對出行需求的完善和對余尾流量的轉換，用戶是開始預訂機票，然后預訂酒店，之后預訂專車接駕至核心目的地，那么就要充分對平臺的：機票、火車票、酒店、旅游團票等數據進行挖掘，更加準確的預測用戶行為進而降低使用成本。

① 所見即所得：進入相應的用車頁面即直接見到用戶要操作的關鍵要素：出發點、目的地、時間。

② 目的地選擇：通過平臺底層數據的分析預測用戶需求，使得：目的地前置推薦、搜索推薦、搜索建議三個策略相互作用，可以大幅提升用戶選擇出發地的效率，詳情見下圖：

③ 時間選擇：選擇組件類目可分為：即時、今日、明日、推薦日（即用戶是否在平臺上有購買相對應當天的機票火車票推薦）、日期順序排列，設置最長預約展示時間。

2. 服務頁：我們一行2個人想坐X車去

發單頁與服務頁的承接設計建議要顯得沒有切換整體的感覺，進而將不同的信息聚焦在當前頁面便于用戶識別，使得整體流程是用戶通過點擊平滑完成的。

① 車型：默認選擇平臺訂單量最高的車型，用戶如手動其他車型支付成功下次則記錄上次選擇。

② 乘車人：默認選項本人乘車，根據接車服務場景制定是否必填和是否讀取機站票和通訊錄信息，最后選擇僅需一次點擊。

③ 價格：根據平臺定價規則給出參考值，參考值可再次點擊拆分顯示價格組成詳情。

3. 結算頁：我從A地到B地使用優惠券后一共要付Y元

① 行程信息：展示用戶在什么時間坐的什么車從A到B地花了多長錢即可，也就是以上用戶操作的所有結果進行聚合展示。

② 支付結算：根據業務形態制定結算規則，關于支付有一個假設想法請往下看。

③ 評價操作：如有用戶評價主要關聯2個點：1.用戶的需求是否沒有被滿足，這里可以發泄吐槽。2.用戶是乘車的體驗評分會與司機關聯進而影響到司機訂單派發率。

提出一個假設：能否將發單流程從行程支付進行分切，打出：”陌生城市接駕，先行后付全保障“的理念？

1. 支付前：系統根據是否有機站、酒店、旅游訂單，自動為用戶推薦選擇：接送機、出發地、目的地、時間、個人常用車型等。
2. 行程后：行程結束后，用戶進行確認支付，選擇評價即可。

如果能夠做成這樣：用戶每步需要做的就是“點擊”確認，而非通過輸入信息后匹配需求，再次簡化用戶提交用車需求的步驟。

二、訂單分發

訂單派發系統是網約車服務中的核心引擎，他直接關乎到用戶的乘車體驗和司機的錢袋子，

先說結論，三步走：1.梳理行業場景特性。2.梳理平臺角色訴求。3.定義不同場景的撮合規則。

首先我們對旅游出行的特性進行梳理：

1. 旅游是低頻高客單價的行為，每張票都意味著大概率乘車行為。
2. 旅游是并發行為：訂票的同時可能會訂門票、酒店、專車等。
3. 旅游是跨市出行：從熟悉地到機場車站，抵達陌生地再出發目的地。
4. 旅游是雙向行為：到陌生地地后還會回到熟悉地。

其次對平臺上的兩個角色：乘客、司機進行分析，了解他們的訴求：

1. 乘客的需求：

基本需求：① 安全；

期望需求：① 速度：等待時間短，到達目地快 ② 各種關懷服務。

2. 司機的需求：

基本需求：① 收入；

期望需求：① 價值：接駕最短、路程最長。

乘客與司機的目的都是相同的：雙方都希望促成交易的，矛盾點在于：每個人都希望自己是最優質的對象，乘客希望等待時間最短，司機希望訂單價值最大，而優質的資源是稀缺的，所以我們需要根據階段性目標找到其中的平衡點進而制定方案。

最后定義不同場景下的司乘撮合規則：

產品目標：提升司機乘客訂單成交率。

底層規則：供給占用優先 以司機為中心的訂單推薦系統。

策略方案：

1. 以司機為中心，當司機需要訂單時，拉取周圍訂單，按照CTR預估模型進行排序。

2. 排序系統特征：

乘客：接車距離（司機空駛）、目的地特征、司機特征等。

司機：訂單金額、訂單長度、完結訂單后接車預估，已被搶概率、取消概率等。

3. 存在最大播單距離，以保證司乘體驗，定義每個角色的利益邊界值：

乘客：最能接受的最長時間是X 分鐘。

司機：最能接受最遠的接駕距離是X km。

再根據當前目標制定其他規則保證目標不會偏移，如：

1. 兩個訂單價值相等，優先距離更近的訂單減少乘客等待時間。
2. 實時單：拉取一遍接駕地附近的聽單司機進行分發，如果沒有再拉取行車目的地在接駕地附近的訂單進入排序隊列。
3. 預約單：根據接駕距離由近至遠分發，考慮司機當日的訂單接駕是否來的及進而合理安排訂單，促進司機訂單賺錢與乘客減少等待。

再次提出一個假設：滴滴已經占據了網約車平臺較大的份額，司機的存量是有限的，為了滿足平臺更多的用車需求，是否可以在自營專車司機的同時通過合作的方式與滴滴建立合作關系，打通雙方的訂單接口，在一些特殊的時間和特定的場景中將這些訂單分發給滴滴平臺，進而更大滿足用車需求。

三、行程風控

18年網約車數次安全事故都將滴滴安全上的不足展現出來，安全是一切之本，安全是信任基石，安全是平臺應該著手考慮的基礎策略，隨后滴滴也將“安全”列為了接下來發展的第一要素，我認同：國民產品應該承擔起國民責任，俠之大者為國為民，產品亦如此。

凡是有利益的地方就會有作弊，凡是有作弊的地方就會有風控策略。

產品目標：最小成本避免乘客司機雙方傷害。

行程前

1. 實名認證：

① 司機：幾次安全事故中都有冒用司機資格的事件發生，司機有出車和收車兩種模式，每當司機出車時都需通過APP 人臉識別 驗證一下是否本人。

② 乘客：接入身份證實名認證，將所有用戶放入模型打分：核心判斷條件：征信、芝麻信用分、工作工種、刑事紀錄等，其次當事故發生后即可查詢到用戶的身份信息，便于通知家人和協助警方破案。

2. 訂單分配：

分配：將“司機分”納入訂單推薦策略做考量目標，其次用車乘車后可對司機進行評價，根據評價維度即時調整司機“分數”，對于不同分數的司機具有不同的權益如：① 80分以上可接非常優質的訂單。② 60.分以下在平臺屬于重點關照對象，具體策略可以根據平臺規則制定。

行程中

1. 行程風控系統搭建

核心觀點：通過對每個正在行程訂單都設定一個動態“安全系數”，并依照安全系數的變化去判斷每一單當下存在的風險程度，通過即時不同風險的程度建立不同的應對方案，進而盡可能的降低風險影響。

風控系統監控值：

① 司機：

基本信息：性別、年齡、籍貫、三證完善程度、上車驗證信息。

違規投訴：分為幾個等級：初級、中級、嚴重，一旦系統打上標簽違規投訴的標簽，即對司機的訂單分配利益有影響，如出現嚴重投訴，可采取封號或暫停派單的處理。

歷史評分：行程歷史評分為司機重要參考點，接單數量與評分都是越高越安全。

其他參考：例如征信體系、芝麻信用分等具有參考意義的指標。

② 乘客：

基本信息：性別、年齡、學歷、籍貫、身份證、手機設備（ios&Android）等。

歷史行為：產品上的交易次數含：機票、車票、酒店、旅游等，乘車次數與金額，次數越多金額越大代表安全分更高。

其他參考：例如征信體系、芝麻信用分等具有參考意義的指標。

有了基本監控值只是基礎分數，還要根據訂單行程的實際情況自動調整分數，行程中監控的環節有：

1. 觀察車輛的行駛路線與滴滴系統推薦的路線是否有大幅度的偏離，一旦有偏離，就立刻關注相關情況，并對司機和乘客進行提醒，并降低安全系數；
2. 觀察車輛的是否在無擁堵的情況下長時間在某地停留，如果超過某個時間，這個情況也會成為可能的風險點上報提醒，并降低安全系數；
3. 乘客如果分享行程相應也會影響分值，乘客或者司機點擊“緊急求助”按鈕，安全系數降為0，升級為最高優先級事件處理。

不同的分數等級將會觸發不同的級別，會有不同的方案措施如：

1. 80~100分：安全。
2. 70~80分：系統推送消息。
3. 60~70分：提醒人工關注行程。
4. 0~60分：最高級別關注，啟動緊急預案。

2.行程預警

① 行程分享：上車后支持一鍵分享行程給其他好友，通過人與人之間的關注預防發生或提升發生后及時響應的速度。

② 一鍵求助：用戶可操作一鍵求助，點擊后在風控系統中直接將此訂單標注為最高優先級，官方核對后支持同步一鍵報警，即時把此訂單的：司機所有信息、乘客所有信息、路程詳情信息提取成表，便于協助警方處理案件。

以上，便是旅游行業網約車中的發單、派單、安全為主的淺薄思考，感謝閱讀。

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

題圖來自 Unsplash，基于CC0協議。