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

# Tasks 功能概览

> **Historical product spec / Superseded（2026-07-15）**：本文描述 V1 Workbench，不再定义当前领域模型。现行产品、backend、AI 与 UX contract 见 [Task System Design](/product-design/v3/tasks-feature/task-domain-lifecycle.md)。

***

## 一、定位

**员工的每日工作台（Daily Action Queue）**

Tasks 不是数据分析页面，是一个**执行驱动**的任务列表。员工打开就知道：先做哪个、怎么做、截止时间是什么。

***

## 二、任务来源

V1 先做Lead和AI自动生成，后续支持手动创建。

| 来源     | 说明                                   | V1 |
| ------ | ------------------------------------ | -- |
| Lead   | 基于 SLA 规则，系统自动创建联系任务                 | 是  |
| AI 建议  | Contacts `suggestedActions` 转化为可执行任务 | 是  |
| 员工手动创建 | 员工在通话后手动设置"3 天后再跟"                   | 后续 |
| 管理者指派  | 管理者手动分配任务给员工                         | 后续 |

## 三、Task 任务的两种类型

Tasks 包含两种性质不同的任务：

| 类型                | 性质                    | 触发时机                    | V1 范围      |
| ----------------- | --------------------- | ----------------------- | ---------- |
| **Lead Outreach** | 主动发起，不依赖通话历史          | Lead 进入系统时              | 仅 SLA 首次联系 |
| **Follow-up（跟进）** | 基于已有通话/SMS 判定是否需要后续行动 | 每日凌晨 Cross-Call AI 批量分析 | AI 自行判定    |

***

### 3.1 Lead Outreach 首次联系

Lead 一进入系统，无需等待 AI 分析或通话历史，系统立即根据 SLA 规则生成首次联系任务。这是时间驱动的确定性规则。

| 项目        | 规则                               |
| --------- | -------------------------------- |
| **触发条件**  | Lead 进入系统且从未被联系过                 |
| **时间要求**  | Lead 进入时间 + SLA（默认 5 分钟），受静默时间约束 |
| **静默时间**  | 夜间 9 PM \~ 8 AM                  |
| **店铺自定义** | SLA 可配置 1-30 分钟                  |

详细规则见 [Lead Contact Cadence](/product-design/v1/lead-tracker-feature/lead-contact-cadence-v1.md)。

***

### 3.2 Follow-up（跟进）

每日凌晨批量运行 Cross-Call AI，读取该客户所有通话记录 + SMS + PhoneBook 现有数据，综合判定是否需要跟进。这是 AI 驱动的智能判定。

**Cross-Call AI 判定逻辑**

```
每日凌晨 Cross-Call AI 批量分析
     │
     ▼  读取：该客户所有通话 + SMS + PhoneBook 现有数据
     │
     ▼  输出
     │
     ├── actionNeeded = true
     │     + suggestedActions（具体行动建议列表，每个含 action/reason/priority/priorityReason）
     │     → 生成 Follow-up Task
     │
     └── actionNeeded = false
           → 不生成任务
```

***

## 四、任务展示

> **UI Prototype 参考**：[UI Prototype — Tasks 页面](../../../ui-design/ui-mvp.md)

### 4.0 状态分组

任务按 Open / Closed 两大类展示，每类再细分子状态。**顶部汇总区**和**下方卡片列表**均按此分组呈现：

**Open — 3 个子状态**

| 子状态          | 含义                 |
| ------------ | ------------------ |
| **Pending**  | 截止时间充裕，尚未进入紧迫区间    |
| **Due Soon** | 接近截止时间（阈值见 §4.1.1） |
| **Overdue**  | 已超过截止时间，需立即处理      |

**Closed — 2 个子状态**

| 子状态               | 含义                               |
| ----------------- | -------------------------------- |
| **Auto-closed**   | AI 分析判定任务不再需要执行，系统自动关闭（见 §4.1.3） |
| **Manual-closed** | 员工或管理者手动关闭任务（完成执行或主动取消，需填写原因）    |

顶部汇总区显示各子状态的任务数量；卡片列表按子状态分组排列，员工一眼即可定位需要优先处理的任务。

### 4.1 任务时间维度

#### 4.1.1 任务截止时间生成逻辑

| 任务类型              | 截止时间生成逻辑                                       | 示例                                 |
| ----------------- | ---------------------------------------------- | ---------------------------------- |
| Lead 节奏（SLA 首次联系） | Lead 进入时间 + SLA（默认 5 分钟），受静默时间约束               | Lead 10:00 AM 进入 → due by 10:05 AM |
| Follow-up（High）   | 任务生成时间 + High 截止窗口（默认 **4 小时**，可配置），受静默时间约束    | 上午 10:00 生成 → due by 下午 2:00       |
| Follow-up（Medium） | 任务生成时间 + Medium 截止窗口（默认 **24 小时**，可配置），受静默时间约束 | 上午 10:00 生成 → due by 明天上午 10:00    |
| Follow-up（Low）    | 任务生成时间 + Low 截止窗口（默认 **72 小时**，可配置），受静默时间约束    | 上午 10:00 生成 → due by 3 天后上午 10:00  |

任务截止时间由 `suggestedActions[].priority`（取最高优先级）决定，按优先级对应不同的截止窗口，再排除静默时间得出最终截止时间。

> 以上截止窗口为系统默认值，店铺管理者可在设置中按优先级分别自定义。

#### 4.1.2 Due Soon 阈值生成逻辑

| 任务类型                     | Due Soon 阈值   | 说明                                     |
| ------------------------ | ------------- | -------------------------------------- |
| Lead 节奏（SLA 首次联系）        | **2 分钟**（可配置） | SLA 默认 5 分钟，进入 Due Soon 后员工仅剩 2 分钟行动窗口 |
| Follow-up（Cross-Call AI） | **1 小时**（可配置） | Follow-up 截止时间通常以小时/天为单位，1 小时提醒合理      |

> 以上为系统默认值，店铺管理者可在设置中自定义 Due Soon 阈值。

#### 4.1.3 Open任务状态

系统用建议截止时间、Due Soon 阈值判定Open任务的状态:

| 任务状态         | UI 分组名   | 判定规则                                 | 驱动方式   |
| ------------ | -------- | ------------------------------------ | ------ |
| **Pending**  | PENDING  | 当前时间 \< 任务截止时间 - Due Soon 阈值         | 时间自动计算 |
| **Due Soon** | DUE SOON | 任务截止时间 - Due Soon 阈值 ≤ 当前时间 ≤ 任务截止时间 | 时间自动计算 |
| **Overdue**  | OVERDUE  | 当前时间 > 任务截止时间                        | 时间自动计算 |

#### 4.2 任务关闭规则

**一、AI 自动关闭（closeType = auto\_closed）**

AI 通过两层分析判定任务是否需要自动关闭，无需员工手动操作：

| 分析层                          | 触发时机                    | 关闭场景示例                   | 判定依据                            |
| ---------------------------- | ----------------------- | ------------------------ | ------------------------------- |
| **Layer 1 — Per-Call AI**    | 每通电话/SMS 结束后实时分析        | 客户在来电中已完成预约、客户明确表示不感兴趣   | 单通通话/SMS 内容直接判定                 |
| **Layer 2 — Daily Batch AI** | 每日凌晨批量分析（Cross-Call AI） | 综合多通电话判定客户已成交、客户多次拒绝达到终态 | 该客户所有通话 + SMS + Contacts 数据综合判定 |

AI 自动关闭的典型场景：

| 触发场景                   | 说明                                                                                                       | 检测来源                   |
| ---------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------- |
| 客户主动来电/来 SMS 且目标已达成    | 客户已主动完成了任务目标对应的动作，跟进任务不再需要                                                                               | Layer 1 Per-Call AI    |
| 客户明确拒绝（Not Interested） | AI 判定为绝对拒绝（详见 [Lead Temperature](/product-design/v1/lead-tracker-feature/lead-temperature-v1.md)），停止一切跟进 | Layer 1 / Layer 2      |
| 客户通过其他渠道已完成行动          | 如客户自行线上预约、已到店等，AI 从后续通话中推断                                                                               | Layer 2 Daily Batch AI |

**二、手动关闭（closeType = manual\_closed）**

员工或管理者点击 \[Close] 按钮，选择一个 `businessResult` 即可关闭任务。选择 No Outcome 时需填写 `closeNote` 说明原因。详细流程见 §4.4.2。

### 4.2 任务重要性维度

时间维度回答"什么时候做"，重要性维度回答"同时有多个任务时先做哪个"。两者正交，共同决定任务在列表中的位置。

#### 4.2.1 三级优先级

| 优先级        | 含义                | 判定标准                  |
| ---------- | ----------------- | --------------------- |
| **High**   | 收入直接受威胁，或转化窗口即将关闭 | 不做 = 丢客户 / 丢收入        |
| **Medium** | 存在转化机会，但窗口相对宽裕    | 不做 = 错失推进机会，但客户不会立刻流失 |
| **Low**    | 常规维护性跟进，无即时风险     | 不做 = 节奏变慢，但短期无负面后果    |

#### 4.2.2 优先级判定规则

**Lead Outreach 任务**：统一为 **High**。首次联系的 5 分钟黄金窗口本身就代表最高紧迫性（研究显示延迟 5 分钟后转化率下降 8 倍）。

**Follow-up 任务**：由 Cross-Call AI 根据通话上下文判定，输出 `suggestedActions[].priority` 字段（High / Medium / Low）。AI 判定依据：

| 判定因素     | High                | Medium        | Low           |
| -------- | ------------------- | ------------- | ------------- |
| **收入风险** | 会员有取消意向、合同到期未续      | —             | —             |
| **漏斗位置** | 试课后未成交（离签约最近）       | 触达后未预约、爽约待重约  | 留了语音信箱、"下周再聊" |
| **时间窗口** | 黄金窗口内（爽约当天、试课后 24h） | 窗口还有余量（1-3 天） | 无明确窗口压力       |
| **客户信号** | 客户主动询价、明确表达兴趣       | 有过互动但意向不明     | 无回应、需要再次触达    |

### 4.3 任务排序

排序综合时间维度和重要性维度，规则按优先级从高到低：

| 排序层级      | 规则                                        | 说明                    |
| --------- | ----------------------------------------- | --------------------- |
| **第 1 层** | Overdue 置顶                                | 已逾期的任务永远排在最前面，无论优先级高低 |
| **第 2 层** | 同为 Overdue → 按优先级排（High > Medium > Low）   | 多个逾期任务中，收入风险高的先处理     |
| **第 3 层** | 同为 Overdue 且同优先级 → 按逾期时长降序                | 逾期越久的排越前              |
| **第 4 层** | 非 Overdue 任务 → 按优先级排（High > Medium > Low） | 优先级是主排序键              |
| **第 5 层** | 同优先级 → 按截止时间升序                            | 截止时间越近的排越前            |

排序示例：

```
1. [Overdue] [High]   试课后未成交 — 逾期 3h
2. [Overdue] [High]   爽约跟进 — 逾期 1h
3. [Overdue] [Medium] 触达后未预约 — 逾期 30min
4. [Due Soon] [High]  新 Lead Outreach — 还剩 2min
5. [Ongoing] [High]   取消意向会员 — 还剩 4h
6. [Ongoing] [Medium] 留了语音信箱 — 还剩 1天
7. [Ongoing] [Low]    "下周再聊" — 还剩 5天
```

### 4.4 任务卡片

每张任务卡片展示员工执行所需的最少信息，目标是**看一眼就能行动**。

> 字段定义详见 [Task 字段设计](/product-design/v1/tasks-feature/tasks-field-design.md)。

#### 4.4.2 关闭流程

员工点击 \[Close] 后，一步完成关闭：

```
点击 [Close]
     │
     ▼  选择业务结果（businessResult）
     │
     ├── Converted / Upgraded / Complaint Resolved / ...  → 直接关闭
     │
     └── Other            → 填写 closeNote（free text）→ 关闭
```

> 业务结果与营收归因的详细映射见 [任务与营收归因](/product-design/v1/tasks-feature/revenue-attribution.md)。

***

## 五、与其他文档的关系

| 文档                                                                                         | 关系                                                        |
| ------------------------------------------------------------------------------------------ | --------------------------------------------------------- |
| [Contacts 字段设计 §2.9](/product-design/future-plans/contacts-field-design.md)                | 定义 `ActionNeeded`、`suggestedActions`、`customerSummary` 字段 |
| [Lead Contact Cadence](/product-design/v1/lead-tracker-feature/lead-contact-cadence-v1.md) | 定义 SLA 计算规则，约束 Lead 节奏的时间要求                               |
| [Lead Temperature](/product-design/v1/lead-tracker-feature/lead-temperature-v1.md)         | 定义降温规则和 Cold 后终态判定                                        |
| [Task 字段设计](/product-design/v1/tasks-feature/tasks-field-design.md)                        | 定义 Task 表的 26 个字段、枚举值、UI 映射（本文档的数据模型实现）                   |
| [Tasks Feature 设计](/product-design/v1/tasks-feature/tasks-field-design.md)                 | 定义任务列表 UI 和交互（本文档的输出消费方）                                  |
| [Follow-up Task 生命周期](/product-design/v1/tasks-feature/task-lifecycle.md)                  | Task 生成、更新与关闭机制（从本文档 §3.3 独立）                             |
| [任务与营收归因](/product-design/v1/tasks-feature/revenue-attribution.md)                         | 定义任务完成结果如何映射到 MRR 营收指标（从本文档独立）                            |
| [跟进机制](../../../industry-knowledge/follow-up-mechanism.md)                                 | 行业知识：6 种电话类型的跟进规则参考                                       |
