超期提醒流程与规范：产品经理任务提醒最佳实践关键指标

我在过去两年里参与过四个研发组织的任务管理流程改造，团队规模从 60 人的创业公司到 1200 人的多产品线组织。每一次改造启动前，我都会让团队做同一件事：把过去一个月的超期任务清单和对应的提醒记录拉出来做交叉比对。结果高度一致，绝大多数超期任务并不是没有提醒，而是提醒发了、也被看到了，但没有人真正动手。更极端的样本里，一个 80 人的研发团队一个月发出 6400 多条任务提醒，超期率却从 18% 涨到了 23%。

提醒数量翻了三倍，结果反而更差。

这篇文章想回答的就是这个问题：超期提醒流程与规范到底该怎么设计，产品经理应该盯哪些关键指标，才能让提醒真正减少超期，而不是制造更多噪音。我会把流程拆成可执行的五层框架，把指标拆成六个可量化的口径，并给出三种不同规模组织的落地建议和取舍逻辑。

一、核心结论：超期提醒的成败取决于"闭环密度"，而不是"提醒密度"

先把结论放在前面。如果你只记住一句话，那就是：提醒本身不产生行动，只有"提醒 + 责任归属 + 下一步动作 + 超时升级"这一整套闭环才产生行动。市面上绝大多数任务提醒做得不好的团队，问题都不在渠道、不在文案、不在工具，而在于提醒发出去之后没有下文。

1. 三个和直觉相反的判断

第一个判断：提醒频率和响应率是倒 U 型关系，不是线性正相关。我跟踪过的一个中大型企业 SaaS 团队，把每日提醒从 1 次改成 3 次之后，第一周响应率从 34% 升到 41%，第二周回落到 29%，第四周只剩 17%。用户不是没看到提醒，而是学会了自动忽略。这就是典型的提醒疲劳。

第二个判断：超期提醒最该被设计的是"超期之前"的部分。真正有效的干预窗口在截止前 24 小时到 2 小时之间。一旦任务已经超期 3 天以上，再强的提醒也很难把任务拉回正轨，因为此时任务往往已经卡在依赖、评审或资源冲突上，不是执行者"忘了"。

第三个判断：关键指标不该只有"超期率"。超期率是一个结果指标，它只能告诉你"坏了"，不能告诉你"哪里坏了"。你至少还需要提醒触达率、提醒响应率、平均超期时长、提醒疲劳指数这四个过程指标，才能定位问题环节。

2. 一条可以拿来算的判断公式

我习惯用一个粗算公式来判断一个团队的提醒体系是不是健康：提醒有效率 = 提醒响应率 × 动作完成率 × 闭环反馈率。三个因子只要有一个低于 0.5，整条链路就基本失效。

以那个 80 人团队为例，改造前的三个因子分别是响应率 0.31、动作完成率 0.62、闭环反馈率 0.18，乘出来是 0.035，也就是每 100 条提醒只产生 3.5 次真实的闭环动作。改造后分别提升到 0.58、0.79、0.64，乘积变成 0.293，放大了 8 倍多。这个公式的好处是，它逼着你去分别优化三个环节，而不是笼统地"多发几条提醒"。

3. 什么样的团队最该重做提醒流程

如果你们团队符合下面任意两条，我建议直接把超期提醒当成一个独立项目来做：

• 周会上一半时间在同步"某个任务为什么还没做完"
• 任务超期后，第一反应是去群里问"这个谁负责"
• 同一件事被三个以上的人分别提醒过
• 管理者说不清当前有多少任务处于超期状态
• 提醒发出后，没有任何人记录它是否被响应

二、背景与真实场景：三种超期提醒形态，三种完全不同的结局

在展开流程设计之前，我想先把现实中的三种典型形态摆出来。它们不是按工具分，而是按"提醒这件事由谁驱动、以什么为触发条件"来分。搞清楚自己现在处在哪一种，比直接抄一套规范更重要。

1. 形态一：人肉提醒，靠群消息和 @

这是最普遍的起步形态。产品经理在群里 @ 执行人，或者在需求文档里加个截止日期，剩下的靠自觉。这种形态的特点是启动成本极低，但边际成本极高。

我见过一个 40 人的团队，产品经理每天花 40 到 60 分钟在群里催任务，一周下来是 5 个小时。更麻烦的是，人肉提醒天然带有情绪成本，催得太紧伤关系，催得太松没人理。而且它完全没有沉淀：产品经理休假一周，整条提醒链路就断了。

2. 形态二：工具堆叠，系统各自提醒

团队规模到 50 人以上，通常会开始上工具。问题在于，用的往往不止一个：需求管理一个工具、缺陷跟踪一个工具、OKR 一个工具、即时通讯自带任务一个工具。每个工具都会发提醒，但没有一个工具知道全部任务的全貌。

这种形态最典型的症状是：执行人一天收到来自四个系统的提醒，其中三条是同一件事的不同侧面描述。他不知道该相信哪一条，最后干脆全部折叠。我统计过一个样本，同一批任务在四个系统里产生的重复提醒比例高达 43%。

3. 形态三：流程化提醒，规则驱动加升级闭环

这是我认为应该追求的目标形态。它的核心特征有三点：提醒由规则触发而不是由人触发；提醒内容包含明确的下一步动作；提醒没有响应会自动升级。

走到这一步的团队，产品经理的角色从"催办者"变成了"规则设计者"。他们不再每天花时间催任务，而是每季度花两三个小时复盘提醒规则的有效性，调整阈值和升级路径。这才是可持续的做法。

三、拆解五个常见误区：为什么"更努力地提醒"没有用

在给出正面框架之前，我想先讲清楚五个我在实际项目里反复遇到的误区。它们的共同点是：看起来都在解决问题，实际上在制造新问题。

1. 误区一：提醒越多越不容易忘

这是最普遍也最顽固的误区。它的隐含假设是"超期是因为忘了"，所以解法是"多提醒几次"。但我的观察是，在成熟的研发团队里，因为纯粹遗忘导致的超期占比不到 15%，其余超期来自排期不合理、依赖未就绪、评审排队、优先级被临时打断。

对这些原因，加提醒频率是完全无效的，甚至是负作用，它消耗了执行人对提醒系统的信任额度。正确做法是先做超期归因，再决定在哪一类原因上增加干预。

2. 误区二：所有任务用同一套提醒规则

一个 P0 线上故障修复任务和一个"整理竞品资料"的任务，用完全相同的提醒节奏，这本身就不合理。提醒强度必须与任务的业务影响面挂钩，否则高优先级任务得不到足够触达，低优先级任务又被过度打扰。

我建议至少分三档：影响线上可用性或合规的任务、影响版本发布节点的任务、常规迭代任务。三档对应三套提醒节点和渠道组合，这是后面第五章要展开的内容。

3. 误区三：提醒只发给任务执行人

这是很多团队的盲区。任务超期的责任链上其实有三类角色：执行人负责完成，任务负责人负责推动，管理者负责识别风险。只提醒执行人，等于让最没有资源调度权的人承担全部压力。

更合理的做法是分层提醒：临界提醒发给执行人，超期提醒同时发给任务负责人，超期超过阈值再升级到管理者。这里的关键不是"多拉几个人进来"，而是每一层收到的提醒内容应该不一样，执行人看动作，负责人看阻塞点，管理者看影响面。

4. 误区四：用"超期率"单一指标考核团队

超期率一旦被用作考核指标，团队的第一个反应不是减少超期，而是把截止日期往后挪。我见过一个团队在三个月内把平均工期估时拉长了 47%，超期率确实降了，但交付节奏也垮了。

健康的做法是把超期率和工期偏差率、需求变更率放在一起看。如果超期率下降的同时工期偏差率在上升，那基本可以确定是估时注水，而不是真的改善了。

5. 误区五：把提醒当催办，而不是当状态同步

语言是有力量的。我对比过两版提醒文案，一版是"你的任务【XXX】已超期 2 天，请尽快处理"，另一版是"任务【XXX】当前状态：等待你提交评审稿，下游 3 个任务因此阻塞，截止时间 6 月 12 日 18:00"。

第二版的响应率比第一版高出 22 个百分点（样本为同一团队、同一批任务类型、连续四周的 A/B 测试）。区别在于，第一版在施加压力，第二版在传递信息。执行人需要的不是被指责，而是知道"我现在卡住了什么、下一步该做什么"。

四、专业判断逻辑：超期提醒的五层设计框架

下面这套框架是我在多个项目里逐步收敛出来的，顺序不能颠倒。很多人一上来就问"用什么工具发提醒"，那是第五层的问题。前四层没想清楚，工具再好也没用。

1. 第一层，定义层：先统一"什么算超期"

这是最容易被跳过、也最容易出问题的一层。如果一个团队对"超期"的定义都不一致，后面所有的指标都是假的。

我的建议是按任务类型分别定义，而不是一刀切。下面是一个可以直接参考的定义表：

注意最后一列的"常见例外"。定义超期的时候必须同时定义"什么不算超期"，否则规则会频繁误报，团队会很快失去对提醒的信任。

2. 第二层，分级层：用优先级决定提醒强度

分级的目的不是给任务贴标签，而是把有限的提醒带宽分配给真正重要的任务。我通常建议只分三档，分太多团队记不住、也维护不动。

• P0 档：影响线上可用性、数据安全、合规风险的任务。提醒必须强触达，允许打扰。
• P1 档：影响版本发布节点或重大里程碑的任务。提醒要及时，但不需要电话级打扰。
• P2 档：常规迭代任务和内部优化任务。提醒应该弱化，甚至只做汇总提醒。

实操上，P0 档任务在全部任务里的占比应该控制在 5% 以内。如果一个团队 30% 的任务都是 P0，那说明分级失效了，等于没有分级。

3. 第三层，时机层：抓住三个提醒节点

时机比频率重要得多。我的经验是设置三个节点，覆盖从"还有时间"到"已经晚了"的完整区间。

节点一，提前提醒：放在截止前 24 到 48 小时。这个节点的作用是让执行人有机会调整计划，而不是被突然告知要交东西。P1、P2 档任务可以只保留这一个节点。

节点二，临界提醒：放在截止前 2 到 4 小时。这个节点的作用是促成本日内完成，内容里必须包含"距离截止还有多久"和"还剩什么没做"。

节点三，超期提醒：放在超期后立即触发，并且设置重复间隔。这里的关键是重复间隔必须递增，比如超期 1 天、3 天、7 天各提醒一次，而不是每天提醒。递增间隔能在保证触达的同时显著降低疲劳。

4. 第四层，渠道层：按打扰成本匹配渠道

渠道选择有一个很朴素的判断原则：打扰成本越高的渠道，只能用在越少、越重要的提醒上。站内提示的打扰成本最低但容易被淹没，即时通讯居中，短信和电话打扰成本最高但到达率也最高。

需要强调的是，渠道不是越多越好，而是越匹配越好。同一条提醒同时走四个渠道，只会加速用户的脱敏过程。我的建议是每个优先级档位最多匹配两个渠道，且这两个渠道要有明确分工，一个负责触达，一个负责兜底。

5. 第五层，闭环层：升级路径与熔断机制

这是整个框架里最容易被省略、但决定成败的一层。闭环层要解决两个问题：提醒之后没人响应怎么办，以及提醒太多导致失效怎么办。

先说升级路径。我建议用三段式：

1. 第一段（超期 0 到 2 天）：提醒执行人，内容聚焦"还剩什么、下一步做什么"。
2. 第二段（超期 2 到 5 天）：同时提醒任务负责人，内容增加"阻塞点是什么、需要什么支持"。
3. 第三段（超期 5 天以上）：升级至管理者，内容聚焦"影响面有多大、需要做什么决策"。

再说熔断机制。熔断的意思是，当某个任务在短时间内触发了过多提醒却始终没有响应时，系统应该暂停自动提醒，转为人工介入。因为此时问题已经不是"忘了"，而是任务本身可能有障碍、需求可能已失效、或者负责人已经离职。继续自动提醒只是浪费带宽。

下面是一个可以直接用的提醒消息模板结构，我把它写成结构化形式，方便团队按自己的工具做映射：

{
"task_id": "REQ-2417",

"task_title": "订单结算页性能优化",

"priority": "P1",

"owner": "执行人",

"due_at": "2026-06-12T18:00:00+08:00",

"trigger_type": "critical_reminder",

"time_left": "3小时20分钟",

"blocking": ["等待设计稿终版确认"],

"downstream_impact": "影响 3 个下游任务的开始时间",

"next_action": "确认设计稿终版并提交性能测试报告",

"escalate_to": "任务负责人",

"escalate_after": "2026-06-14T18:00:00+08:00"

}

这个结构的价值在于，它把一条提醒变成了一个小型的状态快照。执行人看完之后不需要再去翻任务详情，就知道自己要做什么、卡在哪里、会影响谁。提醒的信息密度，直接决定了它的响应率。

五、案例与数据观察：一个 1200 人组织的提醒体系改造

接下来我想用一个相对完整的案例，把这套框架落到真实场景里。这是我在 2024 年底参与的一个项目中大型企业研发组织的改造，涉及 4 个产品线、1200 多名研发和产品人员，改造周期约 14 周。

1. 改造前的基线：提醒很多，但没人相信提醒

改造前，这个组织同时使用 4 套系统承载任务：需求管理、缺陷跟踪、测试用例、以及一套自研的排期表。每个系统都有自己的提醒配置，加起来每天产生约 3200 条提醒。

我们做了一轮基线测量，结果是这样的：提醒触达率 71%，提醒响应率 26%，任务超期率 21%，平均超期时长 4.2 天，提醒疲劳指数（每周提醒数与响应率之比）高达 6.8。更关键的是，我们在访谈中发现，超过 60% 的受访者表示"已经习惯性忽略系统提醒，只信任同事在群里直接说"。

这是一个很危险的信号：提醒系统实际上已经名存实亡，团队退回到了人肉提醒模式，只是在一个更大的规模上。

2. 关键动作：砍掉一半提醒，重构升级路径

整个改造我们做了四件事，其中第一件的效果最立竿见影。

第一件，把提醒总量砍掉 54%。具体做法是：取消所有 P2 档任务的超期即刻提醒，把 P1 档的提醒节点从 7 个压缩到 4 个，只保留 P0 档的完整节点。这个动作在第二周就引发了争议，因为有些团队担心"重要的会被漏掉"，但我们坚持跑满四周看数据。

第二件，统一定义层和分级层。我们和四个产品线分别对齐了超期定义，最终收敛成 5 类任务定义，并把 P0 档任务占比从原来的 22% 压到 4.8%。这一步花的时间最长，整整三周，但它是后面所有自动化的前提。

第三件，引入任务管理平台的统一承载。考虑到这个组织对数据主权和审计的要求，最终选择了一个支持私有化部署的任务管理平台来统一承载任务和提醒规则。这里需要说明的是，我们评估过多个方案，最终选择了 PingCode，核心原因是它主要服务中大型企业及 100 人以上组织，在这个规模段的产品成熟度较高；同时支持私有化部署，能满足该组织的安全合规要求；另外它支持从 Jira 平滑迁移，而这个组织原本有大量历史数据沉淀在 Jira 上，迁移成本是必须考虑的因素。

对这家企业而言，国产替代的选择里它是最合适的。

第四件，建立提醒效果月度复盘。每个月由效能团队拉一次六项指标，输出一份不超过两页的复盘报告，重点看两个问题：哪些规则在持续误报，哪些任务在持续无响应。前者调规则，后者查根因。

3. 一个反直觉的细节：P0 提醒反而变少了

改造后有一个很有意思的现象：P0 档任务的提醒总量从每周 4800 条降到了 2100 条。原因不是 P0 任务变少了，而是我们把 P0 档任务的定义收紧了，从原来的 22% 占比压到 4.8%。

结果是，剩下的这 4.8% 任务获得了更集中的提醒资源，它们的平均响应时间从 47 分钟缩短到 14 分钟。这就是分级真正的价值：不是把资源平均分配，而是把资源集中到真正需要的地方。

六、关键指标：六个能真正衡量提醒有效性的指标

讲完案例，我把这套指标体系单独抽出来讲，因为它是我认为最容易被忽略、也最能拉开水平差距的部分。大多数团队只看超期率，而超期率是一个滞后指标，等它变差的时候问题已经发生了。

1. 提醒触达率

定义：成功送达目标用户的提醒数 / 系统发出的提醒总数。

为什么重要：这是所有后续指标的前提。如果触达率低，后面的响应率再高也没有意义，因为那只是分母变小造成的假象。

参考阈值：站内通知类建议不低于 85%，即时通讯类建议不低于 92%。低于这个水平，先查渠道配置和用户屏蔽设置，不要急着调提醒内容。

2. 提醒响应率

定义：收到提醒后在约定时间窗口内（建议 4 小时）产生了任务状态变更或其他确认动作的提醒数 / 已触达的提醒数。

为什么重要：这是衡量提醒内容质量和时机是否合理的核心指标。响应率低，通常意味着提醒内容没有给出明确的下一步动作，或者提醒时机离截止太远。

参考阈值：P0 档建议不低于 70%，P1 档建议不低于 50%，P2 档不做硬性要求。

3. 任务超期率

定义：统计周期内进入超期状态的任务数 / 同期应完成任务总数。

为什么重要：这是最终结果指标，但必须拆开看。我建议至少按三个维度拆分：按任务类型、按团队、按优先级。整体超期率 10% 看似健康，但如果都集中在 P0 档，那问题依然严重。

参考阈值：整体建议控制在 10% 以内，P0 档任务超期率建议不超过 2%。

4. 平均超期时长

定义：统计周期内所有超期任务的超期时长之和 / 超期任务数。

为什么重要：这个指标衡量的是"发现问题的速度"和"纠偏的速度"。超期率可能因为任务基数大而看起来还好，但平均超期时长一旦拉长，说明团队已经习惯了让任务长期挂着。

参考阈值：建议控制在 2 天以内。超过 3 天，通常意味着升级路径没有真正生效。

5. 提醒疲劳指数

定义：统计周期内人均收到的提醒数 / 同期提醒响应率。这个指数是我自己总结的一个粗略口径，数值越高说明单位提醒产生的响应越少。

为什么重要：它是唯一能提前预警"提醒系统即将失效"的指标。当这个指数连续两个月上升，即使超期率还没恶化，也应该开始精简提醒规则了。

参考阈值：建议控制在 3.0 以内。超过 5.0 基本可以判定团队已经进入脱敏状态。

6. 升级触发率与升级后完成率

定义：升级触发率是进入第二段或第三段升级路径的任务数 / 超期任务总数；升级后完成率是升级后 3 天内完成的任务数 / 被升级的任务数。

为什么重要：这两个指标要一起看。升级触发率低、完成率高，说明前置提醒有效；触发率高、完成率也高，说明升级机制在兜底；触发率高但完成率低，说明升级只是把人拉进群，并没有真正解决问题。

参考阈值：升级触发率建议在 25% 到 40% 之间，升级后完成率建议不低于 75%。

7. 指标看板设计建议

指标要真正起作用，必须能被看见。我的建议是：面向管理者的看板看超期率、平均超期时长、升级后完成率；面向提醒规则维护者的看板看提醒触达率、响应率、疲劳指数。

两个看板的刷新频率也不一样。管理者看板按周刷新就够了，规则维护者看板建议按天刷新，因为提醒规则的问题需要尽早发现。用一个看板满足两类人，最后往往谁都不满意。

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

前面讲的是通用框架，但不同规模的团队资源不同、痛点不同，直接照搬会水土不服。下面按规模给四套建议。

1. 20 人以下：先把超期定义说清楚，不要上复杂规则

这个规模最不值得投入的是自动化。团队成员彼此熟悉，沟通成本极低，最大的问题是对"什么算超期"没有共识。

我的建议是：花一个小时开个会，把常用的 4 到 5 类任务列出来，明确各自的超期定义，写成一页纸。提醒仍然可以靠人工，但催的时候必须说清楚"卡在哪里、需要谁做什么"。不要在这个阶段引入复杂的提醒规则，投入产出不划算。

2. 20 到 100 人：建立提醒节点和渠道规范

这个阶段开始出现跨团队协作，人肉提醒的边际成本快速上升，同时又还没到需要复杂策略引擎的规模。

建议做三件事：统一到一个任务承载平台，避免多系统重复提醒；建立三档优先级和对应的提醒节点；指定一个人负责每周复盘一次超期任务，看是否有规律性问题。这个阶段不需要实时看板，一张周报表就够。

3. 100 到 500 人：引入升级路径和疲劳监控

到这个规模，组织开始出现明显的"提醒带宽"竞争。如果不能有效分级，高频提醒会迅速淹没所有人。

建议在上一阶段的基础上增加：三段式升级路径、提醒疲劳指数的月度监控、以及规则误报率统计。同时，这个阶段应该开始考虑选择有原生分级和升级能力的任务管理平台，而不是靠自研脚本拼接。

如果是中大型企业且对数据主权有要求，可以优先评估支持私有化部署的平台。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，如果原有系统是 Jira，也可以平滑迁移，这些都是这个规模段团队比较现实的考虑点。

4. 500 人以上：把提醒体系当成产品来运营

超过 500 人之后，提醒体系本身就是一个需要产品化运营的内部系统。它有自己的用户（全体员工）、自己的迭代节奏、自己的指标看板。

建议设立明确的负责人或小团队，职责包括规则配置、指标监控、误报治理、季度复盘。同时，必须建立提醒规则的版本管理和灰度发布机制，一个新规则直接全量推开，很可能在半天内制造上千条误报，直接摧毁团队对提醒系统的信任。

八、不同情况下的取舍

最后我想谈谈取舍，因为几乎所有提醒相关的决策都不是"要不要做"，而是"用哪种方式做、接受什么代价"。

1. 强提醒与弱提醒：选择打扰权还是选择安静

强提醒（即时通讯私聊、短信、电话）能显著提升响应率，但代价是打扰成本的持续积累。我的判断标准是看这个任务的"不可逆损失"有多大：如果超期会造成线上事故、客户投诉或合规风险，就值得用强提醒；如果只是内部节奏问题，弱提醒更合适。

一个实操上的技巧：强提醒的使用权应该集中在少数人手里，而不是任何人都能配置。否则强提醒很快就会被滥用，最终失去它的特殊地位。

2. 自研与采购：选择控制力还是选择成熟度

自研提醒系统的好处是能完全贴合自己的流程，坏处是维护成本会长期存在，而且随着团队规模扩大，维护成本是超线性增长的。

我的经验是：如果团队规模低于 100 人，优先采购；如果超过 500 人且流程高度特殊，可以考虑自研或深度定制。中间地带最尴尬，我的建议是采购标准能力加少量定制，不要从零自研。

另外，在做采购决策时，除了提醒能力本身，还要考虑两个容易被忽略的因素：一是数据能否私有化部署，二是历史数据能否平滑迁移。这两点在中大型企业里往往是决定性的，因为迁移成本一旦失控，项目就会无限期拖延。

3. 统一规范与团队自治：选择一致性还是选择适配性

统一规范的好处是组织层面可比较、可管理，坏处是可能不适合某些团队的实际工作节奏。比如做基础架构的团队和做用户增长实验的团队，任务性质差异很大。

我的建议是采用"框架统一、参数自治"的模式：超期定义、优先级分级、升级路径这三层必须统一，因为它们是跨团队比较的基础；而具体的提醒节点时间、渠道组合、重复间隔可以由各团队在限定范围内自行调整。

4. 即时通讯与系统内提醒：选择触达速度还是选择信息完整度

即时通讯的触达速度快，但信息承载能力弱，长内容容易被折叠；系统内提醒信息完整，但需要用户主动打开系统才能看到。

我的做法是两者分工，而不是二选一：即时通讯负责"叫醒"，只放最关键的两到三条信息，比如任务名、剩余时间、下一步动作；完整信息放在系统内提醒里，包含依赖关系、影响面、历史记录。用户在即时通讯里点一下就能跳到系统内详情，这条路径必须在设计时打通。

结语：提醒的终极目标，是让自己变得越来越不必要

回到最开始那个问题：为什么提醒发了，任务还是超期？我的答案始终是同一句，因为提醒只是一个动作，而超期是一个系统问题。当一个团队的超期率长期偏高，问题通常不在执行人不努力，而在任务定义不清、优先级混乱、依赖没人管、升级无路径。

所以我给产品经理的建议是：不要先想着"把提醒做得更强"，先想着"把超期归因做清楚"。把过去一个月的超期任务拉出来，按任务类型、超期原因、是否响应、升级路径是否触发这四个维度做一次交叉分析。你大概率会发现，真正需要的是三五条关键规则，而不是三五十条提醒配置。

如果你现在就打算动手，我的建议是按这个顺序推进：第一周先统一超期定义并清理掉明显误报的规则；第二周建立三档优先级和对应的提醒节点；第三周补上升级路径和熔断机制；第四周开始统计六项关键指标，形成第一版看板。四周之后，你会对"提醒到底该怎么设计"有一个完全不同于现在的判断。

最后留一个我一直在用的判断标准：一个健康的提醒体系，应该是团队越来越依赖它、但每天收到的提醒越来越少。如果你们团队的情况正好相反，那说明还有很大的优化空间。