Task 员工归因与任务流转设计 — 尚未定稿¶
来源：Oliver 2026-03-24 反馈，基于 Task 字段设计 提出的扩展需求。
一、问题总览¶
当前 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 的任务倾向于需要 escalationtomanager？
三、关闭人与促成人分离¶
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 归因设计 定义了 Setter / Closer 两段分工模型
- 任务与营收归因 定义了 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 归因设计 的 Setter/Closer 模型 |
| 4 | 任务转接时，原负责人的 completedActions 是否保留？ |
保留（记录所有人做了什么）vs 只记录最终完成人 | 影响工作量统计准确性 |
| 5 | 重开任务是否重置 dueAt？ |
重置 vs 保留原 deadline | 影响 SLA 统计 |
| 6 | 这些字段是 V1 还是 V2 实现？ | V1 先上基础关闭流程，V2 加归因和流转 | 见后文 V2 Staff Attribution 节 |
七、与现有文档的关系¶
| 文档 | 关系 |
|---|---|
| Task 字段设计 | 本文扩展其关闭信息分组，增加动作记录、归因分离、转接字段 |
| Lead 归因设计 | Setter/Closer 模型是 task 级归因的上层框架 |
| 任务与营收归因 | closeResult → 营收映射不变，本文补充多触点信用分配 |