> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Task 员工归因与任务流转设计

> **Historical proposal / Superseded（2026-07-15）**：本文基于旧字段设计。Recorder 与 credited staff 分离的需求已纳入 [Task System Design](/product-design/v3/tasks-feature/task-domain-lifecycle.md)；其余 schema/flow 不得直接实施。

来源：Oliver 2026-03-24 反馈，基于 [Task 字段设计](/product-design/v1/tasks-feature/tasks-field-design.md) 提出的扩展需求。

***

## 一、问题总览

当前 Task 字段设计覆盖了"任务从创建到关闭"的基本流程，但缺少以下维度：

| # | 缺失维度      | 现状                                | 影响                      |
| - | --------- | --------------------------------- | ----------------------- |
| 1 | 员工执行动作记录  | 只记录 `closeResult`（业务结果），不记录员工做了什么 | 无法衡量员工工作量，无法分析哪些动作组合最有效 |
| 2 | 关闭人 ≠ 促成人 | `closedByStaffId` 一个字段兼任两个角色      | 归因不准确，功劳可能算错人           |
| 3 | 多触点信用分配   | 只归因给最后关闭任务的人                      | 前期大量跟进工作无法体现，影响员工积极性    |
| 4 | 任务转接与重开   | 无分配、转交、重开机制                       | 无法追踪任务在员工间的流转历史         |

***

## 二、员工执行动作记录

### 2.1 问题

> 在关闭一个任务之前可能有一系列的任务需要员工去做。比如说，现在有一个新的 lead 进来，已经打过一次电话。那 front desk 可能就还需要再打一次，或者是再需要发一个邮件，再发一个短信。 — Oliver

当前 `closeResult` 记录的是**业务结果**（converted、complaint\_resolved 等），但不记录员工为达成这个结果**具体执行了哪些动作**。一个 task 完成后不一定有直接 outcome，但知道员工做了什么本身就有分析价值。

### 2.2 建议字段

新增 `completedActions`（List），在关闭任务时由员工多选，记录本次任务中实际执行的动作：

| 值                       | 显示文案                  | 说明        |
| ----------------------- | --------------------- | --------- |
| `call_completed`        | Call Completed        | 完成了电话联系   |
| `sms_sent`              | SMS Sent              | 发送了短信     |
| `voicemail_left`        | Voicemail Left        | 留了语音留言    |
| `escalation_to_manager` | Escalation to Manager | 上报经理处理    |
| `complaint_resolved`    | Complaint Resolved    | 投诉已解决     |
| `retention_offer_made`  | Retention Offer Made  | 提供了挽留优惠方案 |
| `renewal_discussed`     | Renewal Discussed     | 讨论了续约事宜   |
| `referral_requested`    | Referral Requested    | 请求了客户推荐   |

### 2.3 分析价值

- 哪些动作组合最容易促成 converted？
- 平均每个 task 需要几个动作才能关闭？
- 哪些 typeCategory 的任务倾向于需要 escalation\_to\_manager？

***

## 三、关闭人与促成人分离

### 3.1 问题

> Sometimes one person closes the task, but another person converts the lead/member. We need to decide whether attribution goes to the closer of the task, the closer of the sale/save, or both in separate ways. — Oliver

现实场景：Staff A 一直在跟进这个客户（打电话、发短信），但 Staff B 在客户到店时完成了签约。当前只有 `closedByStaffId`，无法区分这两个角色。

### 3.2 建议字段

将当前的 `closedByStaffId` / `closedByStaffName` 拆分为两组：

| 字段                         | 类型          | 写入者   | 说明                       |
| -------------------------- | ----------- | ----- | ------------------------ |
| `taskCompletedByStaffId`   | String (FK) | 员工    | 谁完成（关闭）了这个任务——操作层面       |
| `taskCompletedByStaffName` | String      | 员工    | 完成任务的员工姓名                |
| `outcomeOwnerStaffId`      | String (FK) | 员工    | 谁促成了业务结果（签约/挽留/升级）——归因层面 |
| `outcomeOwnerStaffName`    | String      | 员工    | 促成业务结果的员工姓名              |
| `outcomeAt`                | Timestamp   | 系统/员工 | 业务结果实际发生的时间（≠ closedAt）  |

### 3.3 与现有字段的关系

| 现有字段                | 处理方式                                                      |
| ------------------- | --------------------------------------------------------- |
| `closedByStaffId`   | → 拆为 `taskCompletedByStaffId` + `outcomeOwnerStaffId`     |
| `closedByStaffName` | → 拆为 `taskCompletedByStaffName` + `outcomeOwnerStaffName` |
| `closedAt`          | 保留，表示任务关闭时间                                               |
| —                   | 新增 `outcomeAt`，表示业务结果发生时间                                 |

***

## 四、多触点信用分配（Multi-touch Attribution）

### 4.1 问题

> A lead may have: outreach task → follow-up task → booked-not-converted task → another follow-up task. If you want real attribution, you need to handle: first touch, assist touch, closing touch. — Oliver

一个客户从进入系统到最终成交，可能经历多个 task，每个 task 可能由不同员工完成。只把功劳算给最后一个 task 的人，对前面做了大量工作的人不公平。

### 4.2 建议字段

新增 `creditType`（String），标识该任务在归因链中的角色：

| 值                  | 显示文案             | 说明            | 归因权重         |
| ------------------ | ---------------- | ------------- | ------------ |
| `full`             | Full Credit      | 唯一接触人，全部功劳    | 100%         |
| `assist`           | Assist Credit    | 参与了跟进但不是最终促成者 | 待定（如 30-50%） |
| `operational_only` | Operational Only | 无营收功劳，只算操作量   | 0%（仅计入工作量统计） |

### 4.3 触点角色

在一个客户的完整 task 链中，每个 task 扮演不同角色：

| 触点角色              | 含义             | 示例                           |
| ----------------- | -------------- | ---------------------------- |
| **First Touch**   | 最早接触客户的 task   | Lead Outreach — 第一次打电话       |
| **Assist Touch**  | 中间的跟进 task     | Follow-up — 第二次打电话、发短信       |
| **Closing Touch** | 最终促成业务结果的 task | Booked Not Converted — 到店后成交 |

### 4.4 与现有文档的关系

- [Lead 归因设计](/product-design/future-plans/lead-attribution.md) 定义了 Setter / Closer 两段分工模型
- [任务与营收归因](/product-design/future-plans/revenue-attribution.md) 定义了 closeResult → 营收类型映射
- 本设计补充的是：**同一归因链中多个 task 之间如何分配信用**

***

## 五、任务分配与转接

### 5.1 问题

> Missing scenario: task assigned to Staff A → Staff B actually completes it → then manager intervenes → then outcome happens. Need fields/history for: assignedToStaffId, reassignedFrom/reassignedTo, reopenedAt, reopenedReason. — Oliver

当前设计没有"任务分配给谁"的概念，也无法追踪任务在员工之间的转交。

### 5.2 建议字段

**任务分配**：

| 字段                    | 类型          | 写入者   | 说明       |
| --------------------- | ----------- | ----- | -------- |
| `assignedToStaffId`   | String (FK) | 系统/员工 | 当前任务分配给谁 |
| `assignedToStaffName` | String      | 系统/员工 | 被分配员工的姓名 |

**转接历史**（`reassignmentHistory`，List）：

| 子字段                | 类型          | 说明       |
| ------------------ | ----------- | -------- |
| `reassignedFrom`   | String (FK) | 原负责人     |
| `reassignedTo`     | String (FK) | 新负责人     |
| `reassignedAt`     | Timestamp   | 转交时间     |
| `reassignedReason` | String      | 转交原因（可选） |

**重开记录**：

| 字段               | 类型        | 写入者   | 说明                         |
| ---------------- | --------- | ----- | -------------------------- |
| `reopenedAt`     | Timestamp | 系统/员工 | 任务被重新打开的时间                 |
| `reopenedReason` | String    | 员工    | 为什么重新打开（如"客户反悔"、"问题未真正解决"） |

### 5.3 典型流转场景

```
Task 创建 → 自动分配给 Staff A（assignedToStaffId = A）
  → Staff A 打了电话没解决
  → 转交给 Staff B（reassignmentHistory += {from: A, to: B}）
  → Staff B 上报经理（completedActions += escalation_to_manager）
  → 经理介入解决（outcomeOwnerStaffId = Manager）
  → Staff B 关闭任务（taskCompletedByStaffId = B）
```

***

## 六、待讨论事项

| # | 问题                                         | 选项                       | 备注                                                                                  |
| - | ------------------------------------------ | ------------------------ | ----------------------------------------------------------------------------------- |
| 1 | `completedActions` 是在关闭时一次性勾选，还是执行过程中逐步记录？ | 一次性勾选更简单，逐步记录更准确         | 影响 UI 设计和数据准确性                                                                      |
| 2 | `creditType` 是手动指定还是系统根据 task 链自动计算？       | 自动计算更客观，但规则复杂            | 需要定义 first/assist/closing 的判定算法                                                     |
| 3 | Assist credit 的权重具体多少？                     | 固定比例 vs 按触点数量均分          | 参考 [Lead 归因设计](/product-design/future-plans/lead-attribution.md) 的 Setter/Closer 模型 |
| 4 | 任务转接时，原负责人的 `completedActions` 是否保留？       | 保留（记录所有人做了什么）vs 只记录最终完成人 | 影响工作量统计准确性                                                                          |
| 5 | 重开任务是否重置 `dueAt`？                          | 重置 vs 保留原 deadline       | 影响 SLA 统计                                                                           |
| 6 | 这些字段是 V1 还是 V2 实现？                         | V1 先上基础关闭流程，V2 加归因和流转    | 见后文 V2 Staff Attribution 节                                                          |

***

## 七、与现有文档的关系

| 文档                                                                  | 关系                               |
| ------------------------------------------------------------------- | -------------------------------- |
| [Task 字段设计](/product-design/v1/tasks-feature/tasks-field-design.md) | 本文扩展其关闭信息分组，增加动作记录、归因分离、转接字段     |
| [Lead 归因设计](/product-design/future-plans/lead-attribution.md)       | Setter/Closer 模型是 task 级归因的上层框架  |
| [任务与营收归因](/product-design/future-plans/revenue-attribution.md)      | closeResult → 营收映射不变，本文补充多触点信用分配 |