工单流转
工单的设计目标
工单是售后处理的主载体。它的设计目标不是"记录一切"，而是让客服打开后台时能在 30 秒内回答四个问题：
- 客户遇到什么问题
- 严重程度如何
- 关联哪个订单
- 下一步做什么
字段设计围绕客服处理动线，而不是围绕技术表结构。
工单字段
tickets 表的核心字段：
| 字段 | 类型 | 用途 |
|---|---|---|
id | uuid | 工单主键 |
merchant_id | FK | 商家隔离 |
conversation_id | FK (nullable) | 关联会话，便于回看上下文 |
customer_id | FK (nullable) | 关联客户 |
category | enum | 退款/投诉/漏餐/错餐/变质/差评/团餐/咨询 |
priority | enum | low / medium / high / urgent |
status | enum | open / in_progress / resolved / closed |
title | text | 客服列表展示 |
description | text | 完整描述（含客户原话、AI 摘要、触发规则） |
related_order_id | uuid (软引用) | 关联订单 |
assigned_to | text | 接手客服 |
resolution | text | 处理结果 |
created_at / resolved_at | timestamp | 时间追溯 |
description 字段是工单的灵魂。它必须包含三类信息：
【客户原话】
"我点的捞汁皮皮虾 送来的是花蛤！"
【AI 摘要】
客户反馈订单 MT-20260503-001 配送错餐，AI 已致歉并记录。
【触发规则】
转人工规则 #3（负面情绪 + 错餐投诉），优先级 high
这种格式让客服看到工单时，既能听到客户的原声，又能快速理解处理建议。
状态流转
| 状态 | 含义 | 谁能切换 |
|---|---|---|
open | 已创建但未处理 | 系统创建 |
in_progress | 客服已接手 | 客服点击"接手" |
resolved | 已有处理结果 | 客服填写 resolution |
closed | 客户无后续或复盘完成 | 客服或定时任务 |
关键区分：会话状态和工单状态是两个独立概念。会话可以已 closed（客户离开），工单仍需在后台处理。例如客户投诉错餐，AI 致歉并建工单，客户暂时离开会话，但工单仍然 open 直到老板补发或退款。
会话状态：ai → pending_human → human → closed
│
│（独立）
↓
工单状态：open → in_progress → resolved → closed
自动创建规则
AI 可以在以下场景自动创建工单：
| 客户场景 | 自动 category | 自动 priority | 是否同步转人工 |
|---|---|---|---|
| 漏餐 | 漏餐 | high | 是 |
| 错餐 | 错餐 | high | 是 |
| 食品质量 / 变质 | 变质 | urgent | 是 |
| 主动要求退款 | 退款 | medium-high | 视情况 |
| 配送过慢投诉 | 投诉 | medium | 视情况 |
| 食品安全 / 过敏 | 投诉 | urgent | 是 |
| 团餐咨询 | 团餐 | low | 否 |
自动创建 ≠ 自动解决。工单一旦创建，必须有人工处理结果（resolution）才能 resolved。AI 创建工单的目的是把上下文打包给客服，不是把问题"标记"成已处理。
工单 description 自动写入：
- 客户原话（最近 3 条 customer message）
- 触发规则编号
- 已识别的 intent
- 关联订单号（如能识别）
- AI 给出的初步建议（基于知识库）
处理流程
[工单 open] ──> [客服打开后台] ──> [按 priority 排序]
│
↓
[点击进入工单详情页]
│
↓
[自动 status='in_progress']
│
↓
[查看上下文 + 处理决策]
│
┌──────────────────┼──────────────────┐
↓ ↓ ↓
[联系客户] [更新订单] [内部协同]
(微信/电话) (退款/补发) (骑手平台)
└──────────────────┴──────────────────┘
│
↓
[填写 resolution]
│
↓
[status='resolved']
resolution 必须记录三件事：处理动作（如"已退款 38 元"）、客户确认（如"客户已收到退款"）、是否需要后续跟进（如"7 天内回访")。
工单指标
工单指标进入商家后台数据看板：
| 指标 | 用途 | 异常信号 |
|---|---|---|
| 新建量（日 / 周 / 月） | 售后压力趋势 | 突增需要复盘 |
| 未处理量（open / in_progress） | 实时处理压力 | 持续高位说明响应慢 |
| 平均解决时长 | 服务效率 | 紧急 > 1 小时需要排查 |
| 类别分布 | 售后问题集中点 | 某类突增需要根因分析 |
| 重复投诉率 | 客户问题是否真解决 | > 10% 需要复盘处理质量 |
| 自动创建占比 | AI 接管度 | < 60% 说明 AI 没识别到 |
这些指标是发现运营问题的入口。例如某菜品（皮皮虾）连续两周变质投诉激增，可能是供应链或冷链有问题；某时段（21-23 点）配送投诉集中，可能是骑手平台高峰期协同不够。
工单与知识库的回路
每张工单解决后，系统提示"是否将本次处理 SOP 写入知识库？"商家点"是"后，工单 resolution 字段进入草稿状态作为候选条目。这是知识库新增的最高质量来源——
- 客服真实处理过 → 准确性高
- 商家审核过 → 符合实际规则
- 问题边界清晰 → 不易越权
详细维护节奏参见 03-knowledge/04-maintenance-sop。
设计取舍
工单系统的几个明确取舍：
- 不做工单合并：相似工单不自动合并，因为每个客户的诉求时间和上下文不同
- 不做工单转派：单店场景下没必要，多店扩展时再考虑
- 不做 SLA 强制：只显示响应时长，不强制超时升级，避免给小商家带来压力
- 不做客户侧工单查询：客户通过 widget 看到的是"老板正在处理"，不是工单详情
这些取舍让工单系统聚焦于"中小商家用得起来"，而不是模仿大型工单平台的复杂功能。