任务提醒自动提醒全流程：研发团队数据分析与一文讲清

上周三上午十点，我给一个 60 人规模的研发团队做流程复盘。打开提醒日志的那一刻，会议室安静了几秒：过去 30 天，系统一共推送了 11420 条任务提醒，人均每天收到 6.3 条；但同期任务逾期率是 27%，比三个月前“还没上自动提醒”的时候还高了 4 个百分点。团队负责人问了一句特别典型的话：“我们提醒明明做了，为什么情况更差了？”

这不是个例。过去两年我先后帮十几个研发团队梳理过任务提醒链路，从 8 人的创业小队到 400 人的多产品线组织都有。我发现绝大多数团队卡住的地方，从来不是“提醒发不出去”，而是“提醒发出去之后没人负责收尾”。换句话说，他们把自动提醒当成了一个通知功能，而不是一条需要被度量、被升级、被闭环的流程。

这篇文章会把“任务提醒自动提醒全流程”完整拆开：触发条件、渠道与频率、升级规则、确认闭环、异常处理，再讲清楚研发团队该用哪几个指标做数据分析、看板怎么搭、怎么用对照实验验证提醒到底有没有用，最后给不同规模团队的行动建议和取舍逻辑。文中数值来自我参与过的项目观察，部分做了脱敏与区间化处理，我会标注哪些是实测、哪些是示意推演。

一、先说结论：提醒失效的根因不在渠道，而在缺一套可度量的闭环

1. 我的核心判断

先把结论摆在最前面：任务提醒自动化的成败，90% 取决于流程和数据结构设计，只有 10% 取决于你选了哪个渠道发消息。我见过太多团队把精力全砸在“用企业 IM 还是短信”“要不要加个桌面弹窗”上，却从没定义过“一条提醒发出后，多久没响应算失败”。

一条真正能跑起来的自动提醒，本质上是一条状态机：任务有状态，提醒有生命周期，响应有记录，超时有升级，闭环有回写。缺掉其中任何一环，提醒就退化成一条噪音消息。

2. 一个反常识的数据观察

我跟踪过的一组数据显示：提醒发送量从每月 0 条涨到 11420 条的过程中，任务逾期率并没有单调下降，反而在第三个月明显反弹。提醒量和流程健康度之间不是正相关，而是先升后降的倒 U 型关系。原因很简单，当提醒密度超过人的处理带宽，用户会启动“批量已读”模式，提醒就从信号变成了背景噪音。

下面这组数据来自我参与复盘的那个 60 人团队，提醒条数和逾期率的走势几乎是反向的，这也是当时最刺眼的一张图。

3. 全流程只有五个环节，但 80% 的团队只做了两个

把自动提醒拆到底，总共就五个环节：触发条件、提醒渠道与频率、升级规则、确认与闭环、异常处理。我调研过的团队里，绝大多数只做了“触发 + 渠道”这两步，后面三步基本空白。

这就像装了烟雾报警器却没有消防通道：报警器响得很勤快，但没人知道响了之后该往哪跑。流程缺了后半段，前端做得再精致也没用。

二、背景与真实场景：三个研发团队的提醒失败现场

1. 场景一：周会前的“提醒轰炸”

某 SaaS 公司的研发团队，把每日站会提醒设成了每天早上 9:00 群发一次，同时每个人名下的任务再单独推送一次。结果每天 9:00 到 9:05，团队成员的工作台会同时弹出 4 到 7 条通知。

三个月后我做访谈，一个后端工程师的原话是：“我根本不看时间线了，我只在站会上听组长念。”提醒过载直接摧毁了提醒的信息价值，用户不是没看到，是主动选择忽略。

2. 场景二：逾期任务没人认领

另一个 120 人的组织，任务逾期提醒只发给任务执行人。问题在于，他们的需求变更流程里，一个任务能否推进往往取决于上游的接口联调方和下游的测试资源，而这两方根本不在提醒范围内。

我抽查了 200 条逾期任务，其中 143 条的逾期原因写的是“等待上游”或“等待测试环境”。把提醒只发给单一责任人，等于把系统性问题降级成个人问题。

3. 场景三：提醒只到执行层，不到决策层

还有一个团队，提醒规则设计得很细，但完全没有升级机制。任务逾期 10 天，提醒还是照常发给执行人，只是语气更着急了一点。项目经理每周一靠人工查看板才发现风险项，此时距离真正的交付延期只剩几天。

这个团队的逾期任务平均“被发现时间”是 8.4 天，而任务平均剩余缓冲只有 3 天。没有升级规则的提醒，本质上只是把责任留在了最没有权限解决问题的那个人身上。

4. 我自己踩过的两个坑

（1）坑一：把提醒频率当作“重视程度”的体现。我早期给一个团队做配置时，把 P0 缺陷设成每小时提醒一次，自以为很负责。结果一周内三位工程师把这个通知渠道关掉了，P0 提醒反而变成了最不可靠的通道。

（2）坑二：只统计“发出去了多少”，不统计“解决了多少”。当时我做的周报全是发送量、送达率这种上游指标，看起来很漂亮，但没人能回答“这个月提醒到底帮我们挽回了几次延期”。后来我改用闭环率做核心指标，整个讨论的质量立刻不一样了。

为了看清主次，我把这 12 个团队反馈的提醒失效原因做了一次归因排序，结果如下。

三、拆解常见误区：五个看上去合理、实际在拖后腿的做法

1. 误区一：把提醒发送量当成流程健康度

发送量是成本，不是产出。它只证明系统在运转，不证明问题在被解决。更危险的是，发送量是一个很容易“做上去”的指标，把频率调高一倍，数字立刻翻倍，但逾期率可能一动不动。

我建议把发送量降级为诊断指标，只在排查“提醒是否正常触发”时使用，永远不要放进给管理层看的周报首页。

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

一个 3 天工时的重构任务和一个 4 小时工时的线上缺陷，用同一套 T-1 天提醒规则是荒谬的。前者的提醒出现在正确的决策窗口，后者在提醒发出时早已逾期 20 小时。

合理的做法是按任务类型 × 优先级 × 工时区间做规则分桶。比如工时小于 8 小时的任务用“到期前 2 小时提醒”，工时大于 5 天的任务用“到期前 24 小时 + 中断 48 小时提醒”。

3. 误区三：只提醒责任人

研发任务的本质是协作网络。一个任务卡住，往往不是责任人不努力，而是他需要的外部条件没到位。提醒的设计必须覆盖“谁执行、谁依赖、谁验收”三类角色，否则提醒推到的人根本没有解决问题的权限。

实操上可以这样分：执行人收到“你要做什么”，依赖方收到“你挡住了谁”，验收方收到“什么时候需要你验收”。三种提醒，三种文案，三种时间点。

4. 误区四：忽略提醒的打扰成本

打扰是有价格的，而且价格不低。我做过一个粗略估算：一条打断深度工作的通知，平均需要 11 到 15 分钟才能恢复到原来的专注水平。如果一个人一天被无效提醒打断 5 次，等于每天损失近一小时的高质量编码时间。

这个成本从来不会出现在任何一张项目报表里，但它真实存在，并且会以“工程师关闭通知权限”的形式反噬提醒系统本身。

5. 误区五：用 IM 群消息代替任务系统

“@张三 这个需求今天能提测吗？”这类消息在群里很常见，看起来高效，实际上是把流程数据扔进了信息黑洞。责任没有落点，时间没有记录，状态不会回写，下周复盘时谁也说不清到底催过几次、催完有没有动。

我坚持一个原则：IM 可以是提醒的通道，但不能是提醒的终点。所有提醒都必须能追溯到具体任务 ID，并且能在任务系统里找到对应的状态记录。

四、任务提醒自动提醒全流程拆解

1. 第一步：触发条件设计

触发条件是整条流程的起点，也是最容易被做粗糙的一环。我通常把触发分成三类，各有各的适用场景。

• 时间触发：基于截止时间偏移，例如 T-24h、T-0、T+4h。适合有明确截止日的任务，是覆盖最广的一类。
• 事件触发：基于状态变更，例如任务被阻塞、被重新打开、依赖任务完成。适合流程驱动的团队，能抓住最关键的推进时机。
• 状态触发：基于“停滞时长”，例如任务连续 48 小时状态未变。这类触发最容易漏，但恰恰是发现隐性风险最有效的。

（1）判断标准一：每个触发条件都要能回答“为什么是这个时间点”。如果你说不出 T-24h 相比 T-48h 的优势，那这个数字就是拍脑袋来的。

（2）判断标准二：触发条件必须和任务的实际决策窗口对齐。8 小时以内的小任务，提醒窗口不该超过 2 小时；跨迭代的大任务，提前一天提醒才有人真的去调整资源。

2. 第二步：提醒渠道与频率策略

渠道选择不是“哪个好”，而是“哪种打扰程度配得上这条消息的紧急度”。我把五个常用渠道的实测表现整理如下，样本是 6 个团队连续 8 周的数据。

（1）频率策略上，我推荐“一次预告 + 一次到期 + 一次超时”的三段式基线。也就是 T-24h 预告、T-0 到期、T+4h 超时，中间不额外插入提醒。

（2）同一任务单日提醒上限建议设为 2 次。这个数字来自我观察到的响应率拐点：超过 2 次后，响应率开始下降而打扰度快速上升，性价比明显变差。

3. 第三步：升级规则

升级规则是整条流程里最容易被省略、却最能决定成败的一环。它的作用是把“个人遗忘”转换成“组织可见的风险”。没有升级，提醒就永远停留在个人层面。

我常用的三级升级结构是：超时 4 小时回到责任人并强化提示，超时 24 小时升级到直属主管，超时 72 小时升级到项目负责人。每一级升级都要带上上下文：任务卡了多久、卡在什么状态、之前提醒过几次。

（1）升级线要区分任务等级，不能一刀切。P0 缺陷可以设 T+1h 升级，普通需求设 T+24h 都不过分。

（2）升级不是问责，而是暴露阻塞。我要求所有升级通知必须包含“当前阻塞原因”字段，如果责任人填写的是“等待外部资源”，升级的对象应该是那个资源方，而不是责任人本身。

4. 第四步：确认与闭环

这是绝大多数团队缺失的一环。提醒的终点不是“被看到”，而是“状态被更新”。只有当提醒动作能触发一次状态回写，数据才可能沉淀，流程才可能被度量。

我建议的闭环定义是：责任人必须在提醒后完成三个动作中的至少一个，更新任务状态、填写预计完成时间、或者明确标记阻塞并指定解除人。只有完成了这三者之一，这条提醒才算闭环。

5. 第五步：异常处理

流程设计得再完整，也会遇到边界情况。我整理了三类必须提前定义的异常：任务被取消、责任人变更、以及优先级临时调整。

• 任务取消：取消后必须立即终止所有待发提醒，否则用户会收到指向已关闭任务的无效通知，直接损害信任。
• 责任人变更：变更发生时，历史提醒记录应保留在原责任人名下，新责任人只继承未来的提醒节奏，避免把前任的逾期压力直接甩给新人。
• 优先级调整：优先级下调时，提醒频率和升级速度都应同步降级；优先级上调时，应立即重算触发时间点，而不是等下一个周期。

6. 一份可直接抄的配置示例

下面这份配置是我在某中大型研发组织落地时用的简化版，覆盖了触发、渠道、升级、闭环和免打扰五段。字段名做了通用化处理，可以直接映射到大多数任务管理系统的规则引擎。

reminder_rule:
name: "高优先级任务-三段式提醒"

scope:

task_type: [bug, requirement, dev_task]

priority: [P0, P1]

trigger:

type: "deadline_offset"

offset: "-24h"

channel: ["im_card"]

type: "deadline_offset"

offset: "0h"

channel: ["im_card", "email"]

type: "status_stale"

duration: "48h"

channel: ["im_card"]

escalate:

level: 1

after: "4h"

to: "assignee"

payload: ["blocked_reason", "remind_count"]

level: 2

after: "24h"

to: "team_lead"

payload: ["blocked_reason", "due_gap_hours"]

level: 3

after: "72h"

to: "project_owner"

payload: ["history", "dependency_chain"]

closing:

require: "any_of[status_update, eta_update, block_flag]"

record: ["first_remind_at", "first_response_at", "closed_at"]

quiet_hours:

range: "22:00-08:30"

behavior: "aggregate_next_morning"

rate_limit:

per_task_per_day: 2

per_user_per_hour: 3

这份配置里我最想强调的两个字段是 per_task_per_day 和 closing.require。前者防止单任务刷屏，后者强制提醒必须有出口。很多团队把规则写得极其复杂，却漏掉了这两个最关键的约束。

五、研发团队怎么做提醒数据分析

1. 四个核心指标

指标不在多，在于能形成互相制衡的组合。我通常只看四个，前三个衡量效果，最后一个衡量代价。

这四个指标必须一起看。只看逾期率会逼着团队加频率，只看打扰度会逼着团队砍提醒，只有四个一起看，才能找到那个既有效又不扰民的平衡点。

把 12 个团队的数据点投到同一张图上看，逾期率和平均响应时长呈现出非常明显的正相关，而团队规模与逾期率之间反而没有清晰关系。决定提醒效果的从来不是团队大小，而是响应链路的长短。

2. 数据看板怎么搭

看板的第一原则是：一屏之内必须能回答“哪里出问题了”，而不是“数据有多少”。我通常把看板分成三层。

（1）概览层：四个核心指标的当前值与周环比，用子弹图或仪表展示健康区间，一眼能看出哪项飘红。

（2）归因层：按团队、按任务类型、按优先级拆解逾期率与响应时长，找出问题集中在哪一类任务上。

（3）明细层：列出当前处于升级状态的任务清单，附提醒次数、阻塞原因、责任人，供项目经理每周例会直接使用。

下面这张子弹图是我给团队做基线对齐时最常用的形式，它比单纯的数字更直观，一眼能看出距离健康区间的差距。

3. 用对照实验验证提醒是否有效

很多团队调整提醒规则时靠感觉，改完也不知道有没有用。我的建议是：任何一次规则改动，都做一次为期 4 周的对照实验。按团队或按任务类型随机分组，实验组应用新规则，对照组保持原状，其余条件不变。

需要注意三个干扰项：一是迭代周期长度不同会导致基线不可比，建议选择跨度相近的团队；二是线上事故等突发事件会污染数据，需要单独剔除；三是任务复杂度分布要尽量接近，否则逾期率差异可能来自任务本身。

下边是一次真实对照实验的结果，实验组把提醒频率从人均 5.8 条降到 2.4 条，同时补齐了升级规则和闭环要求，四周后的差异相当明显。

4. 数据反哺流程优化

数据最后要落到具体的参数调整上，否则分析就是自娱自乐。我常用的三个调参规则是：

• 响应率低于 60% 的任务类型，优先检查提醒对象是否正确，而不是提高频率。
• 平均响应时长超过 24 小时的任务类型，把升级线整体前移一档，比如从 24 小时改成 12 小时。
• 人均提醒超过 6 条的团队，先做提醒合并与降级，把同一任务的多次提醒聚合成一条摘要。

顺便给一份可以直接改用的取数 SQL，把四个核心指标一次性算出来。这段逻辑我在多个团队用过，兼容大多数主流关系型数据库的时间函数。

— 提醒有效性周报：按团队聚合四个核心指标
SELECT

t.team_id,

COUNT(*) AS task_total,

ROUND(SUM(CASE WHEN t.closed_at > t.due_at THEN 1 ELSE 0 END)

0 / COUNT(*), 4) AS overdue_rate,

ROUND(SUM(CASE WHEN n.first_view_at IS NOT NULL THEN 1 ELSE 0 END)

0 / COUNT(DISTINCT t.id), 4) AS remind_response_rate,

ROUND(AVG(TIMESTAMPDIFF(MINUTE, n.sent_at, n.first_action_at))

/ 60.0, 2) AS avg_response_hours,

ROUND(SUM(n.sent_count) * 1.0 / COUNT(DISTINCT t.id), 2) AS remind_per_task

FROM task t
LEFT JOIN notification_log n ON n.task_id = t.id
WHERE t.created_at >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
AND t.status != 'cancelled'
GROUP BY t.team_id
ORDER BY overdue_rate DESC;

六、工具选型：从“能发提醒”到“能跑流程”

1. 选型 checklist

选型的核心不是看功能列表有多长，而是看它能不能承载你设计的那条流程。我通常会拿这五个问题去测每一个候选工具。

1. 规则引擎是否支持自定义触发条件？能不能配置“状态停滞 48 小时”这种非时间类触发。
2. 升级规则是否可配置？能不能按层级、按时间、按角色设置多级升级。
3. 提醒记录是否可查询？每条提醒的发送时间、查看时间、响应时间能否导出。
4. 是否支持免打扰与频率上限？能不能按人、按任务设置每日上限。
5. 数据能否被外部 BI 消费？有没有开放接口或数据表可以直接取数。

这五个问题里，只要有一个答不上来，这个工具就很难支撑一套完整的提醒闭环。功能演示时看起来都差不多，真正拉开差距的是规则引擎的灵活性和数据可获取性。

2. 小团队轻量方案与中大型团队系统方案

3. 以 PingCode 为例：中大型研发组织的落地路径

在 100 人以上、且有多产品线并行或强合规诉求的组织里，我通常会把 PingCode 放进候选清单重点评估。它主要服务中大型企业及 100 人以上组织，在提醒规则配置、权限体系、跨项目依赖管理和数据开放性上，比较贴近我前面提到的“五问 checklist”。

（1）规则承载能力。它支持按任务类型、优先级、工时区间组合触发条件，也可以基于状态停滞时长触发，这正好对应前文说的第三类触发。对于有跨团队依赖的组织，依赖方提醒是刚需，而不是可选项。

（2）私有化部署。这一点在中大型组织和受监管行业里往往是硬门槛。数据不出内网、可与内部统一身份体系对接，直接决定了安全团队是否放行。

（3）Jira 平滑迁移。我参与过的一次迁移里，最关键的不是任务字段本身，而是历史提醒记录和工作流状态能不能映射过去。如果迁移后提醒规则全部重建、历史响应数据全部丢失，那前面讲的所有度量基线都要从头再攒一遍。

（4）国产化替代场景。在信创和自主可控要求比较明确的行业里，这是一个经常被纳入首选的平台。我的建议是：把“数据能不能导出、能不能自己算指标”作为评估的第一条，而不是先看界面好不好看。

需要说明的是，工具只是承载流程的容器。我见过用通用任务工具把提醒闭环做得非常好的团队，也见过上了功能齐全的平台但只用了“发消息”这一个功能的团队。选型的价值在于降低流程落地的摩擦，而不是代替流程设计本身。

4. 落地三步走：先跑通、再优化、后固化

（1）第一周，跑通最小闭环。只做一件事：所有 P0/P1 任务启用“到期提醒 + 4 小时未响应升级到主管”。规则越少越好，先让团队习惯“提醒是有后果的”。

（2）第二到第四周，补数据。接入四指标看板，但先不调优，只是观察基线。这个阶段最容易犯的错是看到数据难看就立刻大改规则，结果基线被打乱，后面无法判断改动是否有效。

（3）第五周起，做参数调优与固化。按对照实验的方法逐步调整频率与升级线，把验证有效的规则写进团队规范，并在新项目启动时默认继承。

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

1. 5 到 10 人：先解决“有人负责”

这个规模不要上复杂规则。我的建议是只配一条规则：任务到期当天早上 9:30 提醒责任人一次，逾期次日站会上必须口头说明原因。这个阶段最大的价值不是自动化，而是建立“提醒会被追问”的心理预期。

2. 10 到 50 人：把升级规则补上

这个规模通常已经有专职或半专职的项目管理者，痛点从“忘记”变成“推不动”。建议按任务等级配置两到三级升级，并开始记录响应时长。看板上只要有逾期率和响应时长两个指标就足够起步。

3. 100 人以上：必须做数据化和分层

这个规模靠人盯已经不可能了。必须建立四指标看板、按团队和任务类型做归因、按季度做一次对照实验。同时提醒策略要分层：P0 用电话或强提醒，P1 用 IM 卡片，P2 及以下只做聚合摘要。

如果有跨产品线的依赖关系，还要专门设计依赖方提醒，否则跨团队任务会成为逾期的重灾区，这一点在前面的气泡图中体现得很明显。

4. 有私有化或合规诉求：把数据主权放第一位

金融、政务、军工以及部分制造业客户，往往要求数据不出内网、账号对接内部统一身份、操作日志可审计。这类场景下，选型的第一顺位是私有化部署能力和数据导出能力，其次才是提醒功能的丰富度。

因为提醒数据一旦被锁在第三方 SaaS 里无法导出，你连最基本的四指标看板都搭不起来，后面所有优化都无从谈起。

八、不同情况下的取舍

1. 自研提醒系统还是采购成熟平台

自研的唯一合理理由是流程极度特殊，市面产品确实承载不了。但要注意隐性成本：一套能支撑升级规则、频率上限、免打扰、数据回写的提醒系统，工程量远超大多数人的预期，后续每年的维护和迭代投入往往被严重低估。

我的经验判断是：除非提醒逻辑本身就是你们的核心竞争力，否则不要自研引擎。把精力花在规则设计和数据分析上，收益要高得多。

2. 及时性与打扰度

这是一组永恒的矛盾。越及时，打扰越高；越安静，风险越大。我的处理方式是按任务等级分配“打扰预算”：P0 允许高打扰，P1 用中等打扰，P2 及以下一律走低打扰的聚合通道。

如果一定要在两者之间选一个，我建议在早期偏向及时性，先把风险暴露出来；等流程稳定、团队习惯养成之后，再逐步向降低打扰度倾斜。

3. 流程严格度与团队灵活性

规则太严，团队会绕开系统用 IM 沟通，数据反而更差；规则太松，又无法形成约束。我的折中方案是：只在“截止时间”和“状态更新”这两个点上强制，其余环节保持灵活。截止时间强制保证结果可控，状态更新强制保证数据可用，中间怎么干由团队自己决定。

4. 数据精细度与维护成本

指标不是越多越好。每增加一个指标，就多一份解释成本和维护成本，而且很可能没人看。我通常建议起步阶段只保留四个核心指标，等团队真正用起来、开始主动提问的时候，再按问题增量补充维度。

一个可用的判断标准是：如果一个指标连续四周没有出现在任何一次会议讨论中，就把它从看板上撤掉。

九、常见问题解答

1. 提醒发了但没人看，第一步该改什么？

先别改频率，先检查提醒对象和渠道。多数情况下是提醒发给了不负责这件事的人，或者发到了用户已经屏蔽的渠道。把你最近一周的提醒记录导出，看看响应率最低的那一类提醒都发给了谁、通过什么渠道，问题通常一眼就能看出来。

2. 提醒疲劳怎么破？

三个动作：设频率上限、做提醒聚合、把低优先级提醒降级为摘要。具体来说，同一任务每天最多 2 条，同一人每小时最多 3 条，跨任务的低优先级提醒合并成每天一条晨间摘要。

3. 跨部门任务的责任人怎么定？

原则是“一个任务的提醒必须有唯一主责人，但可以有多个干系人”。主责人负责推进和状态更新，干系人只接收与自己相关的提醒，例如“你的接口阻塞了某个任务”。不要让多个部门同时接收同一条提醒，那只会导致责任稀释。

4. 怎么防止“形式闭环”，点一下就算处理完？

两个办法。一是把闭环定义从“点击确认”改成“必须提交状态更新或预计完成时间”，动作有实质内容；二是定期抽查闭环质量，看状态更新后任务是否真的推进了，如果大量任务在“已确认”之后仍然长期停滞，说明闭环定义太松。

5. 免打扰时段该怎么设？

我通常建议设 22:00 到次日 08:30 为免打扰，期间产生的提醒聚合到次日早上统一推送。唯一的例外是 P0 线上事故，这类提醒应当绕过免打扰，但必须严格限定范围，否则例外会迅速变成常态。

6. 上线多久能看到效果？

按我的经验，触达类指标（响应率）通常一周内就能看到变化，因为规则生效很快；但结果类指标（逾期率）一般需要 3 到 6 周，因为它取决于团队行为习惯的改变和流程配合。急着在第二周就下结论，往往会误判效果。

十、总结与下一步行动

回到最开始那个问题：为什么提醒明明做了，情况反而更差？因为大多数团队做的是“通知”，而不是“流程”。自动提醒的真正价值，不在于把消息发出去，而在于把每一次提醒变成一个可被记录、可被升级、可被度量的状态变更事件。

如果只让我留三句话：第一，提醒的终点是状态更新，不是消息送达；第二，没有升级规则的提醒，等于把问题留给最没有权限解决它的人；第三，衡量提醒是否有效，看响应率和打扰度的组合，而不是发送量。

下一步我建议你做三件事，顺序不要颠倒。

1. 今天就能做：导出最近 30 天的提醒日志，算一下响应率和人均日提醒条数。这两个数字出来，你大概就知道自己处在什么位置。
2. 本周内做：给 P0 和 P1 任务补上一条升级规则，就从“超时 4 小时提醒责任人、24 小时升级主管”开始，先跑两周看响应率变化。
3. 本月内做：把四指标看板搭起来，哪怕先用表格手算都行。有了基线，后面每一次规则调整才有可比性，否则你永远在凭感觉优化。

最后留一个问题给你：你们团队现在的人均日提醒条数是多少，提醒响应率又是多少？如果这两个数字你答不上来，那基本可以确定，你们的自动提醒，目前还只是一个消息发送器，而不是一套流程。