# 疗效保障(PAC)项目 W1 进展报告

> **报告周期**:第 1 周(W1)· 首次汇报
> **汇报路径**:PAC(luoqi)→ CTO(于总)→ 管委会
> **报告人**:luoqi
> **状态**:🟢 按计划推进
>
> 所有决策、跨团队对齐、资源协调统一通过 CTO 推动。

---

## Page 1

### ▎本周一句话

> **PAC 疗效保障项目 W1 完成"框架定稿 + 评审 closure",进入并行实施阶段。W3 末将交付第一批可评估的业务结果。**

### ▎核心成果

```
✅ PAC 三层业务模型确立(患者事实 → 患者画像 → 召回计划)
✅ 数据库结构 60+ 评审决议项 100% closure
✅ PAC 自身业务边界明确(做什么 / 不做什么)
🟡 DW 对接文档 W2 启动
```

### ▎里程碑预告

```
🎯 W2 末:数据源对接文档发出 + Mock 数据集启动 + 数据骨架定型
🎯 W3 末:患者画像出来(基于 Mock 数据)+ 画像页面 v1
⭐ W4 末:召回名单 + 排序解释 + AI 话术 + 一页摘要(管委会评估节点 1)
🎯 W5 末:客服工作台扩展 + 数据源真实接入启动
🎯 W6 末:演示版 + 1 家试点最小数据接入
```

### ▎本周需推动决策(通过 CTO 协调)

```
🆘 业务方拍板召回算法策略(最高优先级)
🆘 协调试点门诊提供 100-300 个脱敏患者样本(W2 内)
🆘 DW 团队对接(W2 末文档定稿后由 CTO 转交,不阻塞 PAC 内部开发)
```

详见 Page 7

---

## Page 2 · 项目使命(Mandate)

### ▎为什么做(目的)

```
集团老客户流失 + 复购转化低,是各试点门诊持续运营的共性痛点。

PAC 把"该打谁、为什么、怎么打"自动化,
让客服每个电话打在刀刃上,把流失客户带回诊所。
```

### ▎一期场景(具体 Use Case)

| 维度 | 内容 |
|---|---|
| **业务场景** | 治疗链已完成患者召回(根管 / 正畸 / 种植后未复查的老客户) |
| **试点门诊** | 杭州大厦 / 杭州高德 / 无锡学前街 / 上海世纪公园 / 北京朝阳公园 |
| **本期周期** | 6 周框架就绪 + 演示;后续 4-6 周试点跑通 |
| **量级 / 基线** | 患者档案量 / 现有流失率 / 复购率(待业务方提供,用于评估 PAC 提升幅度) |

> 注:本期场景以 PDF 钦定"疗效保障召回"为基础,业务方可在 W2 内拍板扩展到"漏诊召回"或两者并行(详见 Page 7 #0)。

### ▎PAC 跟传统召回的差异（优势）

| 维度 | 传统召回 | PAC 召回 |
|---|---|---|
| **派单逻辑** | 客服自己想"今天打谁" | PAC 自动给优先级清单 |
| **话术准备** | 靠经验,新客服难上手 | AI 生成参考话术 + 一页患者摘要 |
| **跨诊所视角** | 各诊所看自己 | 集团统一画像,跨店就诊连续追踪 |
| **效果评估** | 主管经验判断 | 数据可追溯、可审计、可复盘 |
| **合规边界** | 各诊所独立 | 不打扰名单全集团生效 |

### ▎召回四大高价值场景(业务视角)

| # | 场景 | 业务价值 | 召回属性 |
|---|---|---|---|
| 1 | **根管未戴冠** | 立刻转化数千营收 + 防止后续拔牙 → 种植 | 漏诊召回(选项 B) |
| 2 | **正畸中断 / 保持器期** | 防高客单流失(单客 1.5-8 万)+ 防反弹投诉 | 疗效保障(选项 A) |
| 3 | **种植年度复查** | 防种植失败 + 锁定终生维护 + 后续多颗种植机会 | 疗效保障(选项 A) |
| 4 | **牙周维护期** | 长尾高频复购(3-6 个月一次)+ 防复发 | 疗效保障(选项 A) |

> 选项 A 主抓 #2/#3/#4;选项 B 主抓 #1;**选项 C 并行覆盖全部 → 完整召回闭环**(详见 Page 7 #0)。

### ▎给用户的价值

| 用户 | 得到什么 |
|---|---|
| **客服** | 上工就有"今天该打谁"的清单 + 现成话术摘要;新客服不靠师傅带也能上手 |
| **诊所主管** | dashboard 看团队转化率分布、找出短板 |
| **患者** | 接到的不是骚扰,是"医生关心你的复查"——客户体验提升 |
| **集团** | 老客户激活率提升 → 复购营收 + 防止流失到他家诊所 |

### ▎评判 KPI — PAC vs 人为 实际可量化提升

| KPI | 现状(人为) | PAC 预期 | 提升机制(PAC 凭什么) |
|---|---|---|---|
| **召回转化率**(接通后预约成功比例) | 基线待业务给 | 显著提升 | 算法选高价值客户 + AI 个性化话术 |
| **召回客单价**(转化客户带来营收) | 多为小复查 / 洗牙 | **1.5-2x**(抓根管 / 种植 / 正畸高客单) | 精准识别"该治未治"的高价值漏诊 |
| **客户挽回率**(沉睡 >90 天回诊比例) | 基线待业务给 | 显著提升 | 跨诊所画像识别真流失,跨店连续追踪 |
| **客服准备时间**(单个电话准备) | ~30 分钟 / 单 | **~5 分钟 / 单**(6x 提速) | One Page Summary + AI 话术,不用翻档案 |
| **客服日均有效外呼 / 转化** | 基线待业务给 | **1.5-2x** | 准备时间压缩 + 优先级清单准 |
| **新客服上手时间** | 1-2 月(老带新) | **1-2 周**(系统辅助) | 系统给摘要 + 话术,不靠师傅经验 |

> 注:具体百分比提升幅度待 W7+ 试点期实测(需业务方提供基线数据)。

---

## Page 3 · 总体计划 + 当前位置(并行工作流)

### ▎6 周里程碑

```
W1  ━━━━━━━━━━━━━━━━━━ ✅ 框架定稿 + 评审 closure
W2  ▶━━━━━━━━━━━━━━━━━ 🟡 数据源对接文档 + Mock 数据集 + 数据骨架定型
W3  ───━━━━━━━━━━━━━━━ 🎯 数据摄入跑通 + 患者画像 + 画像页面
W4  ──────━━━━━━━━━━━━ ⭐ 召回名单 + AI 话术 + 摘要(评估节点 1)
W5  ─────────━━━━━━━━━ 🎯 客服工作台扩展 + 数据源真实接入启动
W6  ────────────━━━━━━ 🎯 演示版 + 1 家试点最小接入
W7+ ────────────────── ⏳ 试点跑通(需 DW + 客服培训配合)
```

### ▎并行四条线(单人 + AI 也能并行)

```
线 1(异步)│ DW 对接 ──[W2 文档定稿/CTO 转交]──[DW 排期/PAC 不阻塞]──[W5+ 切真实数据]──▶

线 2(干)│ PAC 后端:schema → ingest → Persona → Plan → Agent ━━━━━▶

线 3(协)│ Mock 数据集 ──[脱敏样本]──[典型病例集]──▶
                ↑W2                          ↑W3 投入使用

线 4(干)│ 工作台前端:骨架 ─→ Mock v1 ─→ v2(含话术)─→ v3(完整工作台)
                ↑W2         ↑W3        ↑W4              ↑W5
```

### ▎关键里程碑

| 里程碑 | 时间 | 业务可见性 |
|---|---|---|
| **画像初见** | 🎯 W3 末 | 患者画像页面 v1(可点击,基于 Mock 数据) |
| **管委会评估节点 1** | ⭐ **W4 末** | 完整业务流 Mock 演示(画像 + 召回名单 + AI 话术 + 一页摘要),可点评算法 + 话术质量 |
| **第一家试点接入** | 🎯 W6 末 | 真实数据切换 + 角色扮演试点 |

---

## Page 4 · W1 具体成果
### ▎三层业务模型(本周确立的核心架构)

```
第一层 患者事实层      第二层 患者画像层       第三层 召回计划层
─────────────────     ─────────────────      ─────────────────
门诊真实业务事件    →   PAC 自动评价患者    →    生成召回名单 + 话术
(看诊/治疗/缴费)        (价值/复查风险等)        (谁该打/打什么/怎么打)
```

**业务含义**:**患者数据进 → PAC 自动算 → 召回名单出**,数据驱动取代经验决策。

### ▎评审 closure 数据

| 维度 | 数量 | 状态 |
|---|---|---|
| schema设计原则 | 8 条 | 已对齐 |
| 框架核心实现点 | 8 条(对应 PDF 验收口径) | 已 closure |
| 数据库评审决议项 | ~60 项 | 已 closure |
| 提议响应确认单 | 1 份(待反馈) | 🟡 W2 必拍板 |

### ▎PAC 业务边界(本周明确)

**PAC = 集团级"召回算法大脑",不替代任何业务系统,通过接口跟宿主协作**

| ✅ PAC 做 | ❌ PAC 不做(留给宿主) |
|---|---|
| 接收患者事实(治疗 / 预约 / 缴费) | 替代 5i5ya / Friday 召回任务执行 |
| 自动评价患者(画像 / 风险 / 价值) | 控制企微 / 外呼 / SCRM 触达通道 |
| 生成召回名单 + 优先级 + 召回原因 | 持有完整病历原文(EMR) |
| AI 生成参考话术 + 一页患者摘要 | 主权影像 AI / 影像诊断 |
| 接收执行结果回写 | 持有支付能力 / 直连患者 |
| **对外输出集团级患者画像数据**(供宿主自有 dashboard / 业务决策消费) | |

**协作模式**:PAC 输出召回结果 + 患者画像数据给宿主消费,宿主返回事实 + 执行结果。PAC 不直连患者、不直连客服界面、所有动作通过宿主中转。

**PAC 复用价值**:画像层是集团级资产,**不仅服务召回场景**——宿主可消费用于客户分层运营、流失预警、VIP 识别、营销精准触达等多场景。

### ▎本周关键设计决策

| 决策 | 设计要点 |
|---|---|
| 患者身份模型 | 集团内同名同手机的"跨诊所患者"系统认得是同一人,画像合一 |
| 合规边界 | 不打扰名单挂在患者身上(不是诊所),全集团一标全集团生效 + 审计透明化 |
| 证据链 | 每条召回都能反查依据(规则 / Agent / 历史事实 / 版本号)|
| 召回归属 | 支持"主诊所归属 / 集团统一客服池 / VIP 中心"多种业务模式自由切换 |

---

## Page 5 · W2-W4 计划(面向 W4 评估节点)

### ▎W2交付清单

```
✅ 必交付
1. 数据源对接文档发出 → 启动 DW 团队排期
2. Mock 数据集启动:
   - 协调试点门诊脱敏样本 100-300 个
   - 兜底典型病例集合 50-100 个
3. 数据骨架定型(等 confirm 反馈)

🎯 本周关键风险
- 业务方拍板召回算法策略(影响后续整个评估节点价值)
```

### ▎W3 计划

```
✅ 必交付
1. 数据摄入跑通(Mock 数据 → 系统内)
2. 患者画像出来 — 4 个起步特征(基于 Mock):
   - 客户价值
   - 治疗链状态
   - 触达活跃度
   - 复查风险
3. 画像页面 v1(可点击,展示画像卡片)

🎯 演示给管委会
- 100+ mock 患者画像卡片
- 业务方可点评"画像准不准"
```

### ▎W4 ⭐ 评估节点

```
✅ 必交付
1. 召回名单生成(基于 mock 数据)
2. 排序解释 → 每个患者"为什么排这个优先级"
3. AI 参考话术(每个召回任务一段)
4. 一页患者摘要
5. Mock 召回页面 v2(完整业务流可点击)

🎯 演示给管委会(管委会评估节点 1)
- 浏览器打开页面 → 走完一个完整业务流
- 100+ 召回名单 + 优先级 + 召回原因 + AI 话术 + 摘要
- 业务方可点评算法质量 + 话术质量
```

**W4 末是首个让管委会能给业务反馈的完整节点。**

---

## Page 6 · 风险 + 资源依赖

### ▎风险清单

| # | 风险 | 等级 | 缓解措施 | 求 CTO 推动 |
|---|---|---|---|---|
| 0 | **PAC 一期召回算法策略未拍板**(疗效保障 vs 漏诊召回 vs 混合) | 🔴 **最高** | 起草两种算法对比 → 业务方选 | **本周内拍板**,否则 W4 评估节点空跑 |
| 1 | **PAC 工程团队 = 1 人 + AI**;跨团队对接唯一接口 = CTO(于总) | 🔴 **高** | W1-W4 范围聚焦;试点期资源 / 跨团队协调统一由 CTO 推动,PAC 实施侧不直接出面 | 管委会授权 CTO 跨团队推动 DW / 5i5ya / 客服培训 |
| 2 | **DW 团队排期不可控** | 🟢 已规避 | Mock 数据并行驱动 PAC 内部开发,DW 不在关键路径;对接文档成型后交付 DW,真实数据接入 W5+ 切换 | 文档定稿后由 CTO 交付 DW 排期 |
| 3 | **Mock 数据集质量决定 W3 评估价值** | 🟡 中 | 试点门诊脱敏样本 + 典型病例兜底 | 协调试点门诊 W2 内提供样本 |
| 4 | **5i5ya 业务团队接入意愿** | 🟡 中 | 暂走 DW 路径,5i5ya REST 接入 Phase 6+ | 业务管委会出面对接 |
| 5 | **客服培训接受度** | 🟡 中 | Phase 5 试点前对齐 SOP | 客服管理团队提前介入 |
| 6 | **业务 KPI 定义未敲定** | 🟡 中 | 已起草 主 KPI 候选 | 业务管委会本月确认 |
| 7 | **跨诊所合规边界** | 🟢 已对齐 | 全集团 DNC + 审计透明 | 无 |
| 8 | **评估节点 1 时点**(W3 → W4) | 🟡 中 | 完整业务流需画像 + 召回 + 话术齐全,W3 出画像、W4 出完整 | 管委会理解 W4 末评估更有价值 |

### ▎资源依赖矩阵(说清楚)

```
W1-W6 PAC 框架 + 演示 = 1 人 + AI(可承受)

W7+ 试点跑通 = 必须借力(由 CTO 统一协调,PAC 实施侧不直接对接):
  ▶ DW 团队 1 人(W3-W6 配合接入,W7+ 持续维护)
  ▶ 5i5ya 业务对接人(W5-W8 配合 SOP)
  ▶ 客服培训对接人(W7-W8 实施培训)

不借力 = 试点跑不通,只能停在演示版。

PAC 实施侧专注代码 / 设计 / 演示交付,
跨团队 / 跨部门沟通统一由 CTO(于总)出面。
```

---

## Page 7 · 本周求支持 + 附件

### ▎本周(W2)需推动决策(通过 CTO 协调)

```
🆘 0(最高优先级)业务方拍板 PAC 一期召回算法策略
   选项 A:走 PDF 定义"疗效保障召回"(治疗链已完成 → 复查跟踪)
            · 业务价值:维护老客户 / 复购小治疗(客单价中)
            · 数据来源:治疗记录 + 时间窗
   选项 B:走 Friday 旧版"漏诊召回"(影像 AI + 医生诊断 → 推导漏诊)
            · 业务价值:直接拉高客单价(根管 / 种植 / 正畸营收)
            · 数据来源:朝厚影像 AI 已接入(集团已买单)+ 医生诊断
            · 业务模式:Friday 旧版已验证跑通
   选项 C:两者并行 — 完整召回闭环("该治没治" + "治完没维护")
            · 业务价值最高,但算法工作量翻倍 / 工期需评估
   → 影响 W3 mock 数据集设计 + Persona feature 设计 + 整个评估节点价值

🆘 1. DW 团队对接(W2 末对接文档定稿后由 CTO 转交,启动 DW 排期)
     → 不阻塞 PAC 内部开发(Mock 并行驱动);影响 W5+ 真实数据切换时点

🆘 2. 协调试点门诊提供 100-300 个脱敏患者样本
     → 影响 W3 评估节点输出质量

🆘 3. 业务方确认 3 个主 KPI 业务定义
     → 影响后续 dashboard 设计

🆘 4. 跟 5i5ya 业务管委会沟通 Phase 5 客服培训窗口
     → 影响 W7+ 试点跑通节奏

🆘 5. 业务方提供 5 家试点门诊基线数据
     - 现有年流失率 / 复购率 / 召回转化率 / 客服效能基准
     → 用于 W7+ 试点期评估 PAC 提升幅度(没基线就无法证明价值)
```

### ▎下一份报告

**W2 末**(本周五):
- 数据源对接文档发出回执
- Mock 数据集进度
- 业务方拍板情况(召回算法 + AI 模型选型)
- W4 评估节点演示路径预告

### ▎附件(留参考,不在主线讲)

| 附件 | 内容 |
|---|---|
| 提议响应确认单 PDF | 60+ 评审项 closure 详情 |
| 数据库结构评审文档 | 完整 schema 设计 + 决议过程 |
| 系统架构方案 | 跟 5i5ya / Friday / DW 边界设计 |
| 三层模型详细图 | (单独可视化,可贴 PPT) |
| **Friday 旧版召回流程图** | 影像 AI + 诊断 → 漏诊推导,业务方可参考(算法策略待拍板) |

---

> **核心信号**:框架就绪 + 业务质量验证不等真实数据 + 风险透明 + 试点期需资源支持
