任务提醒如何做好催办？PMO落地方案与操作步骤

2023年我接手一个制造业集团的PMO，负责ERP上线的项目管控。上线节点前两周，186项任务里有71项逾期，我拉了一份清单，用邮件群发了一遍提醒，措辞客气、格式工整，抄送了所有部门负责人。第二天早上我打开邮箱，只收到9封回复，其中4封是"收到"，真正推进了任务的只有3项。第三天我换了个做法，不再群发，而是按责任层级分别处理，一周内逾期项从71降到14。

这件事让我彻底改变了做催办的方式。催办失败的原因，几乎从来不是"提醒没送到"，而是"压力没有传导到该承担后果的人身上"。任务提醒只是入口，催办是一套组织机制，两者之间隔着一整套权责设计、升级规则和记录闭环。这篇文章不讲工具测评，只讲PMO怎么把这套机制搭起来，以及我实际操作中踩过的坑。

一、先给结论：催办是压力传导机制，不是通知服务

在我服务的组织里，PMO做催办最容易犯的方向性错误，是把催办理解成"信息触达工作"，只要提醒发出去了，责任就在执行方。这个假设在跨部门项目里几乎必然失效，因为执行方的优先级排序和项目方的优先级排序，天然不一致。

1. 催办的本质是把后果提前搬到台面上

一个人愿意在周五下班前赶完一份报告，通常不是因为他收到了第三次提醒，而是因为他知道这份报告下周一要在经营会上被提及，或者知道逾期会被记录进部门的过程考核。催办真正起作用的部分，是后果的可见性和确定性，而不是提醒的次数。

沿着这个逻辑往下推，PMO催办机制要解决三个问题：后果由谁承担、什么时候暴露、暴露给谁看。回答清楚这三个问题，提醒用什么渠道、发几次，反而是最不重要的一环。

2. 有效催办机制由四层构成

我把实践中的催办拆成四层，每一层的触发条件、执行主体和压力强度都不同。第一层是系统自动提醒，解决"信息到达"；第二层是PMO定向催办，解决"确认接收"；第三层是管理层升级催办，解决"优先级让位"；第四层是结果通报，解决"后果兑现"。

这四层不是并列关系，而是递进关系。跳过某一层直接升级，会让PMO在组织里迅速失去信誉；停在前两层不做升级，催办就会退化成无效的日常骚扰。

3. PMO在催办中只做三件事

很多PMO把自己做成了人工催办员，每天在群里@人、发私信、打电话，忙到飞起但效果一般。PMO在催办机制里的正确角色是规则设计者、异常升级者和数据记录者，不是执行施压者。

规则设计者，负责定义什么时间点提醒谁、什么条件下升级到哪一级。异常升级者，负责处理系统规则覆盖不了的例外情况。数据记录者，负责让每一次催办和响应都留下痕迹，成为后续复盘和考核的依据。这三件事做完，日常催办工作量的八成都可以交给规则和工具。

二、背景与真实场景：为什么提醒发了，任务还是不动

要理解催办为什么难，得先看几个具体的组织场景。这些场景我在不同项目里反复遇到，它们的共同点是：任务提醒系统运行正常，但任务依然逾期。

1. 一个ERP上线项目的催办现场

前面提到的那个制造集团项目，涉及12个部门、186项任务，包括数据迁移、接口联调、用户权限梳理、操作手册编写等。项目初期我们建了任务台账，每项任务都有责任人和截止时间，也在协同工具里配了到期提醒。

问题出在第二阶段。数据迁移任务的责任人是IT部门的一位工程师，但他的直属上级给他在同一周期内排了另一个优先级更高的系统巡检任务。他每天收到系统提醒，也知道截止时间，但他做出的选择是合理的，在他的考核体系里，系统巡检的权重远高于协助PMO做数据迁移。

这不是态度问题，是优先级冲突。当一个人面对两个冲突的任务时，他会本能地服从那个"不做会有明确后果"的任务，而不是那个"提醒发得最勤"的任务。

2. 提醒系统上线后逾期率反而上升的两种情况

我见过两个组织在部署任务提醒功能后，逾期率短期上升。第一种情况是提醒让逾期变得"可见"了，原本靠人情模糊处理的逾期项被系统标红，数字自然变难看。第二种情况更值得警惕：提醒让执行人产生了"任务已经被跟踪，不需要我主动汇报"的心理，反而减少了主动沟通。

第二种情况在跨部门协作里尤其明显。执行人觉得提醒是PMO的事，PMO觉得执行人收到提醒就该动，双方都在等对方先动，任务就卡在中间。打破这个僵局的唯一办法，是把"确认接收"设成提醒链路里的一个必须动作，而不是可选项。

3. 中大型组织的催办复杂度和百人以下团队完全不同

一百人以下的团队，PMO通常能记住每个人的工作状态，催办靠口头沟通和固定站会就能覆盖。超过一百人、尤其是多事业部或多地域的中大型组织，PMO不可能掌握每个执行人的真实优先级，这时候催办必须依赖规则化、层级化和可追溯的机制。

这也是为什么在中大型组织里，选一套支持私有化部署、支持复杂审批和升级规则配置的项目管理平台，会比依赖通用IM工具重要得多。PingCode主要服务中大型企业及100人以上组织，支持私有化部署，支持Jira平滑迁移，是国产替代中比较常见的选择。我们在那个制造集团项目里用的就是它，后面会讲具体怎么配。

三、拆解常见误区：我们踩过的五个坑

这一节里的每一条，都是我或者我带的PMO真实踩过的。写出来不是为了自嘲，而是因为这些坑太容易重复踩，而且踩的时候往往不自知。

1. 误区一：把提醒次数当成催办强度

最常见的做法是"提醒不够就多发几次"，到期前三天发一次、当天发一次、逾期后再发一次，甚至设置每天提醒。结果是执行人对提醒脱敏，重要的和次要的任务提醒被一视同仁地忽略。

我在一个项目里做过统计，同一任务在逾期后一天内连发三次提醒，响应率是27%；改成逾期后只发一次、但明确写出逾期后果和升级时间点，响应率是61%。提醒的价值取决于信息含量和后果明确度，不取决于次数。

2. 误区二：PMO亲自当催办员

PMO同事跟我说过一句话："我一天要发40条催办消息，发完自己都不知道哪条重要。"这是典型的角色错位。PMO亲自催办，短期看响应快，长期看制造了两个问题：一是催办强度完全依赖PMO个人的体力和关系，不可持续；二是把本该由管理层承担的压力转移到了PMO身上，PMO成了矛盾的吸收层。

正确的做法是把PMO的催办动作限制在"异常处理"范围内。常规逾期由系统规则推动，PMO只在规则失效时介入，介入时也不是自己去压，而是推动对应层级的管理者去压。

3. 误区三：没有验收标准的任务也去催

有些任务在创建时就没写清楚交付物是什么、什么样算完成。这种任务一旦逾期，催办就变成了一场扯皮，执行人说"我做了"，PMO说"这不是我要的"。

我的经验是，催办动作应当前移到任务创建环节。没有明确交付物、没有验收标准的任务，不应该进入催办链路，而应该先退回给任务发起人重新定义。这一步看似降低了任务数量，实际上大幅降低了催办的无效劳动。

4. 误区四：只催执行人，不催责任人

很多组织的任务台账里，只有一个"执行人"字段。但真正决定任务能否完成的人，往往是对资源有调配权的责任人。执行人卡住，通常不是因为不努力，而是因为他调不动需要的资源。

我们的整改做法是在任务台账里加一列"责任管理者"，逾期升级时直接触达这一层。催办要找的是那个能让优先级让位的人，而不是那个被优先级压住的人。

5. 误区五：催办过程不留痕，复盘时全是记忆

催办记录的价值在项目后期才显现。当项目延期需要归因时，如果拿不出"某任务在什么时间点被提醒、被催办、被升级、响应情况如何"的记录，复盘就只能变成互相甩锅。

我们从第三个项目开始强制要求：所有催办动作必须在系统里留痕，包括催办时间、催办人、催办渠道、对方响应。记录本身就是一种压力，因为它让"我没看到"这个借口不再成立。

四、专业判断逻辑：催办机制的三根支柱

把上面这些坑反过来看，能催得动的任务都满足了三个条件：任务可催、催办有授权、催办有回路。这三条构不成，机制就立不起来。

1. 可催性判断：任务必须具备三个要素

我给自己定了一个硬标准，只有同时满足三个要素的任务才会进入催办链路。第一，责任人唯一且明确，不接受"某某团队负责"这种写法；第二，截止时间精确到日，不接受"近期""尽快"；第三，交付物可验收，能说清楚什么样算完成。

三个要素缺一，任务就先退回。这个动作在项目启动阶段做，能挡掉大约两成的无效催办。下表是我们实际使用的可催性检查清单。

2. 催办授权：PMO的权力从哪里来

PMO本身通常没有行政权力，催办权必须从组织的正式授权中来。授权的具体形式，一般是一份项目管理制度或者项目管理办法，里面要写清楚三件事：PMO有权向谁发起催办、逾期任务的处理流程是什么、什么条件下可以升级到经营会。

没有这份授权的PMO，催办只能靠"求人办事"的方式推进，效果完全取决于个人关系。我见过做得最好的一个PMO，它的催办权写在集团项目管理办法第三章，明确规定逾期超过五个工作日的任务自动进入分管副总周报，PMO不需要任何额外审批就能触发这个动作。

3. 反馈回路：让每一次催办都产生记录

反馈回路的完整链条是：催办发出→对方响应→响应记录→逾期统计→通报或考核。任何一个环节断掉，催办就变成一次性动作，不会积累压力。

要让回路真正转起来，关键在响应记录的强制化。我们在系统里把催办消息设成"需要确认"，对方必须填写预计完成时间才能关闭，否则任务状态一直挂在"待响应"。这个小小的交互改动，让催办响应率从不到四成提升到了八成以上。

4. 升级阈值：什么条件下必须升级

升级规则如果靠PMO临时判断，就会出现"关系好的人不升级、关系差的人频繁升级"的偏差。正确做法是把升级阈值写死成规则，由系统自动判断和触发。

我们使用的升级规则是三级制：逾期1-2个工作日，PMO定向催办；逾期3-5个工作日，触达责任管理者；逾期超过5个工作日，进入项目周报并通报至分管领导。规则一旦确立，PMO不再有自由裁量权，这也保护了PMO，不是我要升级你，是规则触发的。

五、案例与数据观察：186项任务的催办链路重构

回到开头那个制造集团的ERP项目。这里我把具体做法和数据展开讲，因为细节比结论更有参考价值。

1. 案例背景与初始状态

项目涉及12个部门、186项任务，计划周期16周。初始状态下，任务提醒配置在协同工具的默认模板里，到期前1天提醒执行人，逾期后每2天提醒一次，只提醒执行人，不通知任何人，没有升级规则。

上线前两周的统计是：71项逾期，逾期率38.2%，平均逾期时长5.4个工作日，最高的单项逾期19个工作日。PMO团队2人，每天花在催办上的时间合计约5小时。

2. 用PingCode重构催办链路的四个关键配置

我们当时选PingCode有两个现实原因：一是集团要求私有化部署，数据不能出内网；二是项目组此前用Jira，有大量历史任务和字段配置需要迁移，PingCode支持Jira平滑迁移，这部分历史数据我们两周内完成了迁移和字段映射，没有影响项目节奏。

具体做法分四步。第一步是把任务台账重新清洗，补齐责任管理者和验收标准字段，清洗后186项任务中有31项因为缺验收标准被退回重新定义，最终进入催办链路的任务从186项调整为169项。

第二步是配置三层提醒规则：到期前2天提醒执行人，逾期当天提醒执行人和责任管理者，逾期第3个工作日提醒责任管理者并抄送部门负责人。提醒全部走系统内消息加企业IM双通道。

第三步是配置升级规则，用自动化规则实现状态流转。下面是我们实际使用的规则配置示意：

任务逾期规则配置（示意）
触发条件: 任务状态 != 已完成 且 当前日期 > 截止日期

├─ 逾期 0 天

│ ├─ 通知: 执行人（企业IM + 系统内消息）

│ └─ 要求动作: 填写预计完成时间，否则状态保持"待响应"

├─ 逾期 2 天

│ ├─ 通知: 执行人 + 责任管理者

│ └─ 标记: 任务标签增加 "逾期预警"

├─ 逾期 3 天

│ ├─ 通知: 责任管理者 + 部门负责人

│ └─ 动作: 自动写入项目周报逾期清单

└─ 逾期 5 天

├─ 通知: 分管副总 + PMO负责人

└─ 动作: 进入月度过程考核记录

第四步是把催办响应强制化。所有催办消息设为需确认，对方必须填写预计完成时间或说明阻塞原因才能关闭消息。这一步是整个改造里阻力最大的，因为有人觉得"被要求填表很烦"，但也是效果最明显的。

3. 上线六周后的数据变化

改造上线后第六周，我们做了第一次完整统计。逾期率从38.2%降到7.1%，平均逾期时长从5.4个工作日降到1.8个工作日，PMO每天花在催办上的时间从5小时降到1.5小时左右。

更有价值的是一个过程指标：催办响应率，也就是催办发出后24小时内对方给出明确回复的比例，从33%提升到84%。这个指标比逾期率更早反映机制是否有效。

4. 一个反直觉的发现：催办频率下降后完成率提升

改造后我们做了一件和直觉相反的事：主动减少了提醒频率。逾期后的提醒从每2天一次改成只在逾期当天和第3天各一次，其余时间不再自动提醒。

结果逾期率继续下降。原因是多方面的，但最关键的一点是：当提醒变得稀缺且后果明确时，接收方才会真正处理它。高频提醒训练的是忽略能力，低频高信息量的提醒训练的是响应能力。

这个发现后来被我们固化进规则里：任何一项任务的自动提醒，全周期不超过4次。超过4次还催不动的任务，问题不在提醒，在任务本身或者责任机制，需要转入人工升级流程处理。

六、操作步骤：PMO落地催办机制的六个动作

这一节把前面的逻辑落成可照着做的步骤。顺序很重要，跳过前面的步骤直接做后面的，大概率会返工。

1. 第一步：梳理任务台账，标注催办等级

先把当前项目所有在途任务拉成一张台账，至少包含责任管理者、责任人、截止日期、交付物、验收标准、当前状态六个字段。然后逐项做可催性检查，不合格的退回重定义。

接着按任务对项目关键路径的影响程度标注催办等级，我通常分三级：A级影响上线或验收节点，B级影响其他任务的开始时间，C级不影响关键路径。A级任务的提醒和升级阈值要比C级提前一到两个工作日。

2. 第二步：设定时间规则与升级规则

时间规则要回答三个问题：到期前多久提醒、逾期后多久提醒、提醒几次。我的建议是到期前2天一次、逾期当天一次、逾期第3天一次，之后不再自动提醒，转入人工处理。

升级规则要回答：什么条件下通知谁。这里不要设计得太复杂，三级就够用。关键在于规则一旦确定就写进系统，不留给PMO临时判断的空间。

3. 第三步：配置工具提醒链路

工具配置的重点不是功能多，而是链路完整。需要确认的是：提醒是否同时到达执行人和责任管理者、催办消息是否强制要求响应、逾期状态是否会自动汇总到某一处可视视图。

如果项目涉及数据不能出内网，或者需要用Jira历史数据，选型时要把私有化部署和迁移能力放在前面。中大型组织的另一个实际约束是任务量级，几千项任务的视图加载速度和规则触发延迟，会在日常使用中被放大成很大的体验问题。

4. 第四步：执行日常催办节奏

日常节奏建议固定成两个动作：每天早上花15分钟看逾期看板，确认系统规则是否正常触发；每周五下午做一次逾期汇总，把本周进入升级流程的任务整理成清单，发给相关责任管理者。

这里要克制的是不要顺手去私信催办。系统已经催过的任务，PMO重复催一遍，等于告诉执行人系统提醒可以忽略，会削弱规则的权威性。

5. 第五步：处理异常与升级

PMO真正需要投入精力的只有异常情况，主要是三类：对方不响应催办、对方响应了但给不出完成时间、任务实际已阻塞但没有人上报。

这三类都按同一个原则处理：不在执行层纠缠，直接触达责任管理者，并且附上完整的催办记录。记录是PMO最有力的工具，它能避免沟通变成各说各话。

6. 第六步：复盘与规则迭代

每个月做一次催办复盘，看三个数据：逾期率、催办响应率、进入升级流程的任务占比。逾期率反映结果，响应率反映过程，升级占比反映的是规则是否过松或过紧。

升级占比长期低于5%，通常说明规则太软；高于25%，说明任务定义或资源配置有问题，催办在替管理问题背锅。健康区间大概在8%到15%之间。

七、催办话术模板：四段式，可直接复用

话术在催办里的作用被高估也被低估。话术本身不会让人改变优先级，但话术能决定对方是"配合你处理"还是"防着你处理"。下面四段话术是我们反复调整后沉淀下来的版本，重点在于结构而非措辞。

1. 首次提醒话术

首次提醒的目标是信息同步，不是施压。结构是：任务信息 + 当前状态 + 需要对方确认的动作。语气保持中性，不带有任何暗示对方拖延的表述。

示例："X老师，数据迁移模块第三批任务计划本周五完成，目前系统状态是进行中。麻烦你确认一下是否需要调整时间，如果时间没问题，麻烦在系统里更新一下进度。"

（1）使用场景

适用于到期前的自动提醒和PMO第一次人工触达。此时对方尚未逾期，任何施压表述都会显得多余甚至冒犯。

（2）常见错误

首次提醒就抄送上级，是最容易破坏关系的一个动作。除非任务属于A级且时间已经很紧，否则不要在第一次触达时就扩大知悉范围。

2. 逾期催办话术

逾期催办的核心是让后果变得具体。结构是：逾期事实 + 影响说明 + 明确的回复要求。注意是说影响，不是指责个人。

示例："X老师，数据迁移第三批任务已逾期2个工作日，这项任务目前影响接口联调的开始时间，联调原计划下周一启动。麻烦你今天下班前回复一个预计完成时间，我好判断是否需要调整后续排期。"

（1）使用场景

逾期1-2个工作日内使用，由PMO定向发出，不抄送上级。重点是给出一个明确的、当天可以完成的回复动作。

（2）常见错误

把"影响说明"写成情绪表达，比如"你这样会拖累整个项目"。前者是事实，后者是评判，效果差别很大。

3. 升级催办话术

升级催办由PMO发给责任管理者，而不是发给执行人。结构是：逾期记录 + 已尝试的沟通 + 需要管理者做的事。这一段的关键是把PMO定位成信息提供者，把决策权交给管理者。

示例："X总，数据迁移第三批任务由X同事负责，已逾期4个工作日。我们在逾期当天和第3个工作日分别做过两次催办，目前还没有拿到预计完成时间。这项任务影响接口联调启动，需要你帮忙协调一下优先级。相关催办记录我整理在附件里。"

（1）使用场景

逾期3-5个工作日，且PMO定向催办后仍未获得明确响应时使用。附上催办记录是这段话术的关键，它让升级变成基于事实的流程动作，而不是告状。

（2）常见错误

升级时只说问题不说已做的努力，管理者会觉得PMO在推卸责任。把"我们做过什么"讲清楚，升级才站得住。

4. 向领导汇报催办结果的话术

向分管领导汇报时，重点不是催了谁，而是整体趋势和需要决策的事项。结构是：整体数据 + 异常项分布 + 需要决策的具体事项。

示例："本周169项在途任务中逾期12项，逾期率7.1%，比上周下降1.8个百分点。逾期集中在数据迁移和权限梳理两类，共占9项。其中3项已经逾期超过5个工作日，进入升级流程，需要你帮忙明确一下这两个模块的优先级是否要调整。其余9项已确认预计完成时间。"

（1）使用场景

周报、月度项目例会或专项汇报。这段话术的目的是让领导用最少的时间拿到做决策需要的信息，而不是听催办过程。

（2）常见错误

把汇报做成诉苦，讲太多沟通细节和人际摩擦。领导需要的是数据、异常和需要他拍板的事。

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

催办机制没有通用最优解，取决于组织成熟度、项目类型和PMO自身的授权程度。这一节按几种典型情况分别给建议和取舍。

1. 组织成熟度低：先做人工催办，不要急着上工具

如果组织里连一份正式的项目管理办法都没有，任务台账都是Excel表格，那么直接上工具配置自动化规则，大概率会失败。因为规则触发了也没人认，升级了也没人在意，工具会变成又一个被闲置的系统。

这种阶段的正确顺序是先做制度建设：明确PMO的催办权、明确逾期的处理流程、明确向谁升级。制度落地后再配工具，工具才有承接的土壤。取舍点在于：制度建设见效慢但不可跳过，工具建设见效快但需要制度支撑。

2. 组织成熟度中等：工具自动化 + 人工升级

这是大多数中大型组织的实际状态。项目管理制度有，但执行弹性大；任务台账规范，但催办靠人。这种情况下最优组合是"前两层自动化、后两层人工化"。

系统自动提醒和PMO定向催办交给规则和工具，升级和通报由PMO人工判断和推动。这个组合的取舍点在于：自动化部分可以立刻见效，人工部分需要PMO投入精力维护关系，两者不能互相替代。

3. 组织成熟度较高：规则驱动 + 数据通报

如果组织已经有成熟的项目考核体系，催办可以进一步交给规则。逾期数据自动进入部门过程考核，PMO只负责维护规则和解释数据，不再承担施压职责。

这种模式的好处是PMO从矛盾中心解脱出来，代价是PMO对例外情况的处理空间变小。取舍点在于：机制的确定性提升了，但需要接受个别合理逾期也会被记录进考核。

4. 跨部门项目的取舍：催办强度和关系成本

跨部门项目里，PMO和业务部门没有直接管理关系。催办每提升一个强度，都会带来关系成本。这不是要回避，而是要有意识地控制节奏。

我的做法是把关系成本花在真正关键的任务上。A级任务该升级就升级，哪怕得罪人；C级任务逾期一两天，PMO可以选择先私下沟通，不走升级流程。一刀切的强硬和一刀切的软弱，都会让催办机制失去可信度。

5. 工具选型的取舍：能力优先还是易用优先

百人以下团队，我建议优先考虑易用性，因为规则简单，用不着复杂配置。中大型组织则要把能力放在前面，重点是三个：能不能配复杂升级规则、能不能自动留痕、能不能支持私有化部署。

PingCode在这三点上比较契合中大型企业的需求，尤其是私有化部署和Jira平滑迁移这两项，对已经用惯Jira、又要满足内网要求的组织来说，切换成本会低很多。这也是国产替代场景下比较常见的方案。取舍点在于：功能强的平台配置成本高，需要有人专门负责维护；功能简单的平台维护成本低，但规则复杂后会被迫回到人工催办。

九、常见问题与避坑指南

这一节收几个PMO最常问的问题，每个问题给一到两条可操作的建议，不讲道理。

1. 催办变成得罪人怎么办

得罪人的根源通常是催办动作看起来像个人行为，而不是机制行为。解决办法是把催办固定成规则触发的动作，PMO只做传达和记录。开口时用"系统触发的逾期清单"而不是"我来催一下"，性质完全不同。

另一个技巧是催办时永远附上时间线和记录，让对方知道这是有据可查的流程，而不是PMO今天心情不好。

2. 领导不配合催办怎么办

领导不配合通常有两种情况：一种是他不认为这事重要，另一种是他不想为下属的逾期背书。对第一种，要用影响说话，把逾期对上线节点、对其他部门的具体影响算出来；对第二种，给他一个不需要直接出面就能施压的工具，比如自动生成的部门逾期周报。

3. 跨部门任务催不动怎么办

跨部门催不动，九成情况是任务的重要性没有被对方部门的管理者认可。这时候继续催执行人是无效的，应该把力气花在把任务写进对方的部门目标，或者找到双方管理者的共同上级。

4. 工具提醒发了但没人看怎么办

先确认两件事：提醒是不是发到了对方真正在用的渠道，提醒内容里有没有明确的行动要求。很多提醒只写了"任务即将到期"，没写"你需要做什么"，对方看完不知道要干什么，自然会忽略。

5. 逾期数据不好看，要不要调整统计口径

不建议。逾期率难看说明机制在暴露真实问题，这正是它存在的意义。调口径只是把问题藏起来，等到项目延期时一次性爆发，代价更大。

结语：催办的终点是让催办变得不必要

做PMO这几年，我最大的体会是：催办做得好的标志，不是催得有多勤，而是催得越来越少但任务照样完成。前期的高强度升级，目的是把规则立起来，让所有人知道逾期会有确定的后果；规则一旦立住，日常催办就该逐步退到后台。

如果要把这篇文章压缩成一句话，就是：催办的本质不是提醒人，而是让任务的后果变得确定、可见、可追溯。提醒只是把后果提前告诉对方，升级是让后果真实发生，留痕是让后果可以被追溯。

下一步你可以做的事有三件，按顺序来。第一件，把当前在途任务拉出来做一次可催性检查，把缺责任人、缺验收标准的任务挑出来退回重定义，这一步通常能挡掉两成无效催办。第二件，把升级规则写成一页纸，找项目发起人确认授权，明确什么条件下升级到哪一级。第三件，选一个业务高峰期做两周试运行，用逾期率和催办响应率两个指标验证效果，再决定是否固化进制度。

不要一次把所有规则都建起来，也不要指望上线工具就解决问题。催办机制是长出来的，不是装出来的。