# E04 关系覆盖与关键人经营 · 活动流程与工单说明

> 所属子系统：SS01 客户与市场 ｜ 优先级：P0 ｜ 类型：关系经营型活动
> 本说明总结 E04 活动的整体流程、工单产出的设计逻辑，以及每一步做了什么。配套工单 HTML 见本目录。

---

## 一、活动定位

**E04 关系覆盖与关键人经营**是围绕客户关系网络的持续经营活动：关键人识别与覆盖、关系亲密度维护、决策链更新、影响力经营。核心理念是「你还没开口，你想要的我已经给你了」——关系覆盖是预判需求的前提。

**消费的台账**（读）：L-02 客户主台账（画像/决策链/覆盖度）、L-08 联系人台账（角色/影响力/亲密度）。
**产出的台账**（写）：L-02 的 coverage_score / decision_chain / interaction_timeline、L-08 的角色标注 / 影响力 / 亲密度 / 关键人标记。

**触发方式**：① 月度例行（每月对重点客户做一轮覆盖维护）；② 事件驱动（新客户建档 / 关键人变动 / 重大商机启动 / 攻坚项目 T04 立项）。

---

## 二、整体流程（7 步）

E04 的完整工作链条共 7 步，AI 与人的分工原则是：**AI 承担信息汇总、记录与初稿生成，人负责判断与决策**。

| 步骤 | 名称 | 谁在做 | 干什么 |
|---|---|---|---|
| ① | 启动与覆盖范围确认 | AM Lead（审） | 确认本轮覆盖哪些客户、场景类型、覆盖深度 |
| ② | 读取覆盖现状 | AI 汇总 | 调出客户画像、决策链地图、覆盖度、联系人清单，形成覆盖全景 |
| ③ | 覆盖缺口分析 | AM Lead（审） | 对照决策链识别空白节点，按 BT 层级确定需覆盖的角色 |
| ④ | 制定关系经营计划 | AM Lead（审） | 按「影响力 × 亲密度缺口」排序，草拟每个关键人的经营动作 |
| ⑤ | 执行经营动作 | AM（执行） | 拜访 / 技术交流 / 价值传递等线下动作（AI 做不到） |
| ⑥ | 更新关系台账 | AM（办理） | 重算 coverage_score、更新决策链、更新联系人档案 |
| ⑦ | 复盘与完结（门禁） | AM Lead（审） | 覆盖度达标检查，输出更新后的关系覆盖地图 |

---

## 三、为什么这样产出工单（核心设计逻辑）

7 步不是 7 个工单。按「AI 能不能独立完成」把 7 步收敛成 **2 张执行工单 + 2 张验收工单**：

| 工单 | 覆盖步骤 | 类型 | 依据 |
|---|---|---|---|
| 执行工单 1 | ① | 执行 | AI 识别出了覆盖范围，但「规则之外」的信息需要人来补 |
| 验收工单 1 | ②③④ | 验收 | AI 算出了经营计划，需要人判断计划是否合理 |
| 执行工单 2 | ⑤⑥ | 执行 | 计划要人去线下执行（AI 做不到），执行完要回执 |
| 验收工单 2 | ⑥⑦ | 验收 | AI 收到回执后更新台账，需要人确认无误后入库 |

### 两条工单的本质区别

**执行工单 = AI 产出 + 人填内容**
- AI 先列出它产出的结论（候选基线），人在这基础上**查漏补缺 / 填写内容**（可以不填）。
- 用于「AI 做不到、需要人去做」的事——如物理拜访、线下交流、补充 AI 识别规则之外的信息。

**验收工单 = AI 结论展示 + 人只做审批**
- AI 展示它计算出的结论（只读），人**只做「通过 / 驳回」**，不能修改结论；驳回带意见，AI 重做。
- 用于「AI 算出了结论、需要人拍板」的事——如经营计划是否合理、台账更新是否无误。

### 三条硬约束

1. **工单不承载审批动作**：工单里不放「提交回执 / 通过 / 驳回」按钮，审批动作统一放在对话区的卡（执行卡 / 验收卡）里。
2. **工单要完整**：每个工单必须包含「做什么 / 交回什么 / 期限 / 判据（验收工单）/ 提交后去向」。
3. **交回内容可校验**：执行工单的回执字段标注必填（＊）/ 选填，验收工单给明确的判据清单，让人知道凭什么通过或驳回。

---

## 四、每个工单详细说明

### 执行工单 1 · 覆盖范围确认（步骤 ①）

- **做什么**：确认本轮覆盖范围。
- **AI 产出**：按台账规则识别出的候选客户清单（如 AvtoKom、Boreas）＋ 场景类型、覆盖深度。
- **人填什么（查漏补缺）**：在 AI 清单上直接增删改——加一行 = 额外纳入（AI 没识别但人了解有价值）、删一行 = 排除（AI 纳入了但实际应排除）、改单元格 = 修正 AI 识别内容。
- **为什么是执行工单**：AI 只能按台账规则判断，有些「数据里没有、但人线下知道」的信息（如某贸易商掌握关键渠道）需要人补充录入。
- **交回**：核对后的覆盖范围客户清单（客户编号、客户名称必填）。

### 验收工单 1 · 关系经营计划审批（步骤 ②③④）

- **做什么**：审批 AI 制定的关系经营计划。
- **AI 产出**：经过「读覆盖现状 → 缺口分析 → 制定计划」三步计算，得出经营计划（经营哪些关键人、建议动作、建议优先级、理由），按「影响力 × 亲密度缺口」排序。
- **人怎么审**：只读展示，不可修改。按判据核对后「通过」或「驳回＋意见」（驳回 AI 重做）。
- **验收判据**：① 关键人覆盖是否完整；② 优先级排序是否合理；③ 动作是否可执行、有时间点。
- **为什么是验收工单**：计划是 AI 算出来的结论，人对结论只做肯定或否定，不自己改。

### 执行工单 2 · 经营计划执行回执（步骤 ⑤⑥）

- **做什么**：执行已验收通过的计划动作。
- **AI 产出**：验收通过后的计划动作清单（拜访谁、做什么）。
- **人填什么（回执）**：逐项填完成状态（必填）、结果摘要（必填）、客户反馈（选填）、关键人变动（必填）。
- **为什么是执行工单**：拜访、技术交流、递送实物都是 AI 做不到、需要人到场执行的事；人执行后把回执填回来。
- **交回**：每项计划动作的执行回执。

### 验收工单 2 · 关系台账更新确认（步骤 ⑥⑦）

- **做什么**：确认 AI 拟更新的台账，无误后入库。
- **AI 产出**：收到执行回执后，重算 coverage_score、更新决策链、更新 L-08 联系人档案、追加互动时间线，产出「更新前 → 更新后」明细。
- **人怎么审**：只读展示，不可修改。按判据核对后「通过入库」或「驳回＋意见」。
- **验收判据**：① 更新是否有依据（每条更新能否在回执里找到对应事实）；② 数值是否合理；③ 有无漏更或误更。
- **为什么是验收工单**：台账更新是 AI 的落账动作，人确认无误后入库，是「终局唯放行」的最后一道确认。

---

## 五、文件对应关系

| 工单文件 | 类型 | 覆盖步骤 | 一句话 |
|---|---|---|---|
| `E04-执行工单-01-覆盖范围确认.html` | 执行 | ① | 人补充 AI 覆盖范围结论之外的信息 |
| `E04-验收工单-01-关系经营计划.html` | 验收 | ②③④ | 人审批 AI 的经营计划（通过/驳回） |
| `E04-执行工单-02-执行回执.html` | 执行 | ⑤⑥ | 人执行计划并填回执 |
| `E04-验收工单-02-台账更新确认.html` | 验收 | ⑥⑦ | 人确认 AI 的台账更新后入库 |

**完整闭环**：

```
① 覆盖范围确认 ──执行工单1(人补信息)──▶ ②③④ AI 制定计划 ──验收工单1(通过/驳回)──▶
⑤⑥ 人去执行计划 ──执行工单2(人填回执)──▶ AI 更新台账 ──验收工单2(确认入库)──▶ 完结
```

---

## 六、动态数据标注（模板绑定位置）

> 这 4 个工单 HTML 是**模板**——里面的数据会根据实例（不同任务 / 客户 / 轮次）加载不同内容。本表标注每个工单里「动态数据」的位置及其绑定地址（命名空间）。设计态示例数据在运行时会被注水器替换。

### 6.1 绑定命名空间速查

| 命名空间 | 含义 | 本活动用到 |
|---|---|---|
| `meta.*` | 任务与活动元数据 | 收件人、任务编号、步骤、活动名 |
| `card.*` | 工单身份专属 | 期限、工单编号、验收判据、回执字段 |
| `out.*` | 输出表单 / 台账映射行集 | 客户清单、经营计划、台账更新明细 |
| `sd.*` | 状态数据读数 | 客户计数、触发口径、覆盖度 |

### 6.2 四个工单共用的动态位置（每个工单头部都有）

| HTML 位置 | 动态数据 | 绑定地址 |
|---|---|---|
| 卡头「收件人」 | 负责人 | `meta.task.owner` |
| 卡头「关联任务」 | 任务编号 | `meta.task.id` |
| 卡头「步骤」 | 当前节点 | `meta.phase` |
| 卡头「最迟交回」 | 期限 | `card.deadline` |
| 页脚「工单编号」 | 工单 ID | `card.id` |

### 6.3 执行工单 1 · 覆盖范围确认

| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 【做什么】里「触发口径与覆盖范围」结论 | 本轮触发场景 | `sd.trigger_scene` | 单值 |
| 编辑闸「AI 已识别 2 个客户」 | 识别客户数 | `sd.customer_count` | 单值 |
| 【交回什么】客户清单表 | 候选客户清单 | `out.customer_list` | 行集 |
| └ 客户编号 / 名称 / 类型 / BT层级 / 状态 / 依据 / 覆盖深度 | 各列字段 | `out.customer_list.*` | 字段 |

### 6.4 验收工单 1 · 关系经营计划

| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 【验收判据】清单 | 判据项 | `card.criteria[]` | 列表 |
| 【AI 产出的经营计划】表 | 计划行 | `out.plan` | 行集 |
| └ 客户 / 关键人 / 建议动作 / 优先级 / 理由 | 各列字段 | `out.plan.*` | 字段 |
| └ 优先级「高/中」颜色 | 状态着色 | `data-class-of` | 状态类 |

### 6.5 执行工单 2 · 执行回执

| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 【交回什么】计划动作回执表 | 计划动作（AI 产出） | `out.plan` | 行集 |
| └ 计划动作 / 对象 | AI 产出的计划 | `out.plan.action / target` | 字段（只读） |
| └ 完成状态 / 结果摘要 / 客户反馈 / 关键人变动 | 人填回执 | `card.fields.*` | 字段（可填） |

### 6.6 验收工单 2 · 台账更新确认

| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 【验收判据】清单 | 判据项 | `card.criteria[]` | 列表 |
| 【拟更新的台账】表 | 更新明细行 | `out.ledger_update` | 行集 |
| └ 台账 / 字段 / 更新前 / 更新后 | 各列字段 | `out.ledger_update.*` | 字段 |

---

（完）E04 一个活动，七个步骤，四张工单：**执行工单让人补内容、验收工单让人拍结论**——AI 做得出的算出来给人审，AI 做不到的派出去让人干。数据由服务注水，工单只是模板。