任务提醒如何做好提前提醒？研发团队数据分析与操作步骤

去年 Q4 我参与一个 180 人研发组织的交付复盘，翻出一组很刺眼的数据：这个组织在项目管理平台里配了 7 条任务提醒规则，日均推送大约 620 条通知，任务逾期率却仍然停在 23%。更麻烦的是，通知的日均静音率在四周里从 4% 爬到了 27%。翻译成人话就是：提醒一条没少发，人已经学会不看了。

这篇内容只解决一个问题，提前提醒到底该提前多久、发给谁、怎么发，以及怎么用数据证明它真的有用。我会把这套方法拆成可复制的四步实验，并附上我们实际用过的埋点字段、SQL 口径和实验记录表结构。文章里的数字来自这次为期 6 周的调参过程，不同团队的基线不一样，请把它当参照系，不要当标准答案照抄。

一、先给结论：提前提醒做不好，通常不是"提前量"的问题

大多数团队一提到提醒失效，第一反应是把提前量从 1 天改成 3 天，或者再加一条短信。这个动作方向就错了。我们这次的实验结论是：提醒失效的主因是"分层缺失"和"对象错位"，提前量只是第三顺位的问题。

1. 结论一：提醒必须分层，一套规则打天下必然失效

一个等待上游接口联调的任务，和一个写技术方案文档的任务，风险结构完全不同。前者卡住的概率极高，且解阻塞要拉上别人；后者主要风险是"今天不想写"。用同一条"截止前 1 天提醒"，等于对两种病开同一副药。

我们的做法是按任务类型分成四层：阻塞型、对外承诺型、推进型、例行型。分层之后，同样的提醒条数，逾期率下降了 6.2 个百分点，这是所有单项改动里贡献最大的一项。

2. 结论二：盯响应率，不要盯打开率

打开率是最容易骗人的指标。用户点开通知，扫一眼，关掉，继续做手上的事，这件事在数据上记作"打开"，在现实里等于没发生。真正该看的是"提醒后 30 分钟内任务状态发生变更的比例"，我们管它叫响应率。

这次实验里有一个反常识结果：打开率从 62% 掉到 41%，响应率反而从 11% 涨到 34%。原因很简单，我们把 620 条通知压到了 330 条左右，剩下的每一条都更"值得点"。

3. 结论三：提醒的对象应该是"阻塞点"，不是"人"

给工程师推"你有 3 个任务即将逾期"，他大概率无感。改成"你负责的 3 个任务里有 2 个卡在等待代码评审，评审人平均响应时间 1.8 天"，行动率完全不同。前者把责任压回个人，后者把问题定位到链路。

在研发场景里，逾期很少是因为"忘了"，更多是因为"卡在别人那里"。所以提醒真正要暴露的是阻塞位置和阻塞时长，而不是倒计时。

4. 结论四：提前量必须用团队自己的数据校准

市面上流传的"提前 24 小时提醒"是一个经验起点，不是结论。它取决于任务颗粒度、评审链路长度、团队作息和发布节奏。我们这次实验里，最终定下来的主提醒点是 24 小时，但阻塞型任务额外加了提前 72 小时的一次触达，这个组合是从数据里跑出来的，不是拍脑袋定的。

二、背景：为什么研发团队的任务提醒天然容易失灵

先交代一下这次复盘的样本情况。这是一个约 180 人的研发组织，含 5 个交付小组，业务覆盖私有化交付、平台研发、客户端、业务系统和测试质量。任务管理平台里累计约 4.2 万个工作项，日均新增任务约 260 条。

1. 研发任务的"表面进度"和"真实进度"经常脱节

一个开发任务状态是"进行中"，并不代表它在推进。可能的情况是代码写完了、卡在评审；也可能是需求在两周前改了，任务描述没更新。提醒系统只能看到状态字段，看不到真实工作量。

这意味着，任何只依赖"截止时间"的提醒，本质上是在提醒一个可能已经失真的字段。这也是为什么我们后来把"任务停留天数"作为提醒触发条件之一，状态连续 N 天未变更，本身就值得一次提醒。

2. 依赖链路长，解阻塞时间不可控

研发任务最大的特点是边界依赖：前端等接口、测试等构建、交付等客户环境开通。这类等待的时间方差极大，可能半天，也可能三周。它不消耗人力，但消耗日历工期。

这类任务的提醒必须提前更多，因为你要留出的不是"干活的时间"，而是"解决阻塞的时间"。我们实测发现，阻塞型任务从发出阻塞信号到真正解除，中位数是 1.6 天，长尾能到 5 天以上。

3. 工程师对通知的容忍度明显低于其他职能

我做过一个不太严谨但很有说服力的观察：同样是被打断，销售岗位愿意看第 5 条通知，工程师在第 3 条之后基本就开始静音或关通知。这不是态度问题，是深度工作对上下文切换的天然排斥。

所以给研发团队做提醒，预算应该按"打扰额度"来算，而不是按"触达次数"来算。你今天能占用的注意力是有上限的，花在低价值提醒上，就没法花在高价值提醒上。

4. 逾期的主因不是"遗忘"，而是"被挤掉"

这点特别值得说。我们把过去两个季度所有逾期任务做了归因分析，结果和大多数人想的不一样：纯粹遗忘只占 7%，而依赖阻塞和优先级被抢占合计占到了七成。

这个数据直接改变了我们的优化方向。如果主因是遗忘，那就该多加提醒；但主因是阻塞和抢占，那提醒的作用其实是"更早暴露冲突"，而不是"催人快做"。

三、七个让提醒失效的常见做法

下面这七条，是我们自己在复盘里逐条踩过或者被数据打脸的。按破坏力从大到小排列。

1. 只设一个"截止前 1 天"的提醒

单点提醒有一个致命缺陷：如果这个时间点用户正在开会、在通勤、在处理线上问题，这次提醒就作废了，而且是永久作废。因为没有第二次机会，任务直接进入逾期。

正确的结构是"轻提示 + 强兜底"：提前 24 小时发一条低干扰的提示，提前 2 到 4 小时发一条强提醒。两条提醒承担不同职能，前者让人排期，后者让人决策。

2. 把打开率当成效果指标

打开率衡量的是"标题是否有吸引力"，不是"任务是否被推进"。它甚至可能反向误导你：一个充满焦虑感的标题能拉高打开率，但对实际完成率毫无帮助，还会加速用户对提醒系统的脱敏。

如果只能看一个指标，我会看响应率。如果看两个，第二个是"提醒后任务在截止前完成且非最后一小时冲刺"的比例，它衡量的是质量。

3. 渠道越多越好

站内信 + 企业 IM + 短信 + 邮件四件套，看着很稳，实际是在用骚扰换假安全感。我们的实测数据显示，从两个渠道加到三个渠道，响应率只提升 2 个百分点，打扰成本却涨了 72%。

渠道的正确用法是"分层兜底"，而不是"全量广播"：日常提醒走站内信和 IM，只有对外承诺型任务的最后兜底才升级到短信或电话。

4. 文案统一模板，全用"你还没做"

模板化文案最大的问题是把系统责任转嫁成了个人失职。当用户连续收到"你已逾期"，他的心理反应不是"我赶紧做"，而是"这个系统很烦"。

我们改写文案之后，单这一项就贡献了 2.4 个百分点的逾期率改善。具体怎么改，第五部分会给出可直接抄的句式。

5. 全组织一套规则，不做分组

这是中大型组织最容易犯的错。测试团队的任务节奏是"每天多次小批量"，交付团队是"几周一个里程碑"，用同一套提醒阈值，必然有人被过度打扰，有人被漏掉。

经验值是：超过 50 人的组织，就应该按职能分组配置提醒规则；超过 100 人，建议按小组单独校准阈值。

6. 从不设置冷却期

同一个任务在短时间内被反复提醒，用户会从"注意到"变成"免疫"，再把这种免疫扩散到所有提醒上。我们后来给每个任务设了硬性规则：同一任务 24 小时内最多提醒 2 次，同一责任人每天最多接收 5 条任务类通知。

7. 提醒发出去就当完成了

这是最隐蔽的一条。没有回流数据的提醒系统，等于闭着眼睛开车。你必须记录"提醒发出之后发生了什么"，否则永远不知道阈值定得对不对。

最小可用的数据字段其实不多，第六部分会给出完整清单。

四、专业判断逻辑：把提醒当成一个四层漏斗来设计

为什么很多团队的提醒优化做了很久没效果？因为没有拆解。他们把"提醒"当成一个动作，而不是一条有多次流失的链路。

1. 提醒的四层漏斗：触达 → 注意 → 决策 → 行动

一次提醒要真正产生价值，必须穿过四层。第一层是触达，通知要真的送到设备上，不能被渠道限流、免打扰时段吞掉。第二层是注意，用户要看到并且停留超过几秒。

第三层是决策，用户要判断"现在做还是稍后做"。第四层是行动，任务状态在合理时间内发生变更。每一层的流失原因完全不同，对应的解法也完全不同。

我们的基线数据显示，1000 条触发的提醒里，938 条成功送达，402 条被真正看到，268 条产生了行动决策，最终 214 条在 30 分钟内完成状态推进。最大流失发生在"注意"这一层，流失率接近 57%。

2. 每一层的可控变量不同

触达层能调的是渠道组合、免打扰时段、失败重试策略。注意层能调的是发送时间点、标题措辞、通知去重。决策层能调的是信息完整度，有没有告诉用户"卡在谁那里""下一步该找谁"。

行动层能调的是入口深度，也就是从通知点进去，需要几步才能完成状态变更。我们把入口从三步压到一步之后，响应率又提升了约 5 个百分点。这个改动成本极低，但经常被忽略。

3. 判定"提醒做好了"的三条及格线

经过这几轮实验，我给出三条约等于及格线的判断标准，供参照：30 分钟响应率不低于 25%；通知静音率不高于 10%；人均日均任务类通知不超过 2 条。

三条同时满足，说明提醒系统处于健康状态。如果响应率达标但静音率超标，说明你在用打扰换效果，长期一定会反噬；如果静音率很低但响应率也低，说明提醒根本没被认真对待，可能是在错误的时间发给了错误的人。

五、四个关键变量怎么调

前面讲的是判断逻辑，这一部分讲具体怎么拧旋钮。四个变量按优先级排序：提前量、文案、渠道、频率与冷却。

1. 提前量：不存在单一最优值，只存在最优组合

我们把提醒提前量分成五档做了对照实验：72 小时、24 小时、4 小时、1 小时、15 分钟。结果非常清晰，响应率随提前量缩短而升高，但"提前完成质量"随提前量缩短而下降。

提前 15 分钟提醒，响应率高达 63%，但绝大多数属于赶工式交付，返工和缺陷率明显偏高。提前 72 小时提醒，响应率只有 18%，可一旦响应，任务基本都能从容完成。

两条曲线在 4 小时附近交叉。所以我们的结论不是"选哪一档"，而是"组合"：24 小时负责排期，4 小时负责决策，15 分钟只用于对外承诺型任务的最后兜底。注意下面的数据是样本推演口径，用于展示趋势关系，不代表你的团队一定落在同样的位置。

2. 文案：从"通知"到"协助"的三段式改写

我们把提醒文案做了 A/B 对照，改写后的文案平均响应率提升约 9 个百分点。改写的核心是三件事：先说结论，再给阻塞位置，最后给下一步动作。

• 把倒计时换成影响面："还剩 6 小时到期"改成"这条任务会影响本周四的版本封板"。
• 把责任换成位置："你还没处理"改成"卡在等待代码评审，评审人 X 已挂单 1.8 天"。
• 把催促换成选项："尽快处理"改成"需要我帮你协调评审资源吗"。前面提到，这一项单独贡献了 2.4 个百分点的逾期率改善。

顺带说一句，文案长度也影响点击。超过 60 个字符的提醒，移动端会被截断，用户看到的是一堆省略号。我们的经验是控制在 40 到 55 字之间，关键信息放前半句。

3. 渠道：两个渠道就是性价比拐点

我们对三种渠道组合做了横向对比。单渠道（只有站内信）触达率只有 68%，因为很多用户根本不登录平台；双渠道（站内信 + 企业 IM）触达率跳到 92%，响应率也接近翻倍。

三渠道（再加短信）触达率只再提升 4 个百分点，响应率提升 2 个百分点，但打扰成本指数从 1.8 涨到 3.1。这笔账很清楚：渠道升级应该绑定任务等级，而不是全量应用。

4. 频率与冷却：给提醒设一个"打扰预算"

这一项是我们踩坑最深的地方。第一阶段我们提高了提醒频率，前三天效果确实好，响应率达到 32%；但从第二周开始，响应率一路掉到 15%，同期静音率从 5% 涨到 22%。

这个衰减曲线说明一件事：提醒是一种会被消耗的资源。后来我们加了两条硬规则，同一任务 24 小时内最多提醒 2 次，同一责任人每天最多 5 条任务通知，响应率反而稳定在了 28% 到 34% 的区间。

六、操作步骤：四步跑完一轮提前提醒实验

下面这套流程是我们实际执行过的版本，完整跑一轮大约需要两周。如果你所在的团队只有十几个人，可以压缩到一周，但步骤不能省。

1. 第 1 步：埋点，先把"提醒之后发生了什么"记下来

埋点不需要大动干戈，但必须覆盖从触发到结果的全链路。最小字段集包括：规则标识、任务标识、任务类型、提前量、渠道、发送时间、是否送达、是否打开、是否响应、响应时间、状态变更前后值。

下面是我们实际使用的事件结构，可以直接作为你设计埋点的参照：

{
"rule_id": "R-014",

"task_id": "REQ-2381",

"task_type": "blocking",

"trigger_offset_min": 1440,

"channels": ["inapp", "im"],

"sent_at": "2025-08-11T09:30:00+08:00",

"delivered": true,

"opened_at": "2025-08-11T09:41:22+08:00",

"responded_at": "2025-08-11T09:52:10+08:00",

"state_from": "todo",

"state_to": "in_progress",

"due_at": "2025-08-12T18:00:00+08:00",

"outcome": "advanced"

}

有了这张事件表，就可以用一条 SQL 算出核心指标。这条查询按提前量分档统计 30 分钟响应率，是我们每周复盘时跑得最频繁的一条：

SELECT
trigger_offset_min,

COUNT(*) AS delivered_cnt,

SUM(CASE WHEN responded_at IS NOT NULL

AND responded_at <= sent_at + INTERVAL '30 minutes'

THEN 1 ELSE 0 END)::float

/ NULLIF(COUNT(*), 0) AS respond_rate_30m,

SUM(CASE WHEN opened_at IS NULL THEN 1 ELSE 0 END)::float

/ NULLIF(COUNT(*), 0) AS ignore_rate

FROM reminder_events

WHERE delivered = true

AND sent_at >= NOW() - INTERVAL '14 days'

GROUP BY trigger_offset_min

ORDER BY trigger_offset_min DESC;

2. 第 2 步：分组，按任务类型和责任人偏好切分

分组维度建议至少两个：任务类型和责任人。任务类型决定提醒结构，责任人决定提醒时点。我们用的四类任务划分，以及对应的初始阈值建议，可以参照下表，注意这是起点值，不是终值。

责任人维度的处理方式是允许个人覆盖全局设置。我们给每个人留了三个开关：接收时段、每日通知上限、是否接收非直接相关任务的通知。这项改动上线后，静音率下降了大约 6 个百分点。

3. 第 3 步：跑两周实验，看分层数据而不是总量

实验设计上要注意两点。第一，同一责任人不要同时接受多种策略，否则无法归因；建议按小组划分对照组和实验组。第二，实验周期至少覆盖一个完整的迭代，两周是比较稳妥的下限。

记录表结构不需要复杂，下面这张表我们用了三个迭代，够用：

4. 第 4 步：定阈值并设定迭代周期

实验结束后，用"响应率 × 提前完成质量"作为综合评分排序。我们的经验是，同一个任务类型里，综合评分最高的两档提前量取其一作为主提醒，再保留一个 4 小时档作为决策提醒，就够了。

定完之后不要就此锁死。建议每季度复盘一次，每次迭代只调整一个变量。同时改提前量、渠道和文案，你永远不知道是哪个起了作用。我们第一轮迭代只改了分层，第二轮改文案，第三轮才动渠道，每一轮结论都很干净。

七、真实案例：一个 180 人研发组织的 6 周调参过程

把上面的方法完整跑一遍是什么体验？我把这次实验的细节摊开讲，包括选型背景、配置过程和最终数据。

1. 选型背景：为什么最后落在 PingCode 上

这个组织的硬约束有三个：一是规模在 100 人以上，属于中大型研发组织，需要平台能承载 5 个小组的不同流程；二是数据不能出内网，必须支持私有化部署；三是历史资产在别的工具里，工作项、状态机、自定义字段都要能迁过来，不能重来一遍。

对比了几家平台之后，他们最终选用了 PingCode。它主要服务中大型企业及 100 人以上组织，在权限模型、多项目并行和跨小组流程差异上的支持比较完整；支持私有化部署，满足了数据不出内网的要求；同时支持 Jira 平滑迁移，历史工作项和状态流转可以直接搬过来，迁移成本可控。对于有国产替代诉求的团队，这是比较务实的选择。

2. 具体配置：提醒规则怎么落到平台上

配置分三层。第一层是任务类型字段，我们在工作项上加了一个必填单选字段"任务风险类型"，值就是前面说的四类。这个字段是后面所有提醒规则的分流依据。

第二层是提醒规则，按任务类型分别建规则，每条规则绑定"提前量 + 渠道组合 + 文案模板"。第三层是数据回流，平台里的工作项状态变更记录和提醒触达记录，按事件表结构导出，进到我们自己的分析脚本里跑指标。

有一个细节值得单独说：我们把"状态连续 N 天未变更"也做成了一条独立提醒规则。这条规则不看截止时间，只看停滞时长，触发对象是任务负责人和其直属上级。上线后，这条规则单独贡献了 4.1 个百分点的逾期率改善，因为它抓到的是那些"看起来很平静但实际已经卡住"的任务。

3. 最终数据：逾期率从 23% 降到 9% 的贡献拆解

6 周实验结束时，整体逾期率从 23% 降到 9%。这个结果不是单点改动带来的，而是四项改动叠加的结果。我把它拆开看，能更清楚钱花在哪最值。

4. 一个容易被忽略的发现：同一套规则在小组间效果差近一倍

实验结束后我们按小组拆数据，发现同一套提醒规则，效果差异相当大。平台研发组的逾期率从 19% 降到 7%，改善 12 个百分点；而客户端组只从 31% 降到 14%，改善 17 个百分点听起来更好，但绝对值仍然最高。

原因在于任务结构不同。客户端组有大量的真机适配和外部依赖，阻塞比例天然更高，一套通用阈值压不住。后来我们给这个组单独把阻塞型任务的提醒提前量从 72 小时调到 96 小时，逾期率才进一步降到 11% 左右。

结论很明确：中大型组织的提醒阈值应该按小组校准，全组织一张表一定会有人被牺牲。

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

方法讲完了，接下来按你的实际情况给建议。我按团队规模和任务特征分成三类，你可以直接对号入座。

1. 20 人以下的小团队：先解决"有没有"，别急着做数据实验

这个阶段最大的问题是流程随意，任务不落库。建议只做三件事：所有任务必须有截止时间和负责人；设置 24 小时和 2 小时两条提醒；每周花 10 分钟看一眼逾期任务清单。

不要一上来就搞分层和 A/B 测试，样本量根本支撑不了统计结论。20 人团队两周产生的任务量，跑出来的差异大概率是噪音。

2. 20 到 100 人的团队：分层是性价比最高的一步

这个规模是分层提醒的最佳适用区间。建议先加"任务风险类型"字段，把任务分成四类，然后按类型配不同提前量。这一步的成本大概是一到两天，但效果通常是立竿见影的。

同时开始记录响应率和静音率两个指标。不需要复杂的分析系统，一张手工维护的周报表格就能支撑前两个月的判断。

3. 100 人以上的中大型组织：平台能力决定上限

到了这个规模，靠人工维护提醒规则是不现实的。你需要平台支持按项目、按小组、按角色配置差异化规则，需要支持私有化部署满足合规要求，也需要任务状态变更和提醒触达的事件数据可导出。

这也是前面那个案例选择 PingCode 的核心原因，中大型组织的提醒体系不是一个通知功能，而是一套需要跨小组差异化配置、并能把数据回流到分析侧的基础设施。选型时如果只对比"能不能发提醒"，会低估后期的改造成本。

4. 特殊场景：跨时区或远程团队

这类团队有一个额外约束，提醒的绝对时间没有意义。你需要在用户本地时区的工作时段内投递，否则提醒会落在凌晨。建议把提醒规则绑定到"用户本地时间"，而不是"服务器时间"，同时把免打扰时段默认设为当地 20:00 到次日 09:00。

九、不同情况下的取舍

所有提醒策略本质上都是在做取舍，没有零成本的方案。下面四组取舍是我认为最需要提前想清楚的。

1. 打扰成本 vs 逾期兜底

这是最根本的一组矛盾。想彻底降低逾期，最有效的办法就是高频提醒，但代价是静音率和用户反感。想彻底尊重专注时间，就要接受一定比例的逾期。

我的建议是把这条线画在"任务等级"上，而不是画在"平均值"上。例行型任务允许逾期，对外承诺型任务不允许逾期。前者只发一次站内信，后者可以升级到短信甚至电话。用等级分配打扰额度，而不是一刀切。

2. 统一策略 vs 个性化配置

统一策略的好处是管理成本低、数据可比、新人上手快。个性化配置的好处是体验好、响应率高。这两者不能全要。

折中方案是"全局默认 + 个人覆盖"：组织层面定一套默认规则，个人只能调整接收时段、每日上限和是否接收间接相关通知这三项，不能随意改提前量。这样既保留了个体差异，又保住了组织层面的数据可比性。

3. 自建脚本 vs 平台能力

有些团队的技术能力强，第一反应是自己写提醒脚本，接内部 IM 机器人。短期看很灵活，长期看有隐藏成本：任务数据在平台里，状态变更事件却在脚本里，两边一致性维护会越来越重。

我的判断标准是：如果你的研发流程已经落在某个项目管理平台上，提醒就应该优先用平台原生能力做，把自建精力放在数据分析和文案优化上。提醒系统最难的部分从来不是"发出去"，而是"发对"和"可分析"。

4. 短期指标 vs 长期习惯

提高提醒频率能在两周内显著改善响应率，但会破坏用户对提醒系统的长期信任。反过来，严格限制频率会让短期数据变难看，但半年后用户仍然愿意看你的通知。

如果只能选一个，我选长期习惯。因为提醒系统的价值建立在"用户还愿意看"这个前提上，一旦这个前提没了，所有参数优化都是零。

十、常见问题速答

1. 提前提醒到底提前多久最合适？

没有统一答案，但有稳定的组合结构：24 小时排期提醒 + 4 小时决策提醒 + 15 分钟兜底提醒。阻塞型任务额外加一次提前 72 小时的触达，对外承诺型任务加一次提前 7 天的预警。具体数值用两周实验校准。

2. 响应率和打开率，我该用哪个做考核？

用响应率，定义为提醒后 30 分钟内任务状态发生变更的比例。打开率可以看，但只能当作辅助诊断，不能作为优化目标，否则会诱导团队写出越来越焦虑的标题。

3. 提醒发多了用户静音怎么办？

先降总量，再谈优化。给出两条硬规则：同一任务 24 小时内最多提醒 2 次，同一责任人每日任务类通知不超过 5 条。我们的实测是，总量压下来之后，响应率反而稳定上升。

4. 小团队做数据实验有意义吗？

20 人以下的团队，样本量通常不足以支撑 A/B 结论。建议先照搬上面给出的初始阈值，把精力放在流程规范化上，等规模到 30 人以上再考虑做实验。

5. 提醒文案真的有那么大影响？

有。在我们这次实验里，纯文案改写贡献了 2.4 个百分点的逾期率改善，而且零系统成本。核心是把"你还没做"改成"卡在哪里、下一步找谁、需要我帮什么"。这个改动当天就能生效。

十一、结语：把提醒阈值当成一个活参数

回到最开始那组数字，7 条规则、620 条通知、23% 逾期率、27% 静音率。问题从来不是提醒发得不够多，而是发得太整齐：所有任务一个提前量，所有角色一套规则，所有渠道一起轰炸，发完之后没有任何数据回流。

这次实验里最值钱的三个判断，我想再强调一遍。第一，响应率是唯一值得考核的指标，打开率会骗人。第二，提醒的对象是阻塞点而不是人，把"你还没做"改成"卡在谁那里"，效果立竿见影。第三，提醒阈值不是设一次就完了的配置项，而是随团队节奏变化的活参数。

如果你打算这周就开始动手，我建议按这个顺序推进：今天先加"任务风险类型"字段，把历史任务快速分个类；这周内配好两档提醒（24 小时 + 4 小时），把文案按三段式改写一遍；下周开始记录响应率和静音率，连续记两周。

两周之后你会拿到一组属于自己的基线数据。那时候再决定要不要加阻塞型任务的 72 小时提醒、要不要给某个小组单独加长提前量、要不要引入第三个渠道兜底，用数据做决定，比用直觉靠谱得多。

最后提醒一句：提醒系统是产品，不是配置项。它有用户、有体验、有衰减、有迭代周期。把它当产品来经营，逾期率才会真正降下来并稳在那里。