Skip to content

P
pac
Commit 0b0acba4 by luoqi
Options

docs(站点): 「选人」拆成召回策略 → 主管初选 → 助手精选(产品定的叙述框架) 

产品指出:选人不是一次动作,要**从主管的运营意图出发**拆开讲 —— 而且叙述该
「先列出要回答的问题,再说谁答、凭什么答」,这才是产品思维。按这个重写 §1。

**召回策略(在选人之前的一环)= 一批召回要回答的四个问题**
  1 做哪一类还没启动的治疗   → 主管答,凭这季度的经营重点
  2 找多久没来的人           → 主管答,凭经验
  3 要不要只挑高价值的       → 主管定,但**助手先摆数据**
  4 团队还吃得下多少         → 主管定,但**助手先摆数据**

⇒ 1、2 是运营意图,他张口就来;**3、4 他答不了** —— 不把全景摆在面前,
  「要不要只挑高价值的」根本没法回答:他不知道这批里有多少是高价值的,
  也不知道切完还剩几个。所以:
    **选人 = 主管初选(1、2)+ 助手精选(3、4,并顺手给出一版已经分好的方案)**
  助手在这一步⛔ 不是"等下一个指令",而是先把该看的摆出来、把方案做出来。

🔴 **补上「多久没来」的真正分量**(产品点出,此前整篇都没写):
  它不只是筛选条件 —— **有经验的主管能从它估出这批大概能回来多少**
  (一两年没来的和三年以上的,回头率不是一个量级),而这个估算往下游一步
  就是**诊所的排班**:预计回来多少人、多少要做种植,医生和科室要不要提前留位。
  ⇒ 这一项必须由主管拍,⛔ 系统不代劳也不推荐。

决策树相应改成 召回策略 → 主管初选 → 助手精选 → 分人 → 确认 → 确认之后;
重跑那条环回到「主管初选」。mermaid 节点引用与 style 目标已校验无悬空。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
parent 0ffc8d40
Showing with 47 additions and 18 deletions
apps/pac-docs/content/docs/design/assignment-agent.mdx
......@@ -14,11 +14,17 @@ icon: Bot
整条线只有四步：**① 选人 → ② 分人 → ③ 确认 → ④ 确认之后**。
其中「选人」不是一次动作，而是**两个人各答一半**：主管先定运营意图，助手再用全景数据把它落成一版具体的人。
```mermaid
flowchart TD
S(["主管定这一批召回谁"]) --> A
S(["召回策略<br/>一批召回要回答的四个问题"]) --> A1
A1["① 选人 · 主管初选<br/>1 做哪一类还没启动的治疗<br/>2 找多久没来的人<br/>—— 凭运营经验,他张口就来"] --> A2
A2["① 选人 · 助手精选<br/>3 要不要只挑高价值的 —— 先摆这批人的全景<br/>4 团队还吃得下多少 —— 先摆在岗人手与在手量<br/>—— 数据摆出来,顺手给出一版方案"]
A["① 选人 —— 他的召回策略<br/>做哪一类没启动的治疗<br/>找多久没来的人<br/>要不要只挑高价值的<br/>团队现在还吃得下多少 · 几天内打完"] --> B["② 分人 —— 谁去打<br/>有专属的回自己人手上<br/>无主的给当前手上最少的<br/>专属这轮排满的单列成一组"]
A2 --> B["② 分人 —— 谁去打<br/>有专属的回自己人手上<br/>无主的给当前手上最少的<br/>专属这轮排满的单列成一组"]
B --> C{"这一版还有<br/>要他定的吗？"}
C -->|"没有"| K
......@@ -33,12 +39,13 @@ flowchart TD
M -->|"动①选人<br/>换条件 · 改人数 · 换时间档"| N["重跑，出新版<br/>旧版当场作废"]
J --> C
N --> A
N --> A1
K["③ 确认<br/>点下去，这一刻才真的分下去"] --> L["④ 确认之后<br/>限时撤销 · 补挂福利 · 跟踪进度"]
style S fill:#fef3c7,stroke:#f59e0b
style A fill:#e0e7ff,stroke:#6366f1
style A1 fill:#fef3c7,stroke:#f59e0b
style A2 fill:#e0e7ff,stroke:#6366f1
style B fill:#e0e7ff,stroke:#6366f1
style G fill:#fce7f3,stroke:#ec4899
style M fill:#fee2e2,stroke:#ef4444,stroke-width:2px
......@@ -48,30 +55,52 @@ flowchart TD
style L fill:#d1fae5,stroke:#10b981
```
### 四步各自在做什么
### 召回策略：一批召回要回答的四个问题
| 步 | 主管在决定什么 | 谁来做 |
|---|---|---|
| **① 选人** | **这一批的召回策略**：做哪一类还没启动的治疗（种植 / 正畸 / 拔牙…）、找多久没来的人（三个月内 … 三年以上）、要不要再收窄到高价值的人（消费额、商保、意向）、**团队现在还吃得下多少**、几天内要打完 | 主管定策略，程序按策略挑人、按人手估这批多大 |
| **② 分人** | **谁去打这些电话**：默认有专属客服的回自己人手上、无主的给当前手上最少的；他可以移出某几个人、改派给谁、单独给某位客服少分点 | 程序按规则落，主管微调 |
| **③ 确认** | **要不要就这么发下去** —— 摆在他面前，他点下去这一刻才真的分下去 | 只有主管 |
| **④ 确认之后** | **发出去之后怎么管**：发错了限时撤回、临时加个福利、跟踪这批打得怎么样 | 主管发起，程序执行 |
**这一环在「选人」之前** —— 先把问题摆清楚，再看谁答得了。
<Callout type="info">**①是运营策略，②是排班。** 主管真正在想的是「这个月主推种植，把一两年没来、消费额够的那批捞出来，看看大家手上还接得住多少」——而不是在操作界面。界面只是把这句话变成可点的形状。</Callout>
| | 要回答的 | 谁答 | 凭什么 |
|---|---|---|---|
| **1** | 做哪一类还没启动的治疗（种植 / 正畸 / 拔牙…） | **主管** | 这个季度的经营重点 |
| **2** | 找多久没来的人（三个月内 … 三年以上） | **主管** | 经验 —— 见下 |
| **3** | 要不要只挑高价值的（消费额、商保、意向） | 主管定，**助手先摆数据** | 这批人的画像构成、消费分布 |
| **4** | 团队还吃得下多少、几天内打完 | 主管定，**助手先摆数据** | 在岗几人、各自手上压着多少 |
### 「发多大」不是拍脑袋，是看团队接不接得住
**1 和 2 是运营意图，主管张口就来；3 和 4 他答不了** —— 不把全景摆在面前，「要不要只挑高价值的」根本没法回答：他不知道这批人里有多少是高价值的，也不知道切完还剩几个。
这是主管在 ① 里最实际的一项顾虑：**人捞得太多，客服打不完，到期回池等于白发一轮。**
<Callout type="info">**「多久没来」不只是一个筛选条件。**
有经验的主管能从它估出这批大概能回来多少 —— 一两年没来的和三年以上的，回头率不是一个量级。
这个估算往下游走一步就是**诊所的排班**：预计能回来多少人、多少要做种植，医生和科室要不要提前留位。
⇒ 所以这一项**必须由主管拍**，⛔ 系统不代劳、也不推荐。</Callout>
所以人手这件事在两个地方主动摆给他看：
### 选人 = 主管初选 + 助手精选
| | 主管初选 | 助手精选 |
|---|---|---|
| **答哪几问** | 1 做哪类治疗 · 2 多久没来 | 3 要不要挑高价值 · 4 团队吃得下多少 |
| **他给的是** | 运营意图（一句话） | —— |
| **助手给的是** | —— | **全景数据 + 一版已经分好的方案** |
| **结果** | 一批候选人 | 一批确定的人 + 谁打给谁 |
助手在这一步不是"等他再下一个指令"，而是**先把该看的摆出来、顺手把方案做出来**：这批人的画像构成、消费分布、在岗几人、各自手上压着多少、这批发下去谁最忙。主管看着这些改，或者直接确认。
⚠️ 人手这件事在**两个地方**主动摆给他看，⛔ 不用他去找：
| 什么时候 | 他看到什么 |
|---|---|
| **出方案时** | 这批多大是按「在岗人数 × 每人每天几通 × 时效」估的，式子和用到的每个数都写出来 —— 他要改哪个都行 |
| **确认单上** | 每位客服一行「分完之后约几天打完」，算的是**分完后他手上的总量**（在手 + 本批），⛔ 不只是本批那几条 |
| **出方案时** | 「本批 405 人 = 在岗 27 人 × 每天 15 通 × 1 天」—— 式子和每个数都摊开，他改哪个都行 |
| **确认单上** | 每位客服一行「约 3 天」，算的是**分完之后他手上的总量**（在手 + 本批），⛔ 不只是本批那几条 |
超出本批时效的用**颜色**提示，⛔ 不写「打不完 / 超了 / 过载」—— 几乎每批都会有人超，说成故障主管就会开始怀疑系统，而不是做他该做的判断。
### 后三步
| 步 | 主管在决定什么 | 谁来做 |
|---|---|---|
| **② 分人** | **谁去打这些电话**：默认有专属客服的回自己人手上、无主的给当前手上最少的；他可以移出某几个人、改派给谁、单独给某位少分点 | 程序按规则落，主管微调 |
| **③ 确认** | **要不要就这么发下去** —— 他点下去这一刻才真的分下去 | 只有主管 |
| **④ 确认之后** | **发出去之后怎么管**：发错了限时撤回、临时加个福利、跟踪这批打得怎么样 | 主管发起，程序执行 |
### 红色那个菱形，是助手在这条线上**唯一实质的判断**
主管说一句话，助手要判断他动的是哪一层：
......@@ -79,7 +108,7 @@ flowchart TD
| 他说 | 动的是 | 走 |
|---|---|---|
| 「王强移出这批」「待分配都还给专属」「给 5 天」「带个福利」 | **② 分人** | 就地改，同一版 |
| 「只要商保直付的」「改成 200 人」「换成一两年没来的」 | **① 选人** | 重跑，出新版 |
| 「只要商保直付的」「改成 200 人」「换成一两年没来的」 | **① 选人**（初选那两问、精选那两问，都算） | 重跑，出新版 |
<Callout type="warn">**代价不对称**：把「① 选人」误判成「② 分人」→ 主管以为条件生效了、其实没有（**看不出来的错**）；反过来只是多算一次。⇒ **拿不准时一律走重跑。**</Callout>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment