任务提醒如何做好自动提醒？产品经理实操方法与操作步骤

去年我们给一个三百人规模的研发团队做任务模块复盘时，看到了一个很尴尬的数据组合：过去三个月我们上线了六条自动提醒规则，站内信加 Push 的推送量涨了 240%，但任务按时完成率只从 61% 爬到 64%，与此同时关闭通知的用户占比从 12% 涨到 29%。换句话说，我们用三倍的推送量，换来了三个点的完成率提升，以及一批永久失去触达能力的用户。那次复盘之后我把整套提醒逻辑推翻重做，最终把推送量压回原来的 1.2 倍，完成率做到 79%，通知关闭率稳定在 9% 左右。

这篇文章就是那次重构的完整方法论，我会把判断逻辑、操作步骤、踩过的坑和验证指标全部摊开讲，而不是告诉你"提醒很重要，要做好提醒机制"这种正确的废话。

一、先把结论放前面：自动提醒的成败不取决于推送能力，取决于四个决策

很多产品经理在做提醒功能时，第一反应是去对接推送通道、拉通短信服务商、确认到达率。这些是工程问题，不是产品问题。真正决定提醒效果的是四个设计决策，而这四个决策一旦拍错，推送通道再稳定也救不回来。

1. 触发条件：什么事件发生时，系统才应该启动提醒

触发条件是提醒系统的入口。它回答的不是"什么时候发"，而是"什么事发生了才值得发"。这两者的区别非常大。绝大多数失败案例的根源是触发条件定义得太宽，导致系统把"任务存在且未完成"当成了触发条件，结果就是每天定时扫一遍全量任务，给所有人发一堆提醒。

我的判断是：触发条件必须是某个状态变化，而不是某个时间刻度。状态变化包括任务状态变更、责任人变更、截止时间被修改、依赖任务完成、协作者提交了交付物。时间刻度包括每天早上九点、每周一。以时间刻度作为触发条件的提醒，本质上是在替用户管理注意力，而不是帮用户完成任务。

2. 时间窗口：提前多久、在什么时段可以打扰用户

时间窗口是提醒系统最容易被忽略的部分。我见过太多产品只定义了"截止前 24 小时提醒"，却没定义"晚上十点到早上八点不提醒"。这会导致两种情况：要么深夜的提醒轰炸引发大面积关闭通知，要么早上打开应用时被七条过期提醒淹没，反而不知道先处理哪一条。

正确的做法是把时间窗口拆成两个变量：提前量和可打扰时段。提前量随任务权重和用户习惯变化；可打扰时段则应该作为一个全局约束，任何提醒规则都不得越过它。

3. 升级策略：第一次没响应之后怎么办

没有升级策略的提醒系统是纸糊的。任务的紧急程度不是静态的，随着截止时间逼近，任务的实际优先级会自然上升。如果提醒系统在截止前 48 小时发一条、截止前 2 小时发一条，中间没有任何升级动作，那它只是在完成"通知义务"，不是在推动任务完成。

升级策略要解决的是"提醒失效"这个问题。失效可能来自三种原因：用户没看到、用户看到了但忘了、用户看到了但没能力处理。三种原因对应的升级方式完全不同，这部分我在第四章详细展开。

4. 免打扰与用户控制权：哪些情况一定不能发

这是四个决策里最容易被当成"体验优化"降级处理的一项，但我的观点恰恰相反：免打扰规则是提醒系统的安全阀，它的优先级应该高于任何单条提醒的触发逻辑。任何一条提醒规则在发送前，都应该先过一遍免打扰判定，而不是发完再看用户反馈。

用户控制权的核心不是提供一个"关闭提醒"的开关，而是让用户能精细地表达"什么类型的提醒、通过什么渠道、在什么时段来找我"。粗放的开关只会让用户全关，精细的控制才能保住触达能力。

二、为什么"到点就推"会失效：三个真实场景的复盘

我在不同产品里反复观察到同一个规律：提醒功能的首次上线通常都会带来完成率的短期提升，然后在两到四周内回落到接近基线，同时通知关闭率持续爬升。这个曲线在四个产品的数据里出现过三次，不是偶然。

1. 场景A：截止时间提醒，完成率只涨了三个点

这个场景最典型。产品逻辑很简单：任务有截止时间，截止前 24 小时给责任人发一条提醒。上线第一周数据很好看，按时完成率从 58% 涨到 71%。第二周掉到 66%，第四周掉到 62%，第六周基本回到 60%。

我拉出用户行为日志后发现，问题出在提醒和行动之间的链路太长。用户收到提醒，点开应用，看到任务标题，然后发现自己需要先确认需求、先找协作者要素材、先去另一个系统查数据。提醒只是把"任务存在"这个信息重复了一遍，没有降低任何执行成本。

更关键的是，同一个任务在六个星期里被提醒了十二次，每一次的文案都完全一样。用户在第 3 次之后就学会了忽略它，因为它不再包含新信息。

2. 场景B：跨部门协作任务，提醒发给了错误的人

第二个场景是我自己踩的坑。当时设计的是"任务逾期未完成则提醒责任人"，但忽略了跨部门协作任务的责任人往往只是协调人，真正卡住的环节在另一个部门。结果就是协调人被提醒到麻木，而真正的阻塞方毫不知情。

我们后来把这类的提醒改成双层结构：先提醒实际持有当前环节的协作者，只有当这个环节超过约定时长仍未推进，才升级提醒到任务责任人。改完之后，跨部门任务的平均流转时长从 4.3 天降到 2.1 天。

3. 场景C：周期性任务，第四周开始被集体静音

周期性提醒的衰减曲线比单次提醒更陡。我们有一个每周一早上九点推送的周报提醒，前三周的打开率分别是 78%、61%、44%，第四周掉到 23%，第五周开始，关闭该渠道通知的用户占比在两周内从 5% 涨到 31%。

这个断崖和内容无关，和节奏有关。固定节奏的提醒会让用户形成"我知道它要来"的预期，一旦预期形成，提醒的信息价值就归零了。用户不再需要它来触发记忆，因为记忆已经被建立了。这时候继续推，就是在消耗信任。

这三类场景的指标对比可以用一张图看清楚。我们当时把三类提醒在六周内的表现做了分组对比，趋势差异非常明显。

三、四种提醒类型的适用边界与关键参数

把提醒分类讲清楚，比讲十个技巧都管用。我在实际设计里用的分类只有四种，每种对应一类任务特征。分类的意义在于：选错类型比参数调错更致命，因为参数可以迭代，类型选错了方向就错了。

1. 定时提醒：适用于有明确、不可协商截止时间的任务

定时提醒的特征是触发点固定，不依赖任何外部状态。合规审批、财务结账、版本发布窗口这类任务适合用它。它的关键参数有两个：提前量阶梯和提醒次数上限。

我的经验是提前量至少分两档，比如截止前 72 小时和截止前 4 小时，两档的信息侧重不同。72 小时那一档讲"还剩多少工作量"，4 小时那一档讲"未完成会有什么后果"。同一句文案复用两次，等于浪费一次触达机会。

提醒次数上限建议不超过三次。三次是一个经验值，超过三次之后，提醒带来的边际完成率提升几乎为零，而通知关闭率的边际增长是线性的。这个数字因产品而异，但你的产品一定要有一个明确的上限，而不是让它无限循环。

2. 条件触发提醒：适用于状态依赖型任务

条件触发的触发点不是时间，是某个状态变化。比如"上游接口联调完成后，自动提醒下游测试人员启动用例编写"。这类提醒的价值密度最高，因为它携带的是新信息，用户收到时确实不知道这件事发生了。

设计这类提醒的关键参数是触发源和延迟窗口。触发源要精确到具体的字段变更，而不是泛泛的"任务有更新"。延迟窗口用于做合并，比如五分钟内同一任务的多次状态变更只发一条提醒，避免用户被碎片化的更新轰击。

3. 周期性提醒：适用于习惯养成类场景，但必须预设退出机制

周期性提醒是四类里最容易做坏的。它的本质不是提醒任务，是推动习惯。既然目标是习惯，那就必须有一个"习惯已养成"的判定标准，以及对应的提醒降级策略。

我现在的做法是给周期性提醒设一个四周观察期：连续四周都在提醒发出后两小时内完成动作的用户，自动进入低频档，从每周一次降到每月一次。提醒系统的目标应该是让自己变得不必要，而不是让自己变得不可替代。这个逻辑和很多产品经理的直觉相反，但数据支持它。

4. 智能提醒：适用于任务量大、优先级难以人工判断的场景

智能提醒的核心不是算法炫技，是优先级排序。当一个人手上有四十个任务时，提醒哪三个比提醒多少次重要得多。这类提醒的关键参数是排序因子和展示数量。

排序因子通常包括截止时间紧迫度、任务阻塞影响面、责任人当前负载、任务所属项目权重。展示数量建议控制在三条以内，超过三条用户会直接跳过整条提醒。

下面这张图把四类提醒的适用场景、实现复杂度和失效风险放在一起对比，方便做选型判断。

决策清单：三步定位你该用哪种类型

我在实际评审需求时用的判断路径很短，只有三个问题。

1. 任务是否有明确的、不受外部条件影响的截止时间？是，用定时提醒；否，进入下一问。
2. 任务是否依赖某个前置状态的变化才能开始或推进？是，用条件触发提醒；否，进入下一问。
3. 任务是重复发生的习惯类动作，还是量大且优先级需要排序的一次性任务？前者用周期性提醒并预设退出机制，后者用智能提醒并严格控制展示数量。

这三个问题能覆盖绝大多数场景。真正需要警惕的是那种"四种都想用"的需求，通常是需求没想清楚的表现，最后的产物一定是四套规则互相打架。

四、产品经理必须拍板的四个设计要素

类型选完之后，进入参数设计。这部分是产品经理真正要落笔写进需求文档的内容，也是最容易和研发扯皮的地方。我的做法是把每个要素都写成明确的决策项，而不是描述性文字。

1. 触发条件：写成事件，不写成时间

需求文档里的触发条件应该写成"当 [对象] 的 [字段] 从 [值A] 变为 [值B] 时"。这种写法有三个好处：研发能直接映射成事件监听、测试能设计明确用例、后续迭代能精确改动。

常见错误是写成"任务快到期时提醒"，这里的"快到期"在不同人眼里是不同数字。我在评审时见过研发理解成七天的，最后上线一周才开始提醒，用户完全无感。

2. 时间窗口：全局约束 + 个体覆盖

时间窗口要分两层设计。全局层定义"任何提醒不得在 22:00 到 08:00 之间发出，遇此区间顺延到次日 08:30"。个体层允许用户在全局约束范围内调整，但不能突破全局底线。

遇到紧急情况怎么办？我的处理方式是保留一个高优先级通道，只有标记为最高优先级的任务才能突破免打扰，且每天最多一次。这个通道一旦被滥用，很快就会失去用户信任，所以必须由产品经理亲自管控白名单，不能开给业务方自由配置。

3. 升级策略：按失效原因分三路，而不是简单加倍

升级策略的设计难点在于判断"为什么没有响应"。我把它拆成三种情况和对应的三种动作。

• 没看到：升级动作是换渠道，比如从站内信换到 Push 或邮件，而不是同一渠道再发一次。
• 看到了但忘了：升级动作是缩短间隔并增加上下文，把任务的关键信息（卡在谁那里、还剩多少时间）带进提醒。
• 看到了但无法处理：升级动作是通知到有权限处理的人，同时给原责任人一条说明性提醒，而不是继续催他。

第三种情况的触发判定需要数据支撑。我的做法是看用户在收到提醒后的行为路径：如果他在半小时内打开了应用但没有对任务做任何操作，就判定为"无法处理"，走第三路升级。

4. 免打扰与用户控制权：安全阀优先于触达

免打扰规则要在提醒规则之前执行，这一点必须写死在架构里。我见过太多产品是先判断该不该发提醒，发完之后用户投诉再补免打扰，结果是历史数据已经污染，用户已经关掉了通知。

用户控制权的设计我建议分三档：

1. 类型级控制：允许用户关闭某一整类提醒，比如"关闭所有周期性提醒"。
2. 渠道级控制：允许用户把某类提醒从 Push 降级为站内信，而不是直接关闭。
3. 时间级控制：允许用户设置个人的免打扰时段，但不得与全局约束冲突。

给用户留"降级"这个中间选项非常重要。数据显示，当用户只有"开启"和"关闭"两个选项时，关闭率是提供三级降级选项时的 2.4 倍。因为没有中间地带，用户的唯一选择就是彻底关闭。

五、从0到1设计一套自动提醒机制的五个操作步骤

前面讲的是判断逻辑，这一章讲具体怎么动手。我把整个流程拆成五步，每一步都有明确的输出物。这套流程我在三个产品里跑过，最短的一次从需求提出到灰度上线用了三周。

1. 第一步：梳理任务生命周期中的提醒节点

不要一上来就设计提醒规则，先把任务的生命周期画出来。一个典型的任务生命周期包括：创建、被分配、被接受、开始执行、遇到阻塞、提交待验收、验收通过或被驳回、归档。

在图上标出所有"状态可能停滞超过预期时长"的节点，这些就是候选提醒节点。一个健康的任务生命周期里，候选节点通常不超过四个。如果你标出了十几个，说明你的流程定义本身有问题，提醒解决不了流程问题。

这一步的输出物是一张标注了候选节点的生命周期图，附上每个节点的预期停留时长。预期停留时长必须来自历史数据，不能拍脑袋，否则提醒阈值会定得离谱。

2. 第二步：为每个节点匹配提醒渠道和文案策略

渠道选择的核心依据是"这件事需要多快被知道"和"用户此刻在不在系统里"。我用的匹配规则很朴素：

文案策略上我有一个坚持：每条提醒必须包含一个"新信息"，否则不发。新信息可以是剩余时间变化、责任人变化、协作者动作、风险升级。如果一条提醒和上一条相比没有任何新信息，它就不该被发出去。

3. 第三步：定义频率上限和用户控制权

频率上限要分两级设：单任务级和用户级。单任务级指同一个任务在 24 小时内最多提醒几次；用户级指一个用户在 24 小时内最多收到几条提醒。用户级上限更重要，因为它保护的是用户的整体体验，而不是单个任务的完成率。

我们的设定是单任务 24 小时内不超过 2 次，用户级 24 小时内不超过 5 次。超过上限的提醒进入队列，按优先级排序，次日或下一个可打扰时段统一以摘要形式发出。

摘要形式我强烈建议做。把五条待处理提醒合并成一条"你有 5 项任务需要关注"，打开率和完成转化都比分散推送要好得多，因为它把决策权还给了用户，而不是替他决定先看哪条。

4. 第四步：配置提醒规则并小范围灰度验证

这一步是产品经理从设计走向验证的关键。规则配置我建议用结构化的方式描述，而不是自然语言。下面是一段规则配置的示意结构，实际落地时可以根据你们的技术栈调整字段命名。

rule:
id: task_deadline_escalation

name: 任务截止升级提醒

trigger:

type: event            # 事件触发，不是时间轮询

event: task.deadline_updated

condition: "task.status != 'done' && task.deadline - now() window:

advance_stages: [48h, 4h]

allowed_hours: "08:00-22:00"

timezone: user_local

channel_policy:

stage_48h: [in_app]

stage_4h: [push, email]

escalation:

if: no_action_within 24h

action: notify_collaborators

if: no_action_within 6h

action: notify_project_owner

frequency_cap:

per_task_24h: 2

per_user_24h: 5

dnd:

respect_global: true

max_breakthrough_per_day: 1

breakthrough_requires_priority: "P0"

灰度验证要选对样本。不要选最活跃的团队，也不要选最边缘的团队，选一个流程稳定、任务量中等、成员配合度高的团队。灰度周期建议不少于两周，因为第一周的数据通常受新鲜感影响，第二周才反映真实留存。

5. 第五步：上线后按周观察并迭代

上线不是终点。我给自己定的规矩是：提醒规则上线后的前四周，每周固定看一次数据，四周之后转为每月一次。观察的核心指标不是推送量，是任务完成率和通知关闭率的比值。

这个比值我开始叫它"提醒效率"，后来发现更准确的说法是"单位触达换取的完成增量"。如果推送量涨了 50%，完成率只涨了 2%，这个规则就应该被砍掉或者重做。

六、中大型组织的提醒复杂度：以 PingCode 的规则引擎设计为例

我在这部分想讲的不是工具本身，而是一个判断：当组织规模超过一百人之后，提醒系统的复杂度会发生质变，从"配置几条规则"变成"管理一套规则体系"。这个质变点值得产品经理提前理解。

1. 一百人以下的组织和一百人以上的组织，需求差在哪里

小团队的提醒需求是线性的：任务少、角色简单、沟通靠群聊、提醒只是辅助。一百人以上的组织，提醒需求变成网状：一个任务可能跨越三个部门、五个角色，每个角色的关注点不同，同一个提醒对某些人是必要信息，对另一些人就是噪音。

更麻烦的是权限和可见性。在研发组织中，提醒内容往往包含需求标题、缺陷详情、版本信息，这些信息的可见范围受角色权限约束。提醒系统如果不做权限过滤，很容易造成信息越权泄露，这在金融、政企类客户那里是硬性红线。

我调研过几类面向中大型企业的研发管理平台，其中 PingCode 的提醒机制设计值得一提。它把提醒做成了规则引擎而不是固定的几个开关，允许按工作项类型、状态流转、字段变更、角色关系组合出触发条件。对于需要管理几十条提醒规则的大型团队，这种结构的必要性会随着规则数量增长而显现。

2. 私有化部署场景下，提醒通道的约束条件

这是一个很多 To B 产品经理容易忽略的点。当产品部署在客户内网时，外部的短信通道、第三方 Push 服务、公有云的消息队列都不可用，提醒只能走内网的邮件服务或者客户自有的企业 IM。

这意味着提醒的产品设计必须支持通道可插拔。产品经理在设计时不能把某个具体通道写死在提醒规则里，而要把"通道"抽象成一个可配置的投递目标。同一类提醒在不同客户环境里可能走完全不同的通道，规则逻辑本身应该保持不变。

我在实际项目里吃过这个亏。早期版本把提醒模板和推送通道绑定在一起，导致私有化部署的客户需要改代码才能换通道，交付周期被拉长了两周。后来改成通道适配层，交付时间压缩到两天。

3. 从其他平台迁移过来的团队，提醒规则怎么平移

这是一个很现实的问题。很多团队原本用的是 Jira 之类的国际平台，迁移时最容易被忽略的就是提醒规则。因为提醒规则往往是逐年累加配置出来的，没人记得清到底有哪些，迁移时经常被整体丢弃，然后团队在迁移后的一两个月里频繁遗漏任务。

我的建议是迁移前做一次提醒规则盘点，把现有规则按"触发条件、通知对象、通道、频率"四个字段列成表格。迁移后先恢复那些高频使用、涉及硬性截止的规则，剩下的观察一段时间再决定是否重建。

对于以国产替代为目标的迁移场景，像 PingCode 这类支持从 Jira 平滑迁移的平台在这类需求上有一定积累，它把工作项、状态流、自定义字段一并迁移之后，提醒规则可以基于新的字段结构重新配置，而不需要重新定义整个工作流。这个能力在百人以上组织的迁移项目里价值比较明显，因为工作流重建的成本远高于规则重配。

七、怎么判断你的自动提醒做得好不好

提醒效果的度量是很多产品经理的短板。大家习惯看推送量、送达率、打开率，但这些指标只能说明"发出去了"和"被看到了"，不能说明"有没有用"。我用的是一套五级指标，从触达到结果逐层收窄。

1. 五个核心指标及其真实含义

这五级指标里，我最看重的是第三级和第五级。第三级反映的是产品设计质量，第五级反映的是业务价值。如果第二级打开率很高但第三级跳转率很低，说明提醒文案和任务内容之间存在断层，用户点开提醒后不知道要干什么。

2. 指标异常时的排查顺序

指标出问题时不要乱查，按固定顺序排查效率最高。我的顺序是：先看送达率是否正常，再看打开率是否同比下降，再看跳转率是否异常，最后看完成率是否与前三项背离。

• 送达率下降：优先排查通道配置、用户通知权限、系统级免打扰设置是否被变更。
• 打开率下降但送达率正常：优先排查文案是否同质化、推送时段是否集中在用户忙碌时间、是否存在同任务重复推送。
• 跳转率下降但打开率正常：优先排查跳转链接是否失效、任务详情页是否加载慢、用户是否被跳转到了错误的任务。
• 完成率下降但前三项正常：问题通常不在提醒系统，而在任务本身变难了，或者责任人负载过高。

第四种情况尤其要注意。我见过团队因为完成率下降而不断加推送，结果是把一个流程问题当成了提醒问题，越改越糟。

3. 不要只看数据，也要收集定性反馈

数据告诉你"发生了什么"，不告诉你"为什么"。我每季度会做一轮小样本访谈，找五到八个不同角色的用户，问三个问题：最近一次让你觉得烦的提醒是什么？最近一次帮到你的提醒是什么？如果只能保留一类提醒，你保留哪一类？

这三个问题的答案经常和数据不一致。有一次数据显示某类提醒打开率很高，但访谈里三个人都说"我打开它只是为了让它消失，点一下红点就没了"。这个信息靠埋点根本看不出来。

八、产品经理最容易踩的五个坑

这一章我写得比较直接，因为每一条都是我或我身边的人真实踩过的。坑本身不复杂，难的是在需求评审时意识到自己正在往里走。

1. 坑一：所有任务都用同一种提醒策略

这是最普遍的。产品里只有一个"任务提醒"开关，所有任务共用同一套逻辑。结果是轻量任务被过度提醒，重量任务被提醒不足。用户在轻量任务上产生疲劳，顺带屏蔽掉了重量任务的提醒。

修复方式是把提醒策略和任务类型或优先级绑定，让不同权重的任务走不同的规则。这一步不需要大改架构，只需要在规则配置里加一层匹配条件。

2. 坑二：提醒频率没有硬上限

没有上限的提醒系统，在业务压力大的时候一定会失控。业务方会不断要求"再多提醒一次"，如果没有硬性上限，产品就会变成一个推送机器。

我的做法是把上限写进产品需求文档，并且在数据看板上把"用户日均接收提醒条数"作为一级监控指标。这个数字超过阈值就触发告警，由产品经理介入，而不是等业务方自己收敛。

3. 坑三：忽略用户对提醒的控制权

很多产品只提供一个总开关，甚至把开关藏在设置页的第三层。用户的反应很直接：找不到精细选项就关掉总开关，关掉之后所有提醒都失效，包括那些他其实需要的。

控制权的设计要遵循一个原则：让用户能在不完全关闭的前提下表达不满。降级、延后、合并，这些都是比关闭更好的用户表达方式。

4. 坑四：只看推送量，不看完成率

推送量是最容易做的指标，也是最容易骗人的指标。它只反映系统的活跃度，不反映价值。我在做季度汇报时，会把"单位触达完成增量"作为核心指标放上去，让团队习惯用效率而不是用量来衡量提醒系统。

5. 坑五：上线后不迭代，规则一成不变

提醒规则是有保质期的。团队规模变了、流程改了、工具迁移了，原本合理的提醒阈值就会变得不合适。我见过一个产品，提醒规则上线两年没改过，最后内部调研时发现超过半数用户已经把它当成骚扰信息。

建议给每条提醒规则设一个复查周期，比如半年一次，复查内容包括触发频率、用户反馈、完成率贡献。贡献为负或者接近零的规则，直接下线。

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

前面讲的是通用方法，这一章讲怎么根据自己的情况做取舍。提醒系统的设计本质上是在三个变量之间做平衡：触达强度、用户耐心、实现成本。三者不可能同时最优，必须选一个优先项。

1. 按产品阶段做取舍

产品早期，我建议优先做条件触发提醒，因为它的单位触达价值最高，而且规则数量少、维护成本低。这个阶段的用户对产品还在建立信任，一条精准的提醒能显著提升留存。

产品成熟期，用户量和任务量都上来了，重心应该转向规则治理和用户控制权。这个阶段增加提醒规则的边际收益已经很低，而用户反感的风险在上升。把精力放在给用户更细的控制粒度上，比再加两条规则更有价值。

2. 按组织规模做取舍

百人以下的团队，提醒系统的关键词是"够用就好"。不需要规则引擎，几条固定规则加上合理的时间窗口就能覆盖 90% 的场景。

百人以上的组织，关键词变成"可控和可审计"。这时候需要考虑规则的集中管理、提醒内容的权限过滤、提醒效果的分部门度量。这也是为什么中大型企业倾向于选择具备规则引擎能力和私有化部署能力的平台，不是因为功能多，是因为规则多到需要一个体系来管理它们。

3. 按触达渠道成本做取舍

渠道是有成本差异的。站内信几乎零成本，应用内 Push 成本极低，邮件成本低但打开率不稳定，短信成本高但触达确定，电话成本最高且只在极端场景下使用。

我的分配原则是：把有限的成本花在"无法通过其他方式触达"的场景上。日常任务推进用站内信和 Push，只有硬性截止且后果明确的任务才动用短信，电话基本不进入常规提醒链路，只在 P0 级别的生产事故响应里使用。

4. 按团队协作成熟度做取舍

成熟度低的团队，提醒要做"重"一点，因为还需要靠提醒来推动动作。成熟度高的团队，提醒要做"轻"一点，把控制权交给团队自己配置，产品只提供能力和默认值。

这个判断很反直觉，但我在实际项目里验证过。给一个流程已经很规范的团队强推高频提醒，他们的第一反应是全部关掉，因为提醒对他们来说是干扰而不是帮助。

十、结语：好的提醒系统，目标是让自己变得不必要

回到最开始那个案例。我们把推送量压回 1.2 倍之后，完成率反而做到了 79%，原因不是我们找到了什么神奇的推送时机，而是做了三件看起来很朴素的事：每条提醒必须带新信息、给用户三级降级选项而不是一个开关、每条规则设置硬性频率上限并定期复查。

这三件事没有一件需要复杂的算法，但都需要产品经理在需求阶段就想清楚，并且敢于对"再加一条提醒"的需求说不。提醒系统的复杂度不在技术层，在决策层。

如果你现在正准备做或重做任务提醒功能，我建议你按这个顺序推进：先用第三章的三步判断法确定提醒类型，再用第四章的四个要素写清参数，然后按第五章的五个步骤落地，最后用第七章的五级指标建立监控。整个过程里，把"用户能不能表达不满"和"这条提醒有没有新信息"这两个问题问自己三遍。

还有一个更长期的判断我想留给你：提醒系统做得越好的产品，用户对提醒的依赖应该越低。如果一年之后你的用户还在被同样数量的提醒推动着完成任务，那说明提醒在替代流程和习惯做工作，而不是在帮助用户建立它们。真正成熟的提醒系统，会随着用户行为的改变主动降频，最终退到一个安静的角落里，只在真正需要的时候出现一次。

下一步动作很具体：打开你的产品，把当前所有提醒规则列成一张表，标出每条规则的触发条件、频率上限、用户能否降级、最近一次复查时间。这张表上出现空白的地方，就是你下一个版本要改的地方。