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

> **报告周期**:第 1 周(W1)· 首次汇报
> **报告对象**:管委会
> **报告人**:luoqi
> **状态**:🟢 按计划推进

---

## Page 1 · 一页电梯演讲

### ▎本周一句话

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

### ▎核心成果

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

### ▎里程碑预告

```
🎯 W3 末:第一批 mock 数据评估输出(管委会可点评算法质量)
🎯 W4 末:完整业务流 mock 演示
🎯 W6 末:演示版 + 1 家试点最小数据接入
```

### ▎本周需管委会决策

```
🆘 协调 DW 团队启动对接(本周内)
🆘 协调试点门诊提供 100-300 个脱敏患者样本(W2 内)
🆘 业务方确认 3 个主 KPI 业务定义
```

---

## Page 2 · 项目使命(Mandate · 首次必讲)

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

```
集团 5 家试点门诊每年沉睡 / 流失客户 ~XX%(待业务核数据),
现有召回靠客服个人经验:效率低、质量不稳、跨诊所看不到全貌。

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

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

| 维度 | 内容 |
|---|---|
| **业务场景** | 治疗链已完成患者召回(根管 / 正畸 / 种植后未复查的老客户) |
| **试点门诊** | 杭州大厦 / 杭州高德 / 无锡学前街 / 上海世纪公园 / 北京朝阳公园 |
| **本期周期** | 6 周框架就绪 + 演示;后续 4-6 周试点跑通 |
| **量级** | 5 家门诊预估 XX 万患者档案 / XX 名客服(待数据落实) |

### ▎评判 KPI(主 3 个,业务待确认)

| KPI | 业务含义 |
|---|---|
| **召回转化率** | 外呼接通后预约成功的比例 |
| **客户挽回率** | 沉睡 >90 天客户被激活回诊的比例 |
| **客服效能** | 单客服日均有效外呼数 / 转化数 |

---

## Page 3 · Mandate(续)— 优势特点 + 用户价值

### ▎PAC 跟现有召回的差异(为什么值得做)

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

### ▎给用户的价值

| 用户 | 得到什么 |
|---|---|
| **客服** | 上工就有"今天该打谁"的清单,准备时间从 30 分钟压到 5 分钟;新客服上手快 |
| **诊所主管** | dashboard 看团队转化率分布、找出短板 |
| **患者** | 接到的不是骚扰,是"医生关心你的复查"——客户体验提升 |
| **集团** | 老客户激活率提升 → 复购营收 + 防止流失到他家诊所 |

---

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

### ▎6 周里程碑

```
W1  ━━━━━━━━━━━━━━━━━━ ✅ 框架定稿 + 评审 closure
W2  ▶━━━━━━━━━━━━━━━━━ 🟡 DW 对接文档 + Mock 数据集 + 数据骨架
W3  ───━━━━━━━━━━━━━━━ ⭐ 第一批 Mock validate 输出
W4  ──────━━━━━━━━━━━━ 🎯 完整业务流 Mock 演示
W5  ─────────━━━━━━━━━ 🎯 DW 真实数据接入(并行启动)
W6  ────────────━━━━━━ 🎯 演示版 + 角色扮演试点
W7+ ────────────────── ⏳ 试点跑通(需 DW + 客服培训配合)
```

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

```
线 1(等)│ DW 对接 ──────[发出文档]──────[等排期]────[联调]──▶
                ↑W2                            ↑W4-W5

线 2(干)│ PAC 内部:Mock 驱动开发(自己干,不卡 DW)
        │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶
        │ schema → ingest → Persona → Plan → Agent → 工作台

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

### ▎关键里程碑

| 里程碑 | 时间 | 业务可见性 |
|---|---|---|
| **管委会评估节点 1** | ⭐ **W3 末** | mock 数据 → 100+ 患者画像 + 召回名单可点评 |
| **管委会评估节点 2** | 🎯 W4 末 | + AI 话术 + One Page Summary 完整业务流 |
| **第一家试点接入** | 🎯 W6 末 | DW 真实数据切换 + 角色扮演试点 |

---

## Page 5 · W1 具体成果(业务翻译版)

### ▎三层业务模型(本周确立的核心架构)

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

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

### ▎评审 closure 数据

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

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

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

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

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

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

### ▎关键架构决策(用业务语言)

- **集团内同一患者跨诊所唯一**:杭州大厦的张三和无锡学前街的张三,系统认得是同一人,画像跟着人走
- **不打扰名单全集团生效**:任一门诊标"不打扰",其他门诊不会再打,合规默认 + 审计透明化(各诊所能看到"被排除原因")
- **数据可追溯可审计**:每条召回都能反查"为什么排这个优先级 / 为什么用这话术",支持事后复盘
- **召回归属灵活**:支持"主诊所归属"/"集团统一客服池"/"VIP 中心"多种业务模式

---

## Page 6 · W2-W3 计划(面向 W3 评估节点)

### ▎W2(本周)交付清单

```
✅ 必交付
1. DW 对接文档发出(数据范围 / 字段 schema / 同步规范)
2. 数据骨架落地(代码层重构,等主管 confirm 反馈)
3. Mock 数据集启动:
   - 协调试点门诊脱敏样本 100-300 个
   - 兜底典型病例集合 50-100 个
4. 离线 ingest 链路验证(模拟数据走通)

🎯 演示给管委会
- DW 对接文档目录 + 字段清单截图
- Mock 数据导入截图
```

### ▎W3 ⭐ 第一个评估节点

```
✅ 必交付
1. Persona 画像引擎跑出 4 个起步特征:
   - 客户价值
   - 治疗链状态
   - 触达活跃度
   - 复查风险
2. 召回逻辑跑通 → 第一批召回名单(基于 mock 数据)
3. 排序解释 → 每个患者"为什么排这个优先级"

🎯 演示给管委会(管委会评估节点 1)
- 100+ mock 患者画像卡片
- 召回名单 + 优先级 + 召回原因
- 4 类典型 case 业务点评(管委会可指出"对不对")
```

**这是首个让管委会能给业务反馈的节点 — 不等真实数据 / 不等 Phase 5。**

---

## Page 7 · 风险 + 资源依赖(过程管理透明)

### ▎风险清单(主动管理,不报喜不报忧)

| # | 风险 | 等级 | 缓解措施 | 求管委会支持 |
|---|---|---|---|---|
| 1 | **PAC 工程团队 = 1 人 + AI** | 🔴 **高** | W1-W4 范围聚焦,试点期需借调 | 试点期协调 DW + 5i5ya + 客服培训对接人 |
| 2 | **DW 团队排期不可控** | 🟡 中 | W2 末发出对接文档 + 管委会推动 | 本周内启动 DW 协调会议 |
| 3 | **Mock 数据集质量决定 W3 评估价值** | 🟡 中 | 试点门诊脱敏样本 + 典型病例兜底 | 协调试点门诊 W2 内提供样本 |
| 4 | **5i5ya 业务团队接入意愿** | 🟡 中 | 暂走 DW 路径,5i5ya REST 接入 Phase 6+ | 业务管委会出面对接 |
| 5 | **客服培训接受度** | 🟡 中 | Phase 5 试点前对齐 SOP | 客服管理团队提前介入 |
| 6 | **业务 KPI 定义未敲定** | 🟡 中 | 已起草 3 个主 KPI 候选 | 业务管委会本月确认 |
| 7 | **跨诊所合规边界** | 🟢 已对齐 | 全集团 DNC + 审计透明 | 无 |

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

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

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

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

---

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

### ▎本周(W2)需管委会决策 / 推动

```
🆘 1. 协调 DW 团队启动对接会议(本周内)
     → 影响 W4-W5 真实数据接入

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

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

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

### ▎下一份报告

**W2 末**(本周五):
- DW 对接文档发出回执
- Mock 数据集进度
- W3 评估节点演示预告

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

| 附件 | 内容 |
|---|---|
| 提议响应确认单 PDF | 60+ 评审项 closure 详情 |
| 数据库结构评审文档 | 完整 schema 设计 + 决议过程 |
| 系统架构方案 | 跟 5i5ya / Friday / DW 边界设计 |
| 三层模型详细图 | (单独可视化,可贴 PPT) |

---

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