#Lead Cadence Checkbox

#零、这份文档要解决什么

客户在会议中反复表达的诉求是同一件事：跟进节奏不该由销售顾问自己判断。

Milly：「确实存在一个特定的跟进节奏，节奏跟不上，热线索就变温、最后彻底沉寂。这不该由销售顾问自己决定，因为不是每个人都知道什么算合适。」

Lucas：「我们前台平均比较年轻，也没干多久。大多数情况下，应该直接按这通电话的实际情况自动定。」

Milly（对现有系统的评价）：「一勾选完成，它就按节奏自动把下一次跟进排出来。」

因此本期交付的不是一个跟进管理模块，而是一个勾选框：员工看到「今天该联系谁」，打完勾掉，系统自己排下一次。人不做任何时间判断。

#0.1 明确不做什么

本期不做：多渠道触达编排、跟进节奏的自定义编辑器、AI 决定跟进时间、跟进效果 A/B 测试、与 Lead Line 自动外呼的联动。

Lead Line 是首次 outreach 的自动拨号执行队列，与本功能无关，本期不改动。Lead Cadence Checkbox 管的是首次联系之后长达 90 天的人工跟进节奏。

#一、跟进节奏表（OTF 官方规则）

来源：这是 OTF（Orangetheory Fitness）官方的 Lead 跟进节奏规则，已收录于 industry-knowledge/OTF。会议中 Milly 提到「开业培训时 Aisha 发过一份跟进节奏表，已转给 Oliver」，指的就是这份；她说的 orange book 即 OTF 自己的系统。

这套方案此前被记录在 future-plans/lead-contact-cadence.md §1.1.4，标注为「下一期参考」。客户已在会议中明确要求按此执行，因此本文将其从 future-plans 提升为 v1 实施基准。

#二、这张表拆开只有一个分支

表面上是两个维度（Temperature × Lead Status），实际上：

一、Temperature 完全由天数决定，不是需要维护的字段。

temperature = f(today - lead_created_at)

  0-3   → Red Hot
  4-21  → Hot
  22-60 → Warm
  61-90 → Luke Warm
  91+   → Cold

它是一个纯日期减法，不需要状态机、不需要定时任务翻转、不需要落库。任何时刻按需计算即可。

二、Lead Status 只在 Red Hot 一档起作用。

从 Hot 往下，Lead 和 Appt Booked / Missed Guest / No Show 两行的节奏完全相同。真正的条件分支只有一处：

三、Dormant 不是算出来的，是状态触发的。

Do Not Contact 直接进 Dormant，与天数无关。

#三、字段盘点

#3.1 已经有的

#3.2 Lead Status 的映射与缺口

我们现有 9 个 Lead Status，与客户表格对照：

缺口：No Show 被折叠进了 Connected。

我们的定义是「触达成功但未预约，或者预约后 No show，跟进推动预约」——两种情况共用 connected 一个值。但客户表格在 Red Hot 档给了 No Show 更激进的节奏（每天联系 vs 3-1-1），折叠后这个区分会丢失。

处理方式二选一，建议选 A：

• A（本期推荐）：不改 schema。Red Hot 档下，凡是曾经有过 Booked 记录的 Lead（无论当前是 Connected 还是 Booked），一律走「每天 1 次」。用历史事件判断，不用当前状态判断，零 schema 改动。
• B（推迟）：新增独立的 no_show 状态。涉及状态机、UI、报表多处改动，不适合本期。

#3.3 需要新增的

只有一个字段：上次接触时间（last_contact_at）。如果接触记录表已能可靠取到「该 Lead 最近一条接触记录的时间」，则连这个字段都不用加，直接查即可。

#四、Checkbox 的核心逻辑

今天该联系吗？

  1. status ∈ {Do Not Contact, Not Interested, Unreachable,
               Lost Contact, Neglected}     → 否，永久退出
  2. status = Bad Timing                    → 否，暂停中（条件变化后重新激活）
  3. temperature ∈ {Cold, Dormant}          → 否，不强制联系
  4. contact_count >= 当前档位上限           → 否，本档已跑满
  5. (today - last_contact_at) >= 当前档位间隔 → 是

勾选后：

勾掉
  → 写入一条接触记录（含时间、员工、渠道）
  → contact_count + 1
  → last_contact_at = 现在
  → 下一次应联系日期 = 现在 + 当前档位间隔（跨档时用新档间隔）

Red Hot「第 1 天 3 次」是唯一的一天多次特例。 其余档位都是「每 N 天 1 次」。实现上把 Red Hot 第 1 天单独处理为「今日配额 3 次」，其余按日期间隔计算即可。

员工不输入任何时间。 界面上不出现日期选择器，不出现「改到几天后」的输入框。这是本功能的全部意义。

#五、必须先跟客户确认的三件事

这三件事不确认，数就算不对。建议一次性发给 Oliver。

#5.1 # of Contacts 这一列自己对不上（阻塞）

按每档的间隔和天数反推累计接触次数：

三档精确吻合，说明这一列本意就是累计接触次数。但 Warm 那档差了 7 次——这是 OTF 官方表自身的不一致，不是转录或抄写错误。可能的解释：

• Warm 的实际窗口不是 22-60 天（若为 22-39 天则正好 20 次）；
• 或 # of Contacts 在此列是「上限」而非「预期完成数」；
• 或 Warm 的实际间隔不是每 3 天。

必须问清楚：这一列是「跑满该档应完成的累计次数」，还是「累计次数上限，到了就停」？这直接决定勾选框什么时候不再出现该 Lead。

#5.2 「一次接触」算什么（阻塞）

只算接通的电话？打了没接也算？短信、邮件算不算？

影响极大：Red Hot 第 1 天要 3 次，如果只算接通，绝大多数 Lead 第一天就完不成配额，会立刻堆积成逾期。

建议默认口径：一次去电尝试即计一次（与表格 Forced contact 的字面含义一致），接通与否单独记录。但需客户确认。

#5.3 温度会不会被事件重置（阻塞）

Lead 回电了、约了到店，温度是回到 Red Hot 还是继续按天数往下走？

从表格结构看应是继续按天数走（Appt Booked 也仍按天数分档，没有单独的重置说明）。若确认如此，则温度就是纯日期函数，不需要存任何时间戳——这是最省事的结论。若客户说「约了就该重新算」，则需引入 cadence_anchor_at，工作量增加。

#5.4 次要问题（不阻塞，可上线后补）

• Cold 档写 30 次但「不强制联系」，多出的 5 次从何而来？Dormant 的 31+ 是否意味着「累计超过 30 次即转 Dormant」？
• 强制联系是否受营业时间和 TCPA 夜间禁联约束？（lead-contact-cadence-v1.md 已有静默时间规则，应直接复用）
• 周末是否计入间隔天数？

#六、与现有文档的冲突

lead-temperature-v1.md 必须按本表推翻重写。

现有版本会让 Lead 五天就被系统判定为冷，比客户认知早了近三个月。这不是参数差异，是量级差异。有了客户认可的基准表，不应再使用自拟版本。

现有文档中「Cold 后自动判定 Unreachable / Neglected 两个终态」的机制可以保留，只需把触发点从第 5 天改为第 91 天。这个机制恰好回应了 Lucas 担心的「年轻员工不知道该做什么」——Neglected 就是「该跟没跟」的自动记账。

#七、这张表顺带解决了「列表打不完」的担心

Nadia 提出的顾虑：

「我想确保它看起来不会是几百几百条。你打开待办列表，看到 40 条和看到 340 条，是两种完全不同的心态——前者是『我把这些电话打完』，后者是『这玩意儿永远打不完』。」

本表自带答案：Cold 与 Dormant 都是「不强制联系」。第 91 天起，Lead 不再产生强制跟进条目。数据仍在库里可查，但不占用每日待办。

这正是 Lucas 的说法：「不是消失，只是不再排在最前面。」

因此本功能的待办列表天然有界：只有 0-90 天内、且当日到达间隔的 Lead 才会出现。不需要额外的清理机制。

#八、实施顺序

#P0（本期上线）

1. 温度推导函数（纯函数，含单元测试覆盖 6 档边界值）；
2. 接触记录写入与 contact_count 累计；
3. 「今天该联系」判定规则（§四五条）；
4. 勾选框 UI：列表 + 勾选 + 勾选后即时移出当日列表；
5. Red Hot 第 1 天 3 次配额的特例处理；
6. 复用现有 DNC 硬性拦截与静默时间规则。

#P1（上线后）

1. 逾期条目的展示（昨天该打没打的）；
2. Neglected 自动判定接到第 91 天；
3. 跟进节奏参数的门店级配置；
4. 完成率指标：各档位应联系数 / 实际联系数。

#九、验收不变量

1. Temperature 必须由 today - lead_created_at 实时推导，不得落库为可变状态；
2. 温度档位边界必须与本文表格逐日对齐（0-3 / 4-21 / 22-60 / 61-90 / 91+）；
3. Red Hot 档下曾有 Booked 记录的 Lead 走「每天 1 次」，其余走 3-1-1；
4. Hot 及以下档位不得因 Lead Status 不同而使用不同间隔；
5. Do Not Contact 必须立即进入 Dormant，与天数无关；
6. Cold 与 Dormant 不得产生强制跟进条目；
7. 终态（Not Interested / Unreachable / Lost Contact / Neglected）必须退出跟进节奏；
8. Bad Timing 暂停期间不产生条目，重新激活后按当前天数重新计算档位；
9. 员工界面不得出现任何日期或时间输入控件；
10. 勾选必须原子写入接触记录，不得只改计数不留记录；
11. 重复勾选必须幂等，不得重复累加 contact_count；
12. 下一次应联系日期必须由服务端计算，前端不得自行推算；
13. 跨档时必须使用新档位的间隔，不得沿用旧间隔；
14. 所有查询与计数按 store_id 隔离；
15. 静默时间与 DNC 必须在生成条目前作为硬性拦截；
16. # of Contacts 口径确认前，不得上线「跑满即停」的自动退出逻辑（见 §5.1）。

#十、最终原则

Lead 创建日期
  → 温度（纯日期函数）
  → 该档位的间隔与上限
  → 距上次接触是否已达间隔
  → 今天该不该联系
  → 勾掉 → 自动排下一次

员工只回答一个问题：打完了没有。

其余全部由规则决定。这就是客户说的「不该由销售顾问自己决定什么算合适」——把判断从人身上拿走，是这个功能的全部价值，也是它必须保持简单的原因。

#参考文档

• OTF Lead Temperature 与 Follow-up Cadence — 本文表格的原始出处
• Lead 联系节奏设计（完整版） — §1.1.4 记录了同一套方案，原标注为「下一期参考」
• Lead Funnel 与 Status 汇总 — 9 个 Lead Status 定义
• Lead Temperature v1 — 待按本文表格重写
• Lead Contact Cadence v1 — 首次响应 SLA 与静默时间规则
• Lead Line — 首次 outreach 自动外呼队列，与本功能不重叠