合同签完就压箱底，等到对方延期、验收卡住、付款对不上才发现问题——这是合同管理员最常见的卡点。这篇不聊法律条文，只讲怎么把履约过程拆成能看的指标、怎么设预警线、预警之后谁去处理，给一份可以照着搭的监测框架。
合同签完塞进档案柜，等到对方延期、验收卡住、付款对不上才被业务部门找上门，这是合同管理员最常挨的一刀。问题不在合同法条，而在于履约过程根本没被拆成能看的指标，也没人规定预警之后谁来接。下面这套框架不聊司法解释，只讲三件事：盯哪些合同、看哪些数、预警响了谁负责。
搭这套东西不需要先买系统。先用一张固定字段的台账跑一两个月，字段稳定、责任人对上号了，再考虑往协作工具或合同管理系统上搬。监测本身是管理动作，工具只是载体。
先定监测对象：哪些合同值得盯，哪些不用盯
最容易犯的错是把所有合同一股脑塞进监测台账，结果字段越加越多，没人维护，最后变成一份三个月没更新的死表。正确的做法是先分层：高风险合同进高频监测，低风险合同按季度抽查。分层不是拍脑袋，按下面几个维度打分就行。
| 分层维度 | 高关注（进高频监测） | 低关注（季度抽查） |
|---|---|---|
| 金额规模 | 占部门预算比例高、单笔影响大 | 零星、单次、影响可控 |
| 履约周期 | 跨多期交付、周期拉长 | 一次性、短周期完成 |
| 可替代性 | 对方难以替换、切换成本高 | 市场上同类供应商多 |
| 历史表现 | 有过延期、验收争议或沟通不畅 | 历次合作干净利落 |
| 义务清晰度 | 有明确数量、日期、交付标准 | 条款模糊、全靠口头确认 |
除了分层，还要圈出四类关键节点：交付、验收、付款、续约或到期。绝大多数履约风险都在这四个位置暴露，节点之外的日常沟通不必逐条记录，否则台账会被噪音淹没。
履约监测指标清单：每个节点看什么
指标不在多，在于口径统一。同一个「逾期天数」，有人按合同约定日算，有人按实际到账日算，月底一对账就全乱套。每个指标在台账里都要写清计算口径，并且口径一旦定下就不要再随手改。
- 交付类指标
- 计划交付日、实际进度百分比、延期天数、对方在本期提出的变更次数
- 验收类指标
- 验收发起时间、验收意见轮次、当前卡在哪个部门、遗留问题条数
- 付款类指标
- 应收应付日期、已开票金额占合同额的比例、逾期账龄分档
- 关系类指标
- 对方对接人是否变动、平均响应时长、有无单方面提出条件调整
关系类指标最容易被忽略，但它往往是最早的预警信号。对接人频繁更换、响应时间明显拉长、对方开始反复提条件调整，这些还没到违约程度，但已经说明履约意愿在变化，值得提前跟进。
- 每个指标标注计算口径，写在台账表头或字段说明里
- 口徑涉及金额或比例的，一律到 /price-watch 核对当时的数字，不凭印象填
- 同一合同同时命中两个以上关注级指标时，自动往上升一级
- 指标空缺不等于正常，没人填的字段要标成待确认，而不是当成通过
预警机制怎么设：分级、触发条件与响应动作
预警不是把风险都堆给合同管理员，而是让每条预警都有归属、有时限、有下一步。分三级就好，级别太多没人记得住。触发条件必须写成能直接判断的规则，不能写成「感觉不太对」这种描述。
- 提醒级临近关键节点前触发，动作是发一条进度确认给业务对接人，要求在约定工作日内回话。这类预警不需要升级，闭环就是收到确认。
- 关注级节点已过但影响还可控，比如交付延期但未影响后续验收。动作是合同管理员牵头拉一次沟通，记录对方给出的新时间点并落到台账。
- 升级级已影响后续节点或涉及金额较大。动作是同时通知业务负责人，按事先写好的路径判断是否交法务，管理员不单独扛。
升级路径要提前写死并且让业务部门知道，比如「影响下一付款节点即同步业务负责人」「连续两个节点未闭环即交法务评估」。路径写在纸上、发在群里，比临时找人有效得多。
把监测跑起来的日常动作与工具
监测能不能活下来，取决于节奏和字段固定不固定。节奏建议两条线：周会过一遍新增和未闭合的预警，月度过一遍存量合同的健康度。周会解决「现在谁在等谁」，月度解决「哪些合同正在变差」。
- 台账固定字段：合同编号、对方名称、关键节点、当前状态、责任人、最近一次跟进记录
- 每次跟进只写事实和时间点，不写情绪判断，方便交接和回溯
- 定期拿台账与业务部门的实际进度对一次账，口径差异当场记录下来
- 跑通之后再评估要不要上系统，字段没稳定就上系统只会把混乱搬进软件
工具选型时可以先去 /tools/speed-test 之类站内工具页看看分类思路，再决定是自己搭表格还是接现成协作工具。判断标准很简单：责任人和提醒能不能自动落到人，不能就还是表格更快。
什么情况下这套监测不适用
这套框架不是万能的，硬套反而增加维护成本。以下几种情况要先换思路，而不是硬做指标。
- 长期稳定合作、按框架协议滚动下单的，逐份监测意义不大，改成按季度复盘框架执行情况
- 合同条款模糊、没有可量化义务的，先补条款或补附件，再谈监测
- 业务量小、管理员兼职的团队，优先只做关键节点提醒，不做全量指标
- 一次性、货到付款、金额极小的零星采购，进台账的收益低于维护成本
反过来，如果一份合同同时满足金额大、周期长、对方难替换、历史上有过摩擦，那它就应该被放进高频监测，哪怕管理成本高一点也值得。判断的标准始终是风险敞口，不是合同数量。
合同管理的价值不在签得快，而在履约过程中每一次该响的预警都真的响了。下一步想先看看别人是怎么把合同节点和提醒接到工具里的，可以翻一翻站内工具目录里的协作与合同分类，挑一两个对照自己团队的台账字段再决定要不要搬。→
常见问题
合同履约风险监测和合同审查是什么关系？
审查管的是签之前条款写得对不对、风险敞口在哪；监测管的是签之后对方和自己有没有按约定走。两者用的信息不一样，审查结论可以当监测的起点，但监测要另建一套节点和台账，不能拿审查清单代替。
预警线怎么定才不会天天报警？
先跑一两个周期，把实际发生的延期、卡点天数记下来，再反过来定缓冲期；初期宁可少设几条只盯关键节点，报警太多会被忽略。另外要区分「对方晚了」和「我方流程慢了」，后者不该算对方风险。
没有专职合同管理员的小团队怎么做？
只保留一张表，字段压到最少的几列：合同编号、关键日期、责任人、状态。每天或每周花十几分钟扫一遍临近节点的合同，靠日历提醒代替系统预警，等合同量上来再补分级规则。
