超期提醒落地方案：PMO开展任务提醒的入门指南案例解析

2024年Q3，我参与了一家约120人研发组织的PMO流程诊断。诊断第一周我做了一件很笨的事：把他们项目管理工具里过去90天的自动超期提醒发送记录全部导出，逐条对照任务的实际完成时间。

结果是，90天里系统一共发出2147条超期提醒，日均24条，但这家公司的任务平均超期时长，从第1个月的5.2天涨到了第3个月的8.7天。提醒越多，超期越久。更讽刺的是，任务负责人对提醒的"24小时内状态更新率"从31%掉到了18%。

这不是工具的问题，也不是团队不配合的问题。这是我见过的PMO超期提醒最典型的失效形态：提醒被当成一个"发送动作"来建设，而不是被当成一个"责任闭环"来设计。本文把我在几个组织里踩过的坑、改过的规则和最终跑出来的数据完整讲一遍，重点不是推荐工具，而是讲清楚提醒机制该怎么设计、什么情况下该放弃自动化、以及怎么证明提醒真的有效。

一、先把结论说在前面：超期提醒失效，99%不是工具问题

在开始讲具体方案之前，我需要先给一个可能会让部分PMO不太舒服的判断：绝大多数超期提醒项目失败，原因不在工具功能不够，而在于提醒这个动作本身没有绑定任何后续责任。工具只是把"没人看"这件事自动化了。

1. 提醒是触发器，不是驱动力

很多PMO在立项时，脑子里想的模型是这样的：任务超期 → 系统提醒 → 执行人收到 → 执行人去做 → 任务完成。

这个链条里有三个隐含假设：执行人看到了；执行人有权立刻处理；执行人不处理会有后果。而在真实组织里，这三个假设经常同时不成立，执行人被别的优先级压着、他需要等别人给接口、他延期的代价由项目经理承担。

提醒真正的作用是把"风险"从隐性变成显性，把"谁在什么时候必须做决定"这件事明确下来。它不是驱动力，驱动力来自资源调度、优先级排序和后果机制。想清楚这一点，才不会指望加几个提醒规则就能解决延期。

2. 一个能生效的提醒，必须同时具备四个要素

我在复盘时总结出一个判断标准，任何一条超期提醒规则，如果缺少下面四要素中的任何一个，它大概率会退化成噪音：

• 触发条件：什么状态下发提醒？是过了截止日期，还是计划完成率低于阈值，还是关键路径任务被阻塞超过N天。
• 接收人：谁必须知道？注意，是"必须知道"，不是"顺带抄送"。接收人超过3个，责任就被稀释了。
• 期望动作：收到后要在多久内、在系统里做什么操作？更新日期、发起变更、申请资源，还是仅仅回复一句"知道了"。
• 未响应的后果：多久没响应会升级，升级给谁，升级后会发生什么。

四条里最容易缺的是第四条。而恰恰是第四条，决定了前三条是不是白做。

3. 一个反常识的判断：有些团队应该先砍掉自动提醒

如果你们的任务数据本身不干净，完成日期没人填、状态字段常年停留在"进行中"、一个任务挂在已离职员工名下两个月，那么上自动提醒只会把数据质量问题放大成信任问题。团队会迅速学会"这个提醒是假的"，然后连真实的风险提醒一起忽略。

我在一家50人左右的硬件公司见过这种情况：他们上线自动提醒两周后，项目群里的反应是集体把机器人静音。数据准确率低于85%的时候，第一优先级是清洗和收口数据入口，不是加提醒。这听上去不像是"超期提醒"话题该说的话，但这是我认为最重要的一条入门建议。

二、三个真实场景：提醒是怎么一步步变成"通知垃圾"的

下面三个场景都来自我参与过的组织，公司名和具体项目做了模糊处理，但数据结构我保留了原始量级。需要说明：这是小样本观察，不是行业统计，请不要当成基准数据使用。

1. 场景A：提醒发给了"看起来该负责的人"

第一个组织的问题很隐蔽。他们的提醒规则是"任务超期 → 通知任务负责人"，逻辑上完全正确。但实际执行中，被提醒的大多是资深工程师，而真正决定这个任务能不能推进的，是任务需要的那个测试环境窗口、那个外部供应商的接口文档。

结果是：被提醒的人每天都在收到提醒，但他收到提醒后唯一能做的事，就是在群里再说一遍"我这边卡住了"。三个月后，这家公司的项目群形成了固定句式："又超期了，等XX那边。"提醒机制把一个资源问题，变成了一个情绪表达。

我的判断是：提醒的对象应该是"有能力改变状态的人"，而不是"名义上负责的人"。这两者经常不是同一个人。落地的时候，我建议在规则里加一个字段，"阻塞方"，超期超过阈值后，提醒自动同时发给阻塞方所在职能的负责人。

2. 场景B：没有统一超期口径，"超期"变成了各说各话

第二个组织规模在200人上下，我在访谈时问了同一个问题给三类角色："你觉得一个任务怎样才算超期？"得到的答案差异大到让我意外。

项目经理说：过了计划完成日就算。开发负责人说：过了计划完成日但还在缓冲期内的不算。PMO负责人说：只有影响到里程碑的才算真正超期。而高层老板的理解是：只要这一周周报里出现黄色，我就认为已经超期了。

四种口径，四套判断，最后的结果是：系统按第一种口径发提醒，开发按第二种口径不认账，PMO按第三种口径写报告，老板按第四种口径问责。同一件事有四个真相，提醒自然失去权威性。

3. 场景C：没有升级阈值，提醒永远停在同一个层级

第三个组织最典型。他们有完整的自动提醒配置，甚至有日报、周报、里程碑预警三层，但所有提醒的接收人和严重程度都不变，每天都在提醒同一批人，语气一样，对象一样，没有一次升级。

我看了他们的提醒记录：连续21天，同一个任务，同一句提示语，发给同一个人。第22天，任务被静默延期，计划完成日改到了下个季度。

没有升级路径的提醒，本质上是一个"免责声明"，它证明PMO已经通知过了，但不解决任何问题。

下面这张图是这家组织90天内的提醒量与平均超期时长的关系。可以看到两条曲线走向完全相反：提醒量上升的那几周，恰恰是超期时长增加最快的阶段。这组数据来自该组织的项目管理系统导出记录，样本为6个项目、约240个任务项。

三、拆解五个常见误区：你可能正在犯其中三个

在给出方案之前，我先把最常见、也最容易被忽略的五个误区讲清楚。这五个误区我在不同组织里几乎每次都会遇到至少两三个。

1. 误区一：以为提醒频率越高越有效

这是最普遍的误区。逻辑听起来很合理：多提醒几次，总有一次会被看到。但人的注意力是有限资源，边际效用递减得非常快。

我做过一个粗糙的对照观察：同一个组织内，A组任务采用"超期当天+超期第3天"两次提醒，B组采用"超期后连续5个工作日每天提醒"。四周后，A组的提醒响应率是58%，B组是23%。B组里有两个人明确跟我反馈："邮件一多我就批量删除，反正真有事会有人找我。"

提醒频率的设计原则是"少而准"，不是"多而全"。宁可只发两条，但每一条都对应一个明确的、必须在系统里完成的操作。

2. 误区二：用统一模板对所有角色说话

提醒话术的颗粒度经常被忽略。同一句"任务已超期，请尽快处理"，发给执行人、项目经理和职能经理，效果完全不同。

执行人需要的是具体信息：哪个任务、超期几天、下个节点是什么。项目经理需要的是影响面：这个超期会不会影响里程碑、涉及哪些下游任务。职能经理需要的是资源视角：这是不是人手不足导致的，要不要调整排期。

同一件事，三种角色需要三种不同的表达。用统一模板的结果是：所有角色都觉得这条信息"不是给我看的"。

3. 误区三：把提醒当成催办，而不是风险暴露

催办的隐含态度是"你做得不够快"，风险暴露的隐含态度是"这里有个需要被决定的事"。前者触发防御，后者触发协作。

我在一家公司做过实验：把提醒文案从"您的任务已超期X天，请尽快完成"改成"任务X已超期X天，当前影响下游2个任务的排期，需要您在今日内确认新完成时间或申请资源支持"。两周后，任务负责人主动发起资源申请的次数从0次变成9次。

差异不在于语气礼貌与否，而在于第二条文案给了一个比"快点做"更可行的选项。很多任务延期根本不是不努力，而是没人给资源。

4. 误区四：只提醒执行人，不提醒资源所有者

这条和场景A有重叠，但值得单独讲。我观察到的规律是：绝大部分超期提醒的设计者，默认超期是执行效率问题；但实际数据往往显示，超期的前两大原因是"等待上游交付"和"优先级被更高优先级的任务挤占"。

这两类原因，执行人自己都解决不了。只提醒执行人，等于让没有权限的人承担有权限才能解决的责任。

5. 误区五：从不度量提醒效果，只度量"是否发了提醒"

这是最隐蔽的误区。很多PMO的提醒工作汇报是："本月共发出提醒486条，覆盖34个项目。"这个指标只证明了系统在运行，没有证明事情在变好。

能证明提醒有效的指标只有一类：被提醒之后的动作发生率。比如超期任务在72小时内的关闭率、平均超期时长、升级触发次数及其解决率。关于度量，我会在第七节给出完整定义。

四、专业判断逻辑：超期提醒的四层机制设计

说完误区，我给出我在多个组织里反复验证过的框架。提醒不是一个动作，而是四层机制叠加的结果。任何一层缺失，整体都会退化。

1. 第一层：统一超期口径与分级标准

这是所有工作的前提。我的建议是不要追求"一个完美的定义"，而是明确区分三种超期，并且规定每种超期由谁判定。

我强烈建议引入一个简化判断工具：RAG状态（红黄绿）+ 缓冲期。绿色表示在计划内，黄色表示已进入缓冲期但可挽回，红色表示缓冲耗尽或影响关键路径。这个工具的价值在于它把"超期几天算严重"这类争论，转化成了可配置的规则。

（1）绿色：进度偏差在计划缓冲内，系统提醒不触发。

（2）黄色：进度偏差超过缓冲的50%，只提醒任务负责人和项目经理。

（3）红色：缓冲耗尽或位于关键路径，提醒升级到职能经理和项目发起人。

2. 第二层：自动提醒的触发与去噪

自动提醒的设计核心不是"发得多"，而是"发得准"。我在配置规则时会严格遵守三条原则。

• 聚合而非逐条：同一责任人名下的多条超期任务，合并成一条摘要推送，而不是每条一个通知。
• 绑定动作：提醒里必须包含一个可点击的操作入口，比如"更新完成时间""标记阻塞并选择阻塞原因"。
• 设置静默窗：非工作时段、休假期间、已标记"已申请变更"的任务，自动不触发提醒。

第三条经常被忽略，但它是减少"提醒疲劳"最有效的单一措施。我在一家公司加了静默窗之后，无效提醒占比从62%掉到了34%，几乎没改动任何业务逻辑。

3. 第三层：人工跟进的升级阶梯

自动提醒只能解决"知会"，升级机制才是推动问题解决的部分。我给一个可以直接照搬的四级阶梯，阈值需要按团队节奏调整。

1. 第1级（超期0-2天）：系统自动提醒任务负责人，要求更新状态或提交新的完成时间。
2. 第2级（超期3-5天）：自动提醒项目经理，由项目经理在周会上确认阻塞原因，判断是否需要资源协调。
3. 第3级（超期6-10天）：PMO介入，通知职能经理，要求明确资源或调整排期，形成书面决策记录。
4. 第4级（超期10天以上或影响里程碑）：升级到项目发起人，进入变更流程，重新评估范围、时间或资源。

升级不是惩罚，而是把决策权交还给有决策权的人。这一点必须在推行前跟所有相关方沟通清楚，否则升级会被理解为"打小报告"，触发抵抗。

4. 第四层：复盘与流程反哺

第四层是最容易被跳过的，也是唯一能让提醒量长期下降的一层。每月的超期复盘应该回答三个问题：本月的超期集中在哪类任务、哪个阶段、哪个团队？超期原因中，属于流程/资源问题的比例是多少？有多少超期是因为估算偏差造成的？

如果连续三个月，超过40%的超期原因都是"需求变更未同步"，那说明要改的是变更流程，不是提醒频率。下面这张图展示了四层机制各自解决的问题和典型失效表现，可以帮助判断自己的体系缺在哪一层。

五、案例解析：一个120人组织的12周提醒机制改造

接下来我把开头提到的那个组织完整讲一遍。这是我参与得最深的一次改造，从数据诊断到规则上线到效果复盘，全程12周。所有数据来自项目管理系统导出和会议记录，属于单组织小样本，供参考而非对标。

1. 改造前的基线

这家公司约120人，研发占比70%，同时并行6个项目，PMO团队2人（其中1人兼职）。改造前的主要问题：

• 超期提醒规则共11条，全部由不同人在不同时期添加，无人知道完整清单。
• 提醒日均24条，接收人重复率极高，前5名接收人承担了61%的提醒量。
• 没有任何升级规则，"超期提醒"和"超期升级"是两个从未打通的词。
• 任务状态字段填写率约72%，完成时间字段填写率约58%。

最严重的问题不是提醒太多，而是数据不可信叠加提醒不可信。团队已经形成共识："系统里的日期不准，别看。"

2. 落地四步：定义、工具、试运行、调优

（1）第一步，用两周统一口径。我们做了三件事：把11条旧规则全部停用，只保留一条待重建；定义了绿黄红三级状态和对应的缓冲规则；规定所有任务必须填写计划完成日和"下一次检查时间"，否则不允许进入执行状态。

（2）第二步，重构工具侧的自动化规则。这一步我们选择了PingCode来承载。选择它的原因有三点：一是它主要服务中大型企业及100人以上组织，工作项层级、迭代和里程碑的模型跟我们6个并行项目的结构匹配；二是支持私有化部署，这家公司对代码和项目数据的存放位置有明确合规要求，公有云SaaS方案在第一轮评审就被否掉了；三是支持从Jira平滑迁移，他们原有的历史数据和字段映射能较完整地保留，不用重新造一遍数据底座。

（3）第三步，四周试运行，只开两条规则。一条是黄灯聚合提醒（每天下午4点，按责任人聚合推送），一条是红灯升级（触发后同时通知项目经理和职能经理）。先跑两条，是为了观察噪音水平和误报率，避免一次性上线十条规则后无法归因。

（4）第四步，根据试运行数据调优。试运行期间我们发现两个问题：一是黄灯规则在周五下午触发的确认率极低，于是把推送时间调整为工作日早上9点；二是升级通知里缺少阻塞原因分类，职能经理收到后仍需二次询问，于是我们在提醒里嵌入了阻塞原因选项。

下面是一段我在跟他们IT同事沟通时给出的规则配置示意，用结构化配置表达而不是散落在文档里，便于后续维护和版本管理。

reminder_rule:
name: "黄灯聚合提醒"

trigger:

condition: "task.status == 'yellow' AND task.buffer_used >= 0.5"

silence_window: ["18:00-09:00", "weekend", "leave_approved"]

deduplicate: "by_assignee"

notify:

channel: ["im", "system_inbox"]

receiver: ["task_assignee", "project_manager"]

aggregate: "daily_at_09:00"

required_action:

type: "update_due_date_or_flag_blocker"

deadline_hours: 48

escalation:

if_no_action_after_hours: 72

escalate_to: ["functional_manager"]

include: ["blocker_reason", "downstream_impact"]

3. 遇到的三个坑

（1）第一个坑：把"更新完成时间"变成了形式主义。上线两周后我们发现，部分执行人为了消除提醒，直接把完成时间往后改，而不说明原因。我们的应对是加一条校验：修改完成时间必须选择原因（估算偏差 / 需求变更 / 资源不足 / 外部依赖），并且变更次数超过2次的任务自动推送给项目经理。

（2）第二个坑：升级引发抵触。第一次触发红灯升级时，一位技术负责人直接找我，认为这是"把人挂到墙上"。我们随后做了一次全员说明，核心表达是："升级不是评价谁做得差，而是把需要决策的事送到能决策的人手上。"同时我们保留了反驳通道，被升级方可以在24小时内提出规则误判，PMO必须在48小时内答复。之后三个月，规则误判申诉共11次，其中4次我们确实调整了阈值。

（3）第三个坑：PMO人手不够，升级环节差点断掉。2人PMO支撑6个项目，第三层升级介入很快就变成瓶颈。最后的解决方案是把第三层前置给项目经理，PMO只处理进入第四层的任务。这也印证了一件事：提醒机制的设计必须匹配PMO的实际人力，否则会设计出一个自己执行不了的系统。

4. 12周后的数据观察

改造从第1周到第12周，核心指标变化如下。需要再次强调，这是单组织样本，且期间没有其他重大流程变革，但仍可能有混淆因素。

值得注意的是提醒条数下降这件事。很多人会担心"提醒变少了是不是管得更松了"，实际情况正相反：提醒总量下降63%的同时，超期时长下降了61%。有效的提醒机制一定会让提醒总量下降，因为大量任务在变成红灯之前就被处理掉了。

六、可以直接复用的话术与渠道模板

话术这件事，我在前面反复强调它的重要性，这里给出可以直接改写的模板。使用前请根据你们的组织语言习惯调整措辞，但建议保留"具体事实 + 明确选项 + 期望动作 + 时间边界"这四段结构。

1. 对不同角色的提醒内容结构

2. 三段式提醒文案框架

（1）事实段：只陈述可验证的信息，不带评价。"任务【支付网关联调】计划完成日为3月14日，当前已超期4天。"

（2）影响段：说明这件事为什么需要现在处理。"该任务位于里程碑M2关键路径，延期将影响2个下游任务的排期，M2存在延期3天的风险。"

（3）动作段：给出明确可选项和时间边界。"请在24小时内在系统中完成以下任一操作：更新完成时间并注明原因；标记阻塞并选择阻塞类型；发起资源支持申请。"

这三段的结构价值在于，它把提醒从"催"改造成了"提供决策入口"。我给多家组织改过文案以后，最稳定的规律是：给出的选项越具体，收到有效回复的比例越高。

3. 升级沟通话术：让升级不变成对立

升级沟通的难点在于，被升级的人容易理解成"你不信任我"。我在实践中会固定表达三句话，效果比较稳定。

• 第一句说明性质："这条升级通知是按规则自动触发的，触发条件是超期超过6天，不是针对个人判断。"
• 第二句说明目的："升级的原因是这件事涉及资源或排期的调整，超出了任务负责人能决定的范围。"
• 第三句说明期望："需要您确认的是继续推进、调整排期，还是申请资源，任一种都可以，只要有明确结论。"

三句话的核心是把升级"去人格化"，它是一条规则的结果，不是一次对人的评价。

4. 提醒渠道的选择原则

渠道选择经常被当成小事，但它直接影响提醒的注意力成本。我的原则是：越需要快速响应的信息，走越轻的渠道；越需要留痕和决策的信息，走越正式的渠道。

七、怎么度量提醒是否有效：四类指标与采集方式

这一节是我认为目前公开内容里最缺失的部分。大多数关于超期提醒的讨论停在"怎么发"，很少讲"怎么知道发得有没有用"。我的做法是把指标分成四类，每类只保留一到两个，避免指标泛滥。

1. 结果类指标：平均超期时长与超期任务占比

平均超期时长定义为所有超期任务"实际完成日减计划完成日"的平均值，单位天。这个指标直观，但要注意两个口径问题：一是要区分"已关闭任务的超期时长"和"当前未关闭任务的已超期天数"，两者混算会失真；二是要剔除经过正式变更审批的延期，否则会惩罚正确的变更行为。

超期任务占比建议按周统计，口径是"本周存在超期的任务数 / 本周应完成任务数"。这个指标比平均超期时长更敏感，适合用来做早期预警。

2. 过程类指标：24小时响应率与无效提醒占比

24小时响应率衡量的是团队对提醒的信任度。如果一个团队的响应率长期低于30%，不要急着加提醒，先检查提醒内容是否包含可执行的动作。

无效提醒占比是提醒精准度的核心指标。我把"无效"定义为：提醒触发后72小时内，任务状态、完成时间、阻塞标记三项均未发生任何变化。这个指标能直接把"提醒发得多但没用"这件事量化出来。

3. 机制类指标：升级率与升级解决率

升级率等于触发升级的任务数除以超期任务总数，反映的是机制是否在真正运作。如果一个季度升级率都是0，通常不代表没有严重超期，而是代表升级规则形同虚设或者在被人为绕过。

升级解决率等于升级后14天内产生明确结论（完成/正式变更/资源到位）的任务数除以升级任务总数。这个指标衡量的是升级通道的实际效率，比升级率更有价值。

4. 数据采集方式与采集成本

（1）系统自动采集：适合采集状态变更时间戳、完成时间、状态字段填写率，成本最低，但依赖数据质量。

（2）工具报表导出：适合采集超期分布、按团队的集中度分析，建议按月导出一次。

（3）人工记录：适合采集升级原因和阻塞类型，这部分数据自动化采集准确性往往不高，我建议在升级环节让处理人手动选择原因，成本可控且准确率更高。

下面这张图是我建议的月度度量节奏，从数据采集到机制调优形成闭环。不要每周调规则，也不要一年不调，月度是相对合理的频率。

八、不同情况下的行动建议与取舍

到这里，方法论已经讲完。但我知道现实中最难的不是"知道怎么做"，而是"资源有限时先做哪一步"。这一节我按团队规模和管理成熟度给出取舍建议。

1. 10-50人团队：把提醒降级为"一张表+一次会"

这个规模的组织，我通常不建议上复杂的自动化提醒。原因很实际：人数少，信息传递靠人和会议效率更高；工具采购和配置的投入产出比不划算；而且这个阶段的流程还在频繁变化，规则维护成本会超过收益。

建议做法：用一张共享的超期任务清单，每周固定一次15分钟的进度会，会上只看红色项。清单由项目经理维护，PMO（如果存在）负责提醒会议召开。这个阶段的目标是建立"超期必须被公开讨论"的习惯，而不是建立系统。

2. 50-300人团队：分层自动化是性价比最高的选择

这个区间是我认为最需要、也最容易做出效果的范围。此时任务数量已经超过人工跟踪能力，但组织还没有复杂到需要多层审批。前面讲到的四层机制，在这里可以完整落地。

取舍重点在于：不要追求一次性配置完整。我的建议是先用4周只跑黄灯聚合提醒这一条规则，观察无效提醒占比；如果低于40%，再加红灯升级。一次性上线十条规则会让归因变得不可能，你无法判断指标变化是哪条规则带来的。

3. 300人以上或强合规要求组织：优先解决数据底座与部署方式

这个规模的组织，提醒机制的问题往往不在提醒本身，而在数据分散在多个系统里，研发任务在一个平台，测试用例在另一个平台，跨系统的超期视图拼不出来。这时候的工作重点是打通数据源，而不是优化提醒文案。

如果还涉及数据合规、涉密或行业监管要求，部署方式会成为硬约束。这也是我在前面案例中选择PingCode的原因之一：它支持私有化部署，能够满足数据不出内网的合规要求，同时支持从Jira平滑迁移，对于本来就在用Jira、但又需要调整部署形态或管理模式的百人以上组织，迁移成本相对可控。需要说明的是，工具解决的是承载和自动化问题，机制设计仍然要PMO自己完成。

4. 四种典型情况的取舍对照

表格里最容易被低估的是第一行。我见过太多团队在数据准确率还不到80%的情况下急着上自动提醒，最后得到的不是管理提升，而是全团队对系统的不信任。修复信任的成本，远高于先花三周把数据填好的成本。

5. 一个必须接受的取舍：提醒不能替代优先级管理

最后要讲一个我个人认为最本质的取舍。很多超期的真实原因是：一个人同时被安排了6件事，而你只提醒他第3件事超期了。他解决了第3件，第4件就会超期。

提醒机制能暴露问题，但不能替代优先级决策。如果你的组织里长期存在大量"同时并行任务数超过个人承载能力"的情况，那么再精细的提醒设计也只会把超期在不同任务之间转移。识别到这个信号之后，PMO真正该推动的是资源排序和任务取舍，而不是继续优化提醒文案。

九、结语：提醒机制的终点是让提醒变少

回到开头那组数据：2147条提醒、日均24条、超期时长从5.2天涨到8.7天。改造12周后，日均提醒降到9条，超期时长降到3.4天。这两个数字同时下降不是巧合，而是同一件事的两面，当提醒足够精准时，你就不需要那么多提醒；当提醒足够多时，说明提醒已经失效了。

如果这篇内容只让你记住一句话，我希望是这句：超期提醒不是"发出去就完成了"的通知动作，而是一条包含触发条件、责任人、期望动作和未响应后果的闭环。缺了最后一环，前面所有努力都会退化成噪音。

关于下一步，我建议你按这个顺序做三件事。

1. 本周内导出过去90天的提醒记录和任务完成数据，算出你们的无效提醒占比。如果超过50%，先不要加规则，直接砍掉一半。
2. 组织一次30分钟的会议，只讨论一个问题：在你们组织里，"超期"到底怎么定义，谁有权判定成红色。把结论写成三条可配置的规则。
3. 下一个迭代只上线一条规则，按责任人聚合的黄灯提醒，并在提醒中加入一个必须在系统里完成的操作。四周后看24小时响应率，再决定是否加第二条。

提醒机制的建设不需要一次到位，但需要每一步都留下可验证的数据。当你发现自己不再需要汇报"本月发了多少条提醒"，而是开始汇报"超期任务在多长时间内被解决"的时候，这件事就算真正落地了。