第 5 章 · 共 15 章
一笔业务的五流闭环
5.1 先给所有事实一个共同钥匙
客运数据最容易出现“每个系统都对,但彼此不是同一趟”的问题。建议建立五级关联键:产品/线路ID → 服务日期 → 计划班次ID → 实际运行ID → 乘客订单/客票ID。包车可把线路ID替换为合同服务包ID;网约车可由行程ID直接关联司机、车辆、计价与支付,但仍需保留产品版本和经营区域。
| 事实 | 权威来源候选 | 必须关联 | 不能只信 |
|---|---|---|---|
| 允许经营什么 | 许可、线路/区域批复、公共服务合同 | 主体、业务类别、地区、有效期 | 营业执照简称 |
| 计划发什么班 | 排班/班次系统 | 产品版本、日期、车辆需求、时刻 | 运营群口头通知 |
| 实际谁开哪辆车 | 报班、司机签到、车辆门禁、动态监控 | 实际运行ID、司机ID、车辆ID | 事后补录名单 |
| 谁乘坐并支付 | 售票/派单、闸机/乘车码、支付 | 客票/订单、乘车事件、退款 | 支付流水单独存在 |
| 是否安全完成 | 动态监控、站务、司机、事件工单 | 轨迹、上下客、告警、异常结论 | 只有GPS终点 |
| 应收多少 | 计费引擎、合同、客票与服务验收 | 价格版本、完成事实、抵扣/退款 | 销售Excel |
图5:五流不是五份独立报表,必须通过同一产品、班次和行程标识彼此勾稽。
5.2 合同订单流
**B2C客票/平台行程:**产品与价规发布→乘客查询→实名/身份或服务条件核验→下单→支付/授权→出票或派单→退改/取消→行程完成→结算关闭。
**B2B通勤/包车:**线索→现场踏勘→方案与报价→合规和授信评审→合同→月度服务单/包车订单→乘客名单与行程确认→排班→履约→验收→对账→开票→回款。
**公共服务:**准入/招采或法定安排→线路与服务指标→运营计划→实际班次和服务数据→考核→合同/政策结算→资金拨付。公共服务收入或补偿不能脱离具体文件、履约事实和结算条件凭经验确认。
5.3 旅客服务流
旅客服务从“出门前”就开始:信息查询、无障碍与行李能力、票价和取消规则会影响乘客能否作出正确选择。到站/接驾后,站务或司机核验乘车权、人数、特殊需求和行李;发车前完成车辆与司机安全门;在途持续监控路线、速度、驾驶状态和乘客情况;到达后确认下客、行李、遗失物和异常;最后完成投诉、退款、索赔与失物闭环。
| 触点 | 乘客需要 | 运营证据 | 失败后的最低动作 |
|---|---|---|---|
| 查询/预订 | 真实班次、价格、车型和退改 | 产品版本、展示快照、订单日志 | 更正信息、保留受影响订单范围 |
| 候车/接驾 | 可识别车辆和司机、准确ETA | 车辆/司机匹配、到达事件 | 主动通知、替代或无责取消 |
| 上车 | 合法、安全、票证可用 | 验票、人数、行李/特殊需求记录 | 不超员;解释拒载/拒运依据并安置 |
| 在途 | 安全驾驶、合理路线、必要协助 | 轨迹、监控告警、停靠与事件 | 安全停车、单一指挥、急救/报警 |
| 到达 | 正确地点、人员和行李完整 | 结束点、时间、下客与遗失物工单 | 找回、转运、退款或索赔入口 |
| 售后 | 可理解的责任和时限 | 投诉、录音、调查、结论、支付 | 分级响应、证据保全、CAPA |
5.4 资金流
资金流至少分五个钱包:乘客票款或企业预付款;第三方支付/聚合平台待结算;企业或政府应收;司机/车辆/渠道待结算;事故、退款和保证金受限资金。财务不能把平台账户余额当银行可用现金,也不能把乘客预售票款全部当本期收入。
5.5 票据流
“票”在客运里至少有三种含义:乘车权凭证、会计/税务凭证和内部业务单据。客票证明乘车权与部分交易信息;发票用于税务与报销;派车单、报班记录、例检单、出站记录、行程单和验收单证明履约过程。任何一张都不能单独替代全部事实。
| 单据/记录 | 它回答什么 | 关键字段 | 常见误解 |
|---|---|---|---|
| 产品/线路批准记录 | 能否按此线路/区域和价规销售 | 主体、类别、区域、有效期、版本 | 有线路名就等于获准 |
| 客票/订单 | 谁买了什么乘车权 | 订单、乘客、班次、价格、状态 | 支付成功等于已乘车 |
| 包车/通勤服务单 | 购买方要求哪种服务 | 合同、日期、路线、车型、人数、价格 | 销售聊天可替代正式变更 |
| 排班/派车单 | 计划由谁开哪辆车 | 班次、司机、车辆、时段、批准 | 计划自动等于实际 |
| 安全例检/报班 | 发车前是否通过门禁 | 车辆、司机、检查项、结果、时间 | 勾选通过但无责任人 |
| 动态监控日志 | 在途发生了什么 | 定位、速度、时长、告警、处置 | 有告警就等于已处置 |
| 行程完成事件 | 是否完成约定运输 | 起终点、时间、乘客/班次、异常 | 司机手点完成是唯一证据 |
| 退款/服务抵扣单 | 为什么少收或退钱 | 原订单、原因、责任、批准、支付 | 用改价覆盖投诉 |
| 企业验收/对账单 | 哪些班次可向购买方计费 | 服务量、KPI、扣款、争议 | 月初预估表直接开票 |
5.6 数据流
客运数据包含高敏感度的身份、位置、行程、联系方式、支付、投诉和可能的健康/无障碍需求。应按目的最小化采集,把“安全和监管必须留存”“履约需要”“营销希望使用”分开授权和保存。现行网约车规则要求记录用户注册、身份认证、订单、交易和行驶轨迹等数据并备份;这不意味着可以无限期、无限目的共享。网约车现行办法(截至2026-08-10)
| 数据域 | 主要来源 | 合法使用场景 | 权限重点 |
|---|---|---|---|
| 乘客身份与联系 | 售票/App/企业名单 | 出票、实名、通知、客服 | 前台脱敏;批量导出受控 |
| 行程和位置 | 车载终端、司机端、乘客端 | 安全、派单、计费、投诉 | 实时位置与历史轨迹分权 |
| 司机与车辆 | 证照、排班、监控、维护 | 准入、派车、监管、安全 | 禁止普通运营改证照有效期 |
| 价格与支付 | 价规、计价、支付、退款 | 收费、开票、对账 | 价规发布与退款审批分离 |
| 音视频/报警 | 车载设备、客服、应急 | 安全调查、争议 | 调阅有目的、有记录、有期限 |
| 企业/政府服务数据 | 合同、班次、验收 | KPI与结算 | 只能按合同和授权提供必要数据 |
章末理解检查
合上原文,你能讲明白了吗?
不看原文,用自己的话解释「一笔业务的五流闭环」真正要解决什么业务问题。
已输入 0 个字,还需 12 个字;提交后会显示自检标准,并把本章记为已完成。