> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Lead Cadence Checkbox

> **已被实现取代（2026-09-27）**：本文是 2026-08-05 的方案，保留作为需求来源和讨论记录。当前行为以 [3. Tasks §2.4 跟进节奏](/funding-strategy/02-产品说明书/03-tasks.md#24-跟进节奏自动排期与自动关闭) 为准。与本文的主要差异：
>
> - Lead 跟进到第 60 天为止（不是 90 天），三档间隔 1 / 2 / 3 天，累计上限 4 / 13 / 26 次；线索进入当天只联系一次（不是 3 次）。
> - 员工可以在 Log activity 里手填下一次时间；已约定的员工或 AI 时间会保留，不被节奏覆盖。
> - 「一次接触」（§5.2）按外发计：打了没接也算，来电和收到的消息不算；员工手工记录与 30 分钟内同渠道的 RingCentral 记录重复时只计一次。
> - 跟进机会用完时按规则关闭，但那次联系如果接通了客户本人，任务保持开放，由员工决定下一步。

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

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

> Milly：「确实存在一个特定的跟进节奏，节奏跟不上，热线索就变温、最后彻底沉寂。这不该由销售顾问自己决定，因为不是每个人都知道什么算合适。」
>
> Lucas：「我们前台平均比较年轻，也没干多久。大多数情况下，应该直接按这通电话的实际情况自动定。」
>
> Milly（对现有系统的评价）：「一勾选完成，它就按节奏自动把下一次跟进排出来。」

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

### 0.1 明确不做什么

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

[Lead Line](/product-design/v1/lead-tracker-feature/leadline.md) 是**首次 outreach 的自动拨号执行队列**，与本功能无关，本期不改动。Lead Cadence Checkbox 管的是首次联系之后长达 90 天的人工跟进节奏。

***

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

![OTF Lead Temperature 与 Follow-up Cadence 参考表](/images/OTF/lead-temperature-follow-up-cadence.svg)

| Temperature   | Lead Status                                                  | Time Since Lead Creation      | # of Contacts | Follow-Up Cadence             |
| ------------- | ------------------------------------------------------------ | ----------------------------- | ------------: | ----------------------------- |
| **Red Hot**   | Lead                                                         | 0-3 Days                      |             5 | 第 1 天 3 次、第 2 天 1 次、第 3 天 1 次 |
| **Red Hot**   | Appt Booked / Missed Guest / No Show                         | 0-3 Days                      |             5 | 每天强制联系，直到转化                   |
| **Hot**       | Lead                                                         | 4-21 Days                     |            14 | 每 2 天强制联系 1 次                 |
| **Hot**       | Appt Booked / Missed Guest / No Show                         | 4-21 Days                     |            14 | 每 2 天强制联系 1 次                 |
| **Warm**      | Lead                                                         | 22-60 Days                    |            20 | 每 3 天强制联系 1 次                 |
| **Warm**      | Appt Booked / Missed Guest / No Show                         | 22-60 Days                    |            20 | 每 3 天强制联系 1 次                 |
| **Luke Warm** | Lead                                                         | 61-90 Days                    |            25 | 每周强制联系 1 次                    |
| **Luke Warm** | Appt Booked / Missed Guest / No Show                         | 61-90 Days                    |            25 | 每周强制联系 1 次                    |
| **Cold**      | Lead / Appt Booked / Missed Guest / No Show                  | 91+ Days                      |            30 | 不强制联系                         |
| **Dormant**   | Do Not Contact / Lead / Appt Booked / Missed Guest / No Show | 91+ Days 或状态改为 Do Not Contact |           31+ | 不强制联系                         |

> **来源**：这是 **OTF（Orangetheory Fitness）官方的 Lead 跟进节奏规则**，已收录于 [industry-knowledge/OTF](/industry-knowledge/OTF/lead-temperature-follow-up-cadence.md)。会议中 Milly 提到「开业培训时 Aisha 发过一份跟进节奏表，已转给 Oliver」，指的就是这份；她说的 `orange book` 即 OTF 自己的系统。
>
> 这套方案此前被记录在 [future-plans/lead-contact-cadence.md §1.1.4](/product-design/future-plans/lead-contact-cadence.md)，标注为「下一期参考」。客户已在会议中明确要求按此执行，因此本文将其从 future-plans 提升为 v1 实施基准。

***

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

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

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

```text
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` 两行的节奏**完全相同**。真正的条件分支只有一处：

| Red Hot 档                                 | 节奏                            |
| ----------------------------------------- | ----------------------------- |
| 状态 = Lead                                 | 第 1 天 3 次、第 2 天 1 次、第 3 天 1 次 |
| 状态 = Appt Booked / Missed Guest / No Show | 每天 1 次，直到转化                   |

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

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

***

## 三、字段盘点

### 3.1 已经有的

| 表格所需                     | 我们的现状         | 说明                                                                                   |
| ------------------------ | ------------- | ------------------------------------------------------------------------------------ |
| Time Since Lead Creation | ✅ Lead 创建时间已有 | 直接相减                                                                                 |
| Temperature              | ✅ 无需字段        | 由上一列推导，见 §二                                                                          |
| # of Contacts            | ✅ 接触记录已有      | 口径待确认，见 §五                                                                           |
| Do Not Contact           | ✅ DNC 标记已有    | [leadline.md §10](/product-design/v1/lead-tracker-feature/leadline.md) 已将 DNC 作为硬性拦截 |

### 3.2 Lead Status 的映射与缺口

我们现有 [9 个 Lead Status](/product-design/v1/lead-tracker-feature/lead-funnel-status.md#一lead-的-9-个状态)，与客户表格对照：

| 客户表格                       | 我们的状态                                                                | 是否覆盖             |
| -------------------------- | -------------------------------------------------------------------- | ---------------- |
| Lead                       | New / Attempted / Connected                                          | ✅ 三个都属于「已进入但未预约」 |
| Appt Booked                | Booked                                                               | ✅                |
| **Missed Guest / No Show** | **无独立状态**                                                            | ⚠️ 见下            |
| Do Not Contact             | DNC 标记（独立于 9 状态）                                                     | ✅                |
| —                          | Bad Timing / Not Interested / Unreachable / Lost Contact / Neglected | 表格无对应，按 §四 处理    |

**缺口：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 的核心逻辑

```text
今天该联系吗？

  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) >= 当前档位间隔 → 是
```

勾选后：

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

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

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

***

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

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

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

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

| 档位        | 天数窗口            | 按节奏应有次数         | 累计     | 表格写的   | 是否吻合         |
| --------- | --------------- | --------------- | ------ | ------ | ------------ |
| Red Hot   | 0-3（4 天）        | 3+1+1 = 5       | 5      | 5      | ✅            |
| Hot       | 4-21（18 天）      | 18 ÷ 2 = 9      | 14     | 14     | ✅            |
| **Warm**  | **22-60（39 天）** | **39 ÷ 3 = 13** | **27** | **20** | ❌ **差 7 次**  |
| Luke Warm | 61-90（30 天）     | 30 ÷ 7 ≈ 4      | 24\~25 | 25     | ✅            |
| Cold      | 91+             | 不强制             | 25     | 30     | ⚠️ 多 5，无节奏支撑 |

三档精确吻合，说明这一列**本意就是累计接触次数**。但 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](/product-design/v1/lead-tracker-feature/lead-contact-cadence-v1.md) 已有静默时间规则，应直接复用）
- 周末是否计入间隔天数？

***

## 六、与现有文档的冲突

**[lead-temperature-v1.md](/product-design/v1/lead-tracker-feature/lead-temperature-v1.md) 必须按本表推翻重写。**

|      | 现有文档    | 客户表格             |
| ---- | ------- | ---------------- |
| Hot  | 第 0-1 天 | 第 0-3 天（Red Hot） |
| Warm | 第 2-5 天 | 第 22-60 天        |
| Cold | 第 5 天之后 | 第 91 天之后         |
| 档位数  | 3 档     | 6 档              |

现有版本会让 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）。

***

## 十、最终原则

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

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

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

***

## 参考文档

- [OTF Lead Temperature 与 Follow-up Cadence](/industry-knowledge/OTF/lead-temperature-follow-up-cadence.md) — 本文表格的原始出处
- [Lead 联系节奏设计（完整版）](/product-design/future-plans/lead-contact-cadence.md) — §1.1.4 记录了同一套方案，原标注为「下一期参考」
- [Lead Funnel 与 Status 汇总](/product-design/v1/lead-tracker-feature/lead-funnel-status.md) — 9 个 Lead Status 定义
- [Lead Temperature v1](/product-design/v1/lead-tracker-feature/lead-temperature-v1.md) — **待按本文表格重写**
- [Lead Contact Cadence v1](/product-design/v1/lead-tracker-feature/lead-contact-cadence-v1.md) — 首次响应 SLA 与静默时间规则
- [Lead Line](/product-design/v1/lead-tracker-feature/leadline.md) — 首次 outreach 自动外呼队列，与本功能不重叠