代驾采购会上，业务负责人常抛出两种声音：酒后人只想看一个「到手价」；财务和司机又怕一口价吃掉高峰时长与远程成本。系统若只能二选一，要么转化差，要么投诉多。更稳妥的做法是：文档里那套计价栈配清楚，再用业务开关决定要不要开一口价，以及要不要用特惠价按里程阶段让利。

下面只写代驾功能列表与已确认能力清单里的内容：确认价格页的预估价/优惠价与明细；计价方案含起步/里程/时长/远程/等待 + 周期 + 特惠价按里程阶段；业务开关一口价计价（按预估里程、时长）。不编造夜间单独加价产品名（可用计价周期/时段单价覆盖同类需求）。

用户看见什么：预估价、优惠价与明细

乘客设好出发地、目的地后，确认价格页会按系统计价方案展示预估价、优惠价两种用车方式，并可查看对应计价规则明细。小程序侧支持微信快捷登录，发单前把价说明白，比完单后改价省事。

若后台开了最低里程限制，预估里程不足则无法用车——近日文章写过最低里程与特惠组合，今日主线放在计价组成与一口价开关，最低里程只作边界提醒：价表再漂亮，里程门槛没配也会拦单。

计价栈：起步 / 里程 / 时长 / 远程 / 等待

后台计价方案价格组成包含起步价、里程费、时长费、远程费、等待费。起步价分起步费与基础费：起步费需设起步价、起步里程，可设起步时长；基础费只设起步价，实际价由里程和时长决定。里程费是每公里单价，时长费是每分钟单价，远程费按不同里程区间分别计，等待费管司机到达上车点后的等待。

还可按不同时间阶段设不同起步价与单价，并设计价周期（工作日、周末、节假日、自定义）。这就是「打表」侧的完整栈。演示时建议用同一起终点，切换工作日/周末方案，让采购方看到预估变化，而不是只念参数名。

特惠价：按里程阶段设单价与封顶

特惠价后台可开关。打开后，可按里程阶段设置该阶段里程费，以及该里程阶段的最高收费。适合「前几公里更便宜、超过某里程恢复常规或封顶」的运营策略，和整单一口价不是同一个开关。

配置顺序建议：先定常规计价栈与周期 → 再打开特惠价填阶段表 → 最后在乘客确认价格页核「优惠价」是否按预期出现。文案上对司机和客服区分「特惠里程阶段」与「一口价整单」，避免司机按打表心理期望收款、乘客却按优惠价支付。

一口价开关：整单按预估里程与时长

业务板块「订单设置」含一口价计价：订单按预估里程、时长一口价计价。与上面「打表栈 + 特惠阶段」并列存在——开一口价时，面向的是「出发前锁定总价」的场景；关一口价则更多依赖预估展示 + 完单按规则计费（具体完单确认与支付方式另有乘客支付、司机代付、现金/出示收款码等已确认能力，今日不展开收款码出车门槛）。

同组开关还有线上支付、司机代付、现金支付、接单限制、收入冻结、最低里程等。上线清单里把「一口价是否默认开」写成运营决策，不要留给司机端自行理解。

落地时建议先用两三个真实高频起终点（例如酒吧街到住宅区）把打表栈跑出合理预估，再决定要不要开特惠价做前段让利，最后评估一口价开关对高峰单的影响，必要时按城市或活动期切换。

上线前按这几单验收就够：确认价格页预估/优惠与明细能看懂、计价栈与周期切换后预估跟着变、特惠价按里程阶段生效且和一口价开关分开验证、一口价按预估里程时长锁总价。要把价讲清楚，联系我们聊 Ptaxi 代驾系统即可。