乘客“确认同行”环节降低阻断

链路现状

目前在顺风车中，不同支付类型的订单流程不同，在非预付单中存在“确认同行”环节。这类型的订单导致，车主已经接单了，但订单不能进入履约；乘客已经发单成功，但还需要再次感知、决策和支付。

链路漏损：非预付单的核心漏损在“确认同行”

通过对非预付单与预付单的转化数据对比，可以发现非预付单接单后到达目的地转化比预付单低29.4%，其中最大的差异来自“乘客确认同行”节点。非预付单接单后到确认订单转化漏损 36.4%，表明非预付订单在车主接单后，仍然因为乘客未确认而流失。

干预机会

进一步下钻非预付订单取消原因后发现，车主接单后乘客未确认的订单中，约41.9%的订单来自乘客不知道被接单、联系不上、双方存在信息差或时间差等原因。 这类问题与乘客临时行程变化、高速费协商失败的原因不同，它并不是用户明确拒绝同行，而是流程要求乘客“及时再次操作”，导致订单被动流失，因此存在干预空间。

订单流程是否真的需要确认同行？ 确认同行的功能定位是？ 确认和支付是否必须绑定在接单后这个节点？ 乘客未及时支付，是否一定要阻断车主进入履约？

可以看到“确认同行”绑定了三个事情：1. 乘客确认自己仍然要出行、2.乘客需要完成支付、3. 平台允许订单进入履约。导致只要乘客没有及时完成支付，订单就无法进入履约，车主也无法继续推进接驾。

我们将解耦“确认”与“支付“，重新设计支付发生的时机和风险承接方式，降低“确认同行”对订单流转的阻断，让订单更顺畅地进入履约，提升完单量。

确认同行带来了转化漏损，也承担了风险控制作用，不能被简单删除，所以考虑了两种解决路径： 保守路径：支付节点前置，提升代扣比例，让更多订单跳过确认同行 探索路径：支付节点后置到履约（前期可面向高信用用户开放）

目前代扣 (免密、先乘后付) 开通比例、预付比例仍有较大的提升空间：

1. 发单中非预付订单占比49%，预付、先乘后付、免密代扣订单占比均还有较大的提升空间。行业报告显示，网约车行业的后付比例在85%左右，好的平台可以做到90%。

2. 哈啰用户的芝麻先享后付准入率很高，目前先乘后付在准入门槛上不是阻碍，功能渗透的提升空间较大。

01. 支付节点前置

a. 进入等待接单页，自动拉起预付弹窗 乘客已经发单成功，出行意图明确，同时订单尚未被车主接单，避免了接单后确认同行的阻断。

b. 精简支付链路，降低漏损 参考电商、本地生活等行业，支付能力融入现有关键页面，从独立收银台到聚合收银页。

02. 提升先乘后付比例

在询价页、等待接单页，增加先享后付开通入口，引导乘客在发单阶段完成代扣授权开通。结合默认推荐和默认勾选策略。

实验&效果反馈

为了看清不同节点功能改造对转化的影响，基于询价页先乘后付与等待接单页预付弹窗的不同组合设计了4个实验

整体来看，实验组1 整体效果最好，接确率显著+2.25%，发完率显著+0.56%。推全预估日均新增完单+****，访完率+0.2%。 效率指标来看，实验组2 发完提升最显著，但需降低询发漏损。实验组2 接确率显著+2.67%，发完率显著+0.91%，说明提升先享后付占比能更大幅度的提升发完。但询发-0.25%，主要由哈罗APP导致，说明先享后付在支付宝端有更好的认知基础，用户对询价页默勾先享后付的接受度更高；同时猜测默勾先享后付、展示“0元下单”抬升了用户认知成本和警惕心理，抑制询发。

设计优化迭代

在保守路径正向收益的基础上，降低用户对“0 元下单”和自动扣款的顾虑；同时在微信小程序端接入微信支付分先乘后付，补齐微信端代扣能力覆盖，让更多订单在车主接单后自动跳过确认同行。

经过保守路径优化后，仍有占接单量42.7%的订单会经过确认同行页。虽然更多订单可以通过预付和代扣跳过确认同行，但仍然存在大量订单被这个节点阻断。

乘客发单本身已经表达了同行意愿，车主接单后再要求乘客确认一次，导致额外的阻断。我们需要保障支付完成，而支付不一定必须发生在接单瞬间。

核心主张：解绑“确认”和“支付”

乘客侧：去除确认同行概念，接单后无需再次确认，最晚在上车前完成支付。 车主侧：不因乘客未支付而阻断接驾，但通过提示和强阻断节点管理预期。

01. 乘客侧方案

接单后未支付时主操作为支付，上车节点强引导支付，支付入口与确认上车行动结合，并将优惠、券包搭售模块整合进收银台。

• 乘客不再需要理解确认同行这个概念，页面只表达需要在上车前支付；
• 支付入口和履约行动点结合，当前主要操作是支付，支付同时完成确认上车动作；
• 优惠券和券包搭售放进收银台，作为支付钩子激励乘客支付。

02. 车主侧方案

目的：让车主理解乘客会在上车前完成支付，未支付不会影响当前接驾流程，弱化未支付带来的不确定感。

所以最终选择了方案B： 在车主未出发、已出发、已到达起点等阶段，副标题透传“乘客将在上车前完成支付”； 当车主确认上车时，如果乘客仍未支付，则进行阻断提醒需要乘客先完成支付，并配合语音播报。

03. 风险治理

支付后置的方式，最大的挑战就是信任和风控，在设计方案之外，产品侧复用线上已有判责能力：约束乘客取消、线下交易的行为进行配置，并前置同步客服部门确保新支付节点上线后能承接异常问题。

a. 针对空驶和收入损失，通过判责约束乘客取消订单，在规则和后续宣导中增加披露判责逻辑与乘客是否支付无影响等信息打消车主空驶顾虑；

b. 针对纠纷和线下交易，通过线下交易策略约束，增加更多信息消费，校验拦截取消订单，同时新增故意不支付需的判责。

效果反馈

接完率显著提升，车主取消率显著下降，推全预估日均新增完单+****，验证了跳过确认同行可以减少车主长时间等待乘客确认/联系不上/不知道被接单导致的订单被动流失。

但投诉率显著增加，主要投诉类目是态度恶劣和联系不上乘客。猜测一方面是因为支付由履约开始前移到了履约中，支付提醒和风险感知会带给车乘沟通压力，引发了更多的车乘摩擦，另一方面确认同行被移除后，原本由它承担的支付确认、车乘预期同步，需要被新的触达和提醒补上。后续也需要加强司乘联系链路，通过平台触发短信、IVR等方式强提醒乘客。

01. 聚焦关键问题

项目的核心目标是降低确认同行对订单流转的阻断，减少该环节的漏损，提升完单量，但经过分析后发现，确认同行页面本身并是问题所在，问题关键在交易链路。如果只优化页面按钮、文案或提醒，或许可以提升部分确认效率，但从整个交易链路来看后，设计的空间和机会也变的更大，同样设计解决方式也更泛。

02. 分步推进更有优势

a. 降低推进成本，保守方案不直接挑战交易规则，更容易落地，也能快速拿到结果。 b. 为探索方案提供数据依据，保守路径验证了确认同行确实是关键阻断，也证明了跳过确认同行能带来完单增量，继续探索路径不再只是主观设想，有了业务结果支撑，同时利于探索路径的协作和落地。

03. 设计独立推动项目，需要有半个产品的能力

项目是设计立项，设计师不仅要输出方案，还需要参与价值测算、实验设计、解释数据差异，并推动下一轮策略。