运费调整时，审批流怎么设计：不是谁批都行，是要分层到责任链

运费调整是 TMS 里最日常的操作，但它背后藏着一个系统性风险：审批边界不清，谁都能批，结果谁都不用负责。

一、先说一个真实场景

某三方物流公司，调度员发现某条线路的承运商报价比上周涨了 8%，他想快点批掉，不然这车货今晚就发不出去。

他找到运营主管，主管说"这种事我批不了，你去问经理"，经理正在开会。一来一回，两小时过去了，货还在停车场。

这不是个例。这是大多数运输团队在调价审批上的缩影：流程写了，但没人知道流程在哪；制度有了，但没人遵守制度。 系统上了 TMS，审批却还是靠腿、靠嘴、靠人情。

---

二、问题出在哪

2.1 没有金额分层

很多系统里的运费调整审批是"一刀切"——无论调 50 块还是调 5000 块，都走同一套流程。

结果：

• 小调整走大流程： 效率损耗，一票 200 块的调价要走三个审批节点，等批完货已经晚了
• 大调整走小流程： 权限失控，本该总监批的单被主管直接放行

金额分层是审批流设计的原点，不是岗位名称。

2.2 审批责任链断裂

实际场景中，调价申请往往是谁找到谁批，或者谁权力大谁批。没有预设的链路，也没有强制传递机制。

结果：

• 主管批了本该经理批的单
• 经理不知道手下已经批了
• 调完价，结算模块用的还是旧费率

系统建了，流程没建。

2.3 无审计轨迹

调价记录只有结果，没有过程。查账的时候只知道"调了"，查不到"谁批的、为什么批、当时系统里是什么状态"。

结算时发现差异，对不上账，业务说"当时口头确认过"，财务说"系统里没有记录"。

---

三、解决方案：分层责任链审批

3.1 责任链模式的核心逻辑

参考责任链模式（Chain of Responsibility），将审批流建模为一条链路：

请求发起 → 节点A（运营主管） → 节点B（运营经理） → 节点C（运营总监） → 结束

每个节点只处理自己职责范围内的请求，超出范围自动传递给下一节点。任何节点可以选择通过或拒绝，拒绝即终止链路。

关键设计：申请人不决定走哪个节点，系统根据金额阈值自动匹配链路。

3.2 金额分层：审批链路的起点

建议分为三级，这是最常用、最易落地的分层方式：

等级	调整幅度	审批节点	响应时效
L1	±5% 以内	运营主管	2 小时
L2	±5%~15%	运营经理	4 小时
L3	±15% 以上	运营总监	8 小时

三个设计要点：

第一，阈值由系统自动判定，申请人不能自选等级。 申请时填写调价幅度，系统自动判断进入哪条链路。如果申请人故意低报，系统记录本次申请金额，并在审批时比对最新承运商报价，超阈值自动升级。

第二，调整幅度按单次、线路、周期分别计算，不混用。 不能把本月的调价累计到某一单来降低幅度占比，也不能把同一线路的多笔调价拆开申请。系统要能识别"同一线路 + 近 N 天"的时间窗口。

第三，L3 单据必须附带调价原因说明。 15% 以上的调整不是日常操作，必须有业务背景记录。预设原因选项包括：油费联动、市场行情、承运商变更、客户要求、其他。

3.3 节点处理器：每个节点的决策逻辑

每个审批节点本质上是一个处理器（Handler），它只做两件事：

1. 金额是否在自己的处理范围内？ 是则处理，否侧传递给下一节点
2. 是否存在阻断条件？ 存在则拒绝

处理器示例逻辑：

Handler A（主管层）:
  if 调整幅度 ≤ 5%:
    process() → 通过
  else:
    pass to Handler B（经理层）

Handler B（经理层）:
  if 调整幅度 ≤ 15%:
    process() → 通过
  else:
    pass to Handler C（总监层）

实际落地有两个模式：

• 中断模式（推荐）： 节点拒绝则链路终止。适用于权限分层场景，权限边界清晰。
• 非中断模式： 所有节点都收到通知并处理。适用于需要多方知会的场景，L3 单据可在主链路之外增加抄送通知。

大多数 TMS 场景建议用中断模式为主，L3 增加抄送通知告知相关方。

3.4 与费率模块联动：审批通过后的闭环

审批通过后，费率变更必须同步写回 TMS 费率引擎，不能由人工手动操作。

这条链路断开了，调价就是假的。

结算模块下次计费时直接从费率引擎读取最新费率，而不是去翻历史调价记录。如果费率引擎拿到的价格和申请单不一致，系统自动触发比对异常，提醒相关方核查。

调价审批 → 费率写入 → 结算生效 → 全程可追溯，这才是一个完整的闭环。

---

四、落地关键检查点

4.1 链路可配置

不同线路、不同客户、不同业务时段可以配置不同的审批链路。不是所有人走同一个流程，而是规则匹配链路。

例如：

• 直营线路 → L1/L2 两级审批
• 外包线路 → L1/L2/L3 三级审批
• 月结客户高价值线路 → L3 必须，附带客户知情确认

配置界面建议支持：线路标识 × 客户类型 × 调整幅度 → 自动匹配审批链路。

4.2 超时未审批自动上报

L1 单据 2 小时内无审批动作，系统自动升级至 L2 节点。L2 同理。

超时升级触发通知，包括：申请人、当前节点、已等待时长、超时原因（系统判断）。

4.3 完整操作日志

每次审批动作（通过/拒绝/转交/超时升级）必须记录：

• 操作人
• 操作时间（精确到分钟）
• 操作时的金额与调整幅度
• 系统状态快照（当时的承运商报价、当前生效费率、申请时间）

这是审计的基础，也是结算争议时的凭证。

日志只增不改，任何覆盖或删除操作需要单独权限并留下痕迹。

4.4 拒绝原因必填

L2、L3 审批拒绝时，必须选择预设原因或填写自定义说明。不允许"驳回但不说明"。

预设原因选项建议包含：金额超出授权范围、调整依据不充分、承运商历史违约记录、线路状态异常、其他。

---

五、总结

运费调整审批的核心矛盾不是"批不批"，而是谁来批、凭什么、限多久。

责任链模式解决这个问题的方式是：把审批权按金额分层，让请求在预设链路上自动流转，每一节点只处理自己该处理的，超出范围就向上传递，不越权、不推诿、可追溯。

上了 TMS 却还在用"谁找到谁批"的方式处理运费调整，等于系统建了，流程没建。

TMS 的价值不只是记录和追踪，而是把业务规则翻译成系统逻辑，让规则被执行、让过程可追溯、让责任落在具体的节点上。

---

责任链审批解决的是：调价有边界、权限有层级、过程有记录、结算有依据。

---

CTA

如果你在设计或优化 TMS 调价审批流程，建议先梳理当前审批节点、金额分层、超时机制和日志完整性四个维度，先找到链路断点，再确定系统改造优先级。

如果准备继续往下推进，建议把当前调价场景、金额分布、审批节点、结算口径或系统截图一起带上，这样更容易判断问题卡在链路设计、权限配置还是系统联动。

如果项目还在早期，也可以先从金额分层、链路匹配、时效控制三个方向做最小闭环，先让 L1/L2 单据跑通，再逐步覆盖 L3。

更稳的推进方式通常不是一上来全量改造，而是先挑调价频率最高、结算影响最大、历史争议最多的线路做试点，拿到第一轮稳定证据后再扩范围。

先把链路画清楚、把阈值定清楚，再推进系统落地，后面的改造成本和协同成本会低很多。

企微联系：系统规划 / 内容合作 / 业务沟通