---
title: 召回分配
description: 把「要不要做」变成「做了没有」—— 批次分配的设计原则、流程与闭环。
icon: Users
---

## 问题

召回池成千上万条，**头部反复被看、长尾无人碰**，池子形同虚设。

根因不是客服不努力，是纯自助认领的三个结构性缺口：

| 缺口 | 表现 |
|---|---|
| 责任真空 | 认领零成本，领了不做没有后果 |
| 无目的 | 各捞各的，运营意图落不了地 |
| 无法归因 | 做了什么、效果如何，事后说不清 |

**分配要做的，是把「要不要做」变成「做了没有」。**

---

## 全流程

```mermaid
flowchart LR
  A["① 初选<br/>主管点一格<br/>治疗项 × 时机"] --> B["② 精选<br/>助手挑人、排客服"]
  B --> C["③ 确认单<br/>主管过目"]
  C --> D["④ 分配<br/>确认落库"]
  D --> E["⑤ 跟踪<br/>看效果、调下一批"]
  E -.反哺.-> A

  style A fill:#e0e7ff,stroke:#6366f1
  style C fill:#fef3c7,stroke:#f59e0b
  style D fill:#d1fae5,stroke:#10b981
```

**主管只在两处动手**：点一格（①）、点确认（④）。中间全是助手的活。

---

## 一、这是什么

### 分配是批次运营，不是工单派发

目标是「选一批人、配一套打法、看效果」，**从不追求把池子分完**。
所以"主管扛不住全量"不是缺陷 —— 设计上就不打算分全量。

### 宁缺毋滥

一批宁可只做 100 人做透，不做 1000 人做浅。
**池子里剩下的不是遗漏，是还没轮到。**

### 每一步都在收缩人群

从"万"级压到"十"级。**主管只做判断，不做筛选** —— 筛选是助手的活。

---

## 二、谁做什么

```mermaid
flowchart TB
  L["👤 主管<br/>判断 · 取舍 · 拍板"]
  A["🤖 助手<br/>筛选 · 计算 · 呈现"]
  S["📞 客服<br/>执行"]

  L -->|"点一格 / 提要求"| A
  A -->|"确认单"| L
  L ==>|"确认（唯一的写动作）"| S
  S -.->|"结果 / 退回原因"| L

  style L fill:#e0e7ff,stroke:#6366f1
  style A fill:#f3e8ff,stroke:#a855f7
  style S fill:#d1fae5,stroke:#10b981
```

| | 做什么 | **不做什么** |
|---|---|---|
| 主管 | 判断、取舍、拍板 | 不翻明细、不做算术 |
| 助手 | 筛选、计算、呈现 | **不替主管决定、不自动执行** |
| 客服 | 执行 | 不做选择 |

**任何改变数据的动作，只能由主管的「确认」触发。**

### 客服看不到池子

客服左侧只有「我的」，**无从认领**；主管才有「召回池」。
主管本质也是客服，也要执行 —— 所以分配入口就在召回池里，不新开页面、不把他劈成两个身份。

---

## 三、怎么选人

初选是一张矩阵，两个轴：

```mermaid
flowchart LR
  subgraph X["X 轴 · 潜在治疗（8 类机会）"]
    direction TB
    X1["种植 / 正畸 / 早矫<br/>根管 / 牙周 / 充填<br/>修复 / 拔牙"]
  end
  subgraph Y["Y 轴 · 时机（3 档）"]
    direction TB
    Y1["🔥 黄金期<br/>🌡 窗口内<br/>❄️ 窗口外"]
  end
  X --> M["矩阵格子<br/>= 一批候选人"]
  Y --> M

  style M fill:#fef3c7,stroke:#f59e0b
```

**X 轴是「有需求但没做的机会」**，不是内部技术分类。按业务视角拆：正畸按年龄分成正畸与早矫，残根合成拔牙。

**Y 轴是该治疗项目自己的临床周期**，不是客户价值、不是意愿、不是多久没来。
每个项目用自己的尺度，归一化后横向可比 —— 种植的"过期"和补牙的"过期"不是一个天数。

### 不用没有数据支撑的因素

客服的**态度、能力**没有数据，不进决策。
分配只依据**客观事实**（专属客服、在岗、在手量）和**主管的显式指定**。

> 不给客服建能力评分 —— 分数一旦可见就成了绩效工具，会诱导行为扭曲。

### 画像圈人放在"调整"阶段

助手第一次出方案时**不做画像分层**，保持简洁。
主管追问「只要商保直付的」「排掉怕疼的」时，才当场用画像收窄 —— 那时候它正是主管要的精确回应。

---

## 四、怎么落到人头上

只有**两个基数**，都沿用主管上一次用的值：

| 基数 | 含义 | 首次 | 之后 |
|---|---|---|---|
| **本批人数** | 这一轮推多少人 | 在岗人数 × 20 | 沿用上次 |
| **时限** | 多久没动自动回池 | 3 天 | 沿用上次 |

> 没有第三个数。曾经有过"每人容量"，删掉了 —— 一个数当两个用，第二批必然分不出来。

落人分**三趟**，目标是**又满又平**：名额全部落地，且分完大家在手量齐平。

```mermaid
flowchart TB
  S(["N 个名额"]) --> T1

  T1["① 专属优先<br/>有专属客服的 → 回到他手上"]
  T1 -->|"但封顶在目标水位"| T2
  T2["② 无主补空<br/>没有专属的 → 给当前最空的人"]
  T2 -->|"还没填平？"| T3
  T3["③ 有主改派<br/>超出水位的专属患者 → 改派给最空的人"]
  T3 --> E(["每人在手量齐平"])

  style T1 fill:#e0e7ff,stroke:#6366f1
  style T2 fill:#dbeafe,stroke:#3b82f6
  style T3 fill:#fef3c7,stroke:#f59e0b
  style E fill:#d1fae5,stroke:#10b981
```

**顺序不能颠倒**：②③ 总量一样，但被拆散的老客户关系数不一样。先用"没有关系要顾"的人填坑，代价最小。

**为什么第一趟要封顶**（真实数据）：某个格子 1,081 人里 **70% 挂在同一个客服名下**，而 17 位在岗客服中有 **10 位名下一个患者都没有**。
不封顶，一批 340 人分下去是 **248 / 34 / 31 / 14 / 14**；封顶后是**每人 20，完全齐平**。

> 改派**不是"抢客户"** —— 语义是「关系还在，只是这轮没轮到」。

---

## 五、确认单

助手把结果一次性摆出来，**直出，不追问**。最好的情况是主管看一眼就点确认。

**三层展开**：汇总 → 按客服 → 患者明细（折叠，展开才看）。
患者明细必须给**姓名和病历号** —— 给一串编号等于让主管对着乱码猜。

主管在卡片上能做四件**局部**修正，判据是「要不要重跑算法」：

| 卡片上直接做 | 回对话让助手做 |
|---|---|
| 改批次时限 · 改单条时限 | 换人群（换治疗项 / 时机 / 画像条件） |
| 删掉某一条 | 改本批人数 |
| 把某一条拖给别的客服 | 给某个客服设本批名额 |
| 移除某个客服 | 设本批福利 |

时限的文案是「**N 天后自动退回**」而不是光一个"时限" —— 主管要知道到期会发生什么，否则这个数对他没有意义。

### 福利挂在批次上，不挂在个人上

同一批共享同一个福利，才能归因（这批的效果 = 这个福利的效果）。

福利作为**事实**交给助手，由它自然融进话术。硬约束：**只能说福利原文包含的内容**，不得追加条件、期限、名额，不得夸大。

### 助手不出没有证据的结果

- 缺的数据（如医生档期）→ **不用，也不猜**
- 首次无历史 → 用默认值，**并标明这是默认值**
- 有数据之后 → 反推真实习惯，替换默认值

> 时限"3 天"现在只能写「默认值，暂无历史数据」，**不能**写成「依据平均结案 2.4 天」—— 那个数还算不出来。

---

## 六、闭环

一条单子的完整生命：

```mermaid
stateDiagram-v2
  [*] --> 池子里
  池子里 --> 在客服手上: 主管分配
  在客服手上 --> 已处理: 联系到 / 约上了
  在客服手上 --> 池子里: 客服退回（必须写原因）
  在客服手上 --> 池子里: 到期自动退回
  在客服手上 --> 池子里: 主管撤销整批
  已处理 --> [*]

  note right of 池子里
    退回 / 到期的人会回到池子
    只是排序上排到后面
  end note
```

### 退回必须写原因

退回是**正常路径**不是异常。原因分布是主管调整下一批的输入 ——
「派多了」「时限太紧」「压根不该派给他」，这三种的下一步动作完全不同。

### 撤销 ≠ 退回

| | 谁做 | 做什么 | 粒度 |
|---|---|---|---|
| **撤销** | 主管 | 收回整批（分错人 / 条件填错） | 批次 |
| **退回** | 客服 | 退回单条（不是我的客户 / 没时间） | 单条 |

撤销**几乎总是部分成功** —— 客服已经打开过的单不会被收回（他可能已经联系了患者）。
所以结果如实报三个数，不能只说一句"已撤销"。

### 跟踪是为了自优化

**不做「分配 vs 自认领」的对照** —— 认领已经隐藏，没有对照组；
而且那种框法把分配当成"待验证的假设"，与定位不符。分配是**既定的运营方式**，问题不是"要不要用"，而是**"怎么越用越准"**。

主管能看到的：

| 指标 | 口径提醒 |
|---|---|
| 分了多少人 / 在手 / 已处理 | 「已处理」= 这单动过了，**不等于谈成了** |
| 客服主动退回 · 原因分布 | 「不该我做」，是**分配**问题 |
| 到期没人动 | **没处置**，是派多了 / 时限太紧 / 人不在岗 |
| 通话结果：成功 / 不成功及原因 | 打了之后的结果，是**召回效果**问题 |
| 一次结果都没有 | 最该先看的数 —— 不是效果差，是**根本没做** |

> **退回率永远给两个数**：「退回 5 / 已处置 40 = 12.5%（另有 60 条没人动）」。
> 没人动的数量本身就是信号，只报一个百分比会让人把前者误读成后者。

> **样本不足就直说**。上线初期成功记录会长期是 0 或个位数，
> 这时候必须写「已处置 12 人，暂无转化记录，样本量不足」，⛔ 不能渲染成「0.0% 转化率」。

---

## 一句话总结

> 主管点一格、看一眼、点确认；剩下的事系统做完，并且**回头说得清**。
