#Task 生成、更新与关闭机制

Historical research / Superseded（2026-07-15）：本文保留旧场景和历史问题，不再定义 Task lifecycle、SLA、Outcome 或 AI authority。现行规范见 Task System Design。

Contact Analysis（Pipeline 2 / contacts-analyzer）按业务目标识别客户当前场景，判定是否需要跟进。分类准则：这次跟进要达成什么业务目的？

---

#第一部分：生成机制

#一、触发方式

Follow-up Task 由 Contact Analysis（Pipeline 2） 生成。Per-Call AI（Pipeline 1）不生成 Task，但可以通过设置 follow_up_needed=yes 触发 Pipeline 2 运行。

为什么 Per-Call AI 不直接生成 Task？ 单通通话的信息量不足以做出可靠的跟进判定。Contact Analysis 综合该客户的全部通话历史、SMS、Contacts 数据，才能准确判断是否需要跟进、跟进什么。Per-Call AI 的角色是实时信号检测——发现需要跟进的信号后触发 Pipeline 2 做综合判定。

#On-Demand Refresh

员工在两次 Cron 之间打了多通电话，想要 AI 立即根据最新通话数据更新任务列表，而不必等到次日凌晨。

架构详情见 AI 插入点行业调研。

---

#二、AI 输出与 Task 字段映射

Contact Analysis 的输出直接映射为 Follow-up Task 的关键字段：

字段定义详见 Task 字段设计；typeCategory 枚举值见 Task 字段设计 §二。

---

#三、优先级判定规则

#3.1 三级优先级与业务目标映射

逻辑：已有营收可能流失 → High；潜在营收可以争取 → Medium；无明确风险或机会的例行跟进 → Low。

#3.2 AI 判定因素

#3.3 优先级 → 截止时间窗口

以上为系统默认值，店铺管理者可在设置中按优先级分别自定义。截止时间需排除静默时间（夜间 9 PM ~ 8 AM）。

截止时间、排序等完整规则见 Tasks Overview §4.1。

---

#四、业务场景

#4.1 新 Lead 首次联系（LEAD OUTREACH）

新 Lead 到达系统，需要在 SLA 窗口内首次联系。由 lead-tracking Lambda 在 Lead 到达时直接创建，不经过 Contact Analysis。

判定依据：系统事件驱动 — 新 Lead 进入系统时由 lead-tracking Lambda 自动创建，source_type='lead'。

#4.2 Lead 持续跟进（LEAD FOLLOW-UP）

Lead 首次联系后未转化，需要持续跟进推动进入下一步。

判定依据：Contact Analysis 综合通话历史判定。leadStatus 为 new / attempted / connected 且未进入 terminal 状态时持续生成。

#4.3 预约后促进成交（BOOKED NOT CONVERTED）

Lead 已预约试课但未完成签约，需要跟进推动转化。

判定依据：Contact Analysis 判定。leadStatus 为 booked / showed / trialed，已过预约时间，且未 converted。

#4.4 促进升级（UPGRADE）

现有会员有升级机会，需要推动升级以提升客单价。

判定依据：通话分析直接判定（会员表达升级意向但未行动、员工推荐升级但客户犹豫）；系统数据判定（消课率高的活跃会员）。

#4.5 投诉挽留（COMPLAINT RETENTION）

客户投诉（主动表达不满），需要跟进直到投诉闭环。

判定依据：通话分析直接判定 — 从通话内容中的问题描述、解决确认、情绪升级等信号分析得出。

#4.6 支付恢复（PAYMENT RECOVERY）

会员支付失败（卡过期、余额不足等），自动重试未成功，需要人工催回更新支付方式。

判定依据：系统数据判定 — 由支付网关返回的失败状态 + 自动重试结果驱动。

#4.7 避免流失（CANCELLATION RISK）

客户出现流失信号，需要主动干预留住客户。

判定依据：通话分析直接判定（表达取消意向、提供了方案、客户说"再想想"）。

#4.8 冻结恢复（FREEZE RECOVERY）

会员冻结即将到期或已到期，需要主动联系确认回归并重新激活出勤习惯。

判定依据：系统数据判定 — 由冻结到期日 + 出勤记录驱动。

#4.9 挽回客户（WIN-BACK）

前会员主动联系或表达回归意向，需要推动重新签约。

判定依据：通话分析直接判定（前会员主动联系）；SMS 内容分析（回复表达兴趣）。

#4.10 活动推广（EVENT PROMOTION）

推动会员报名挑战赛或活动，产生一次性收入。

判定依据：系统数据判定 — 由活动日历 + 会员历史参与记录驱动。

#4.11 特别推广（SPECIAL PROMOTION）

推广客户洽谈或已有推广合作需跟进扩展。

判定依据：通话/SMS 分析判定（企业咨询）；系统数据判定（推广合作到期或季度回顾）。

#4.12 终态（不生成跟进任务）

以下场景 AI 判定 actionNeeded = false，不生成 Follow-up Task。

判定依据：通话分析直接判定 — 均可从通话内容直接分析。

---

#第二部分：更新与关闭机制

#五、员工手动更新

员工可以通过 UI 调整任务的截止时间（dueAt），状态会实时重算：

#状态重算规则

当 dueAt 被调整后，任务状态根据新的截止时间实时重算：

dueAtChangelog 记录每次调整的 from、to、reason、changedBy、changedAt，供管理者审计。

注意：员工调整与 AI 重建的冲突问题（待确认）

Contact Analysis（Pipeline 2）下次运行时会 auto-close 旧 task 并创建新 task。当前实现中，新 task 的所有字段（dueAt、priority 等）均来自 AI 新一轮分析，员工之前的调整（如客户说"下周二再打"导致的 dueAt 变更）不会被带到新 task 里。P2 虽然会读旧 task（用于避免重复创建），但不会读取 dueAtChangelog 中的员工调整记录。

这意味着员工的手动调整可能在 P2 下次运行后丢失。需要与后端确认是否应该：（1）让 AI prompt 包含旧 task 的 dueAtChangelog，使 AI 在分析时考虑员工已做的安排；（2）新 task 在代码层面继承旧 task 中员工手动调整过的 dueAt。

---

#六、关闭方式

Follow-up Task 有两种关闭方式：AI 自动关闭和员工手动关闭。

#6.1 AI 自动关闭（closeType = auto_closed）

AI 自动关闭的典型场景：

#6.2 员工手动关闭（closeType = manual_closed）

员工点击 [Close Task] 按钮，选择一个 businessResult 即可关闭任务。

autoCloseResult 枚举和 businessResult 枚举详见 Tasks 字段设计；营收归因详见 任务与营收归因；关闭流程详见 Tasks Overview §4.2。