城市路侧收费率难提升？从追缴闭环聊聊系统该怎么做
做城市停车项目的人，多少都会遇到这个场景：
设备接入了，平台也上线了，报表看起来很完整，但收缴率就是提不上去，或者一阵子上去了，过段时间又掉回来。
很多时候问题不在“有没有系统”，而在欠费这件事上：欠费怎么清，怎么持续清。欠费清不动，后面想做充值、包月、优惠活动，往往越做越难，财务对账也会越来越痛苦。
下面我用比较工程化、好理解的方式，把“追缴闭环”拆开讲一遍。你可以把它当成招采条款清单，也可以当成技术方案评审清单。
1. 先说现实约束：存量改造拼的不是炫技，是成本和周期
路侧改造和车场改造这两年基本都在走存量路线。常见的限制就几条：
- 能利旧就利旧，能迁移就迁移
- 施工窗口短，不能长时间封路
- 弱网、断电、设备状态不稳定是日常
- 多厂家、多协议、多平台并存
所以系统建设目标通常不是追求“最先进”，而是追求三件事：
- 接得快：设备接入、数据上云、业务跑起来要快
- 跑得稳：弱网断网、断电、异常订单要兜得住
- 算得清：订单、欠费、回收、清分对账能闭环
2. 为什么收缴率上不去：你少的是追缴闭环
我把追缴闭环按最简单的顺序写出来：
欠费产生 → 识别归集 → 触达提醒 → 联合约束 → 结清回传 → 清分对账 → 运营放大
这条链条只要断一段，效果就会明显打折。
3. 城市级追缴中心到底要做什么
追缴中心听起来像“一个模块”，但在工程落地里，它至少要把三件事做成能力。
3.1 把欠费统一归集起来
欠费不是只有路侧。城市里常见欠费来源包括：
- 路侧泊位欠费
- 路外道闸场欠费
- 充电相关费用（占位费、超时费、停车费联动）
- 多渠道追缴产生的回收（比如 ETC、巡检车、终端拦截）
关键点是口径要统一，尤其是跨平台时，车牌和场景一定要对齐。
3.2 把追缴策略做成可配置
追缴不能靠“人工勤快”。在城市级项目里，策略必须可配置，否则换个区、换个运营主体就得重写一套。
常用的可配置项，我建议至少做到这些：
1）追缴范围
- 欠费来源（路内、路外、充电、占位费、超时费等）
- 车辆类型（小型、中型、大型、新能源、特种车辆）
- 车牌颜色（蓝、绿、黄、黑、白等）
- 欠费状态（新增、催缴中、分期中、结清、争议等）
2）追缴时间段
- 生效日期范围，比如某个阶段专项治理
- 每天的生效时段，比如白天强提醒，夜间降低触达
- 触达频率，比如当天提醒一次，第二天再提醒一次
- 静默期，比如触达后 6 小时内不重复打扰
3）金额分段和账龄分层
金额分段示例（可以按城市自己调）：
- 10 到 50：轻提醒，给支付入口
- 50 到 200：提醒 + 下次联动提示
- 200 以上：提醒 + 联合约束 + 分期引导或人工介入
账龄分层示例：
- 0 到 3 天
- 4 到 15 天
- 16 到 30 天
- 30 天以上
账龄和金额一般要一起用，才能把资源用在最值得追的欠费上。
4）处置动作编排
- 触达渠道：短信、公众号、小程序、支付渠道、人工工单
- 分期和缴清周期：按金额、账龄、车辆类型配置分期档位
- 联合约束：路内路外联动提示，跨平台联动提示，必要时做拦截规则
- 争议处理：申诉、复核、冲正、核销流程要有
3.3 把清分对账做成自动化
跨平台追缴最后一定会落到钱上。钱的问题处理不好，联合机制很难长期跑下去。
最容易扯皮的点有三个：谁贡献的，怎么分，什么时候结。
我建议把清分模型做成配置项，并按账期出对账单。
1）参与方常见类型
- 场景运营方（路内、路外、充电）
- 追缴执行方（巡检队伍或第三方服务）
- 平台能力方（统一归集、策略、对账）
- 渠道方（如果需要单独核算手续费）
2）清分口径建议写死
- 回收金额 = 实收 - 退款 - 冲正
- 可分成金额 = 回收金额 - 渠道手续费 - 约定扣项
3）贡献归因的做法
常见三种，建议至少支持其中一种，最好可切换：
- 以最后一次有效触达归因
- 以首次建案归因
- 按加权归因，触达次数、拦截成功等做权重
4）分成规则示例
这里给一个更容易落地的方式：按金额分段，再给账龄加成。
- 10 到 50：执行方 10%，平台 5%，场景方 85%
- 50 到 200：执行方 15%，平台 5%，场景方 80%
- 200 以上：执行方 20%，平台 5%，场景方 75%
- 账龄超过 30 天：执行方额外加 3%，从场景方比例里扣
账期可以按周或按月。最重要的是对账单要到订单级，能导出，能复核，能追溯。
对账单字段建议包含：
订单号、欠费单号、车牌和颜色、场景类型、应收、实收、回收金额、渠道单号、归因方、分成比例、分成金额、冲正标记、对账状态。
4. 跨平台数据交互怎么做，接口标准要先定
跨平台追缴最怕“每家系统一套对接方式”。建议把对外交换做成一套固定协议，大家按这个来，不用每次重写适配。
4.1 建议的接口最小集
1）推送欠费或更新欠费状态 POST /api/v1/exchange/debts/push
2）按车牌、时间、场景查询欠费 POST /api/v1/exchange/debts/query
3）结清、退款、冲正回传 POST /api/v1/exchange/payments/confirm
4）清分对账单下发 POST /api/v1/exchange/settlement/statement
5）黑白名单或重点关注名单同步 POST /api/v1/exchange/lists/sync
4.2 必须统一的主键和口径
这部分不统一，后面一定对不上账。
- debtId：欠费唯一 ID，建议全局唯一
- orderId：业务订单 ID，最好带来源系统标识
- plateNo + plateColor：车牌必须带颜色，不然跨系统会撞车
- sceneType：路内、路外、充电要用固定枚举
- amountDue、amountPaid、amountRecovered：应收、已付、回收必须严格定义
- occurTime、settleTime：统一时间格式，带时区
4.3 幂等和对账的硬要求
追缴、缴费、冲正这些写操作必须幂等，否则重复回调一次就会出大事故。
- 写操作建议带 Idempotency-Key
- 回调也要验签
- 状态流转用状态机，不允许随意改状态
错误码建议做得清晰一点，至少区分：
- 字段不合法
- 幂等冲突
- 主键冲突
- 内部失败可重试
5. 设备层怎么兼容，别让业务系统直连硬件
设备异构是常态。建议做统一接入层和网关适配，业务系统只面对统一协议。
常见做法是 MQTT 或 HTTP 做接入，再把设备身份和状态做成标准字段：
deviceId、vendor、model、firmwareVersion、在线状态、信号、电量、心跳时间、告警码。
告警码也建议统一，比如离线、弱网、低电、识别置信度低、设备异常重启等。
6. 停充一体化别只讲概念，重点是占位治理和计费口径
充电设施增长快以后，占位问题会变得很突出。停充一体化要能落地，至少要做到：
- 占位费和超时费能配置，能计费，能追缴
- 充电减免规则可配置，且能审计和追溯
- 路内、路外、充电的欠费能统一归集和统一结算
如果只是“互相跳转一下”，通常很难解决占位和对账问题。
7. 最后给一份我们操作过的执行清单，评审方案时可以直接对照
1）改造策略和分批上线计划
2）设备接入清单和协议梳理，验收指标明确
3）数据字典和口径统一，状态机定义清楚
4）追缴范围、时段、金额分段、账龄分层、动作编排都能配置
5）清分模型可配置，对账单能出到订单级
6）跨平台交换协议固定，主键口径统一，写操作幂等
7）停充一体的占位费、超时费、减免规则能落地并可审计
8）弱网断网、断电、断云、异常订单处理有完整兜底流程
