本文将从发单流程、订单分发、行程风控三方面出发，来和大家一起聊聊旅游行业中的专车业务。

旅游行业是一个比较有意思的行业，上游接洽：旅游公司、出行资源、酒店集团等供应商，下游连接：通过在产品上提供各种综合便捷的服务进而产生价值。

其中旅游的业务类型也十分繁杂有：出行：机票、火车票、专车租车，住宿：酒店预订，旅游：景区、跟团游、周边游等。

今天就专车业务中：发单、派单、安全为主写一下我浅薄的思考。欢迎业内人士指点补充。

正文前想问一下：为什么在滴滴已经成为国内出行行业的第一时，大多数的旅游公司如：携程、去哪儿、同城艺龙、航班管家还去涉及专车业务？

个人猜想的原因有：

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协议。