Support ticket triage

何时使用

• 新的支持工单、客户消息或问题描述进来，需要：归类、定优先级、判断负责团队、判重（是否重复或已知问题）后再路由。
• 需要在路由前产出一份结构化分诊评估，并附一段可直接发出的初步回复草稿。

不该用的边界：

• 已确定归属、只需撰写完整客服回复正文 -> 用对应的回复撰写技能，本技能只产出首响草稿。
• 需要正式升级（打包上报、拉相关方）-> 转交升级类技能（如 customer-escalation），本技能只标注升级触发条件。
• 与单条工单无关的批量数据分析、报表统计，不在本技能范围。

步骤

1. 解析问题

从输入中抽取：核心问题（客户实际遭遇什么）、症状（具体行为/报错）、客户上下文（账号、套餐、历史）、紧急信号（是否阻塞、是否生产环境、影响人数）、情绪状态（受挫/困惑/平静/正在升级）。

2. 归类与定级

• 用下方分类法定一个主分类，必要时加一个次分类。
• 用下方优先级框架定 P1-P4。
• 标出对应的产品域/团队。

3. 判重与已知问题

路由前检查可用数据源：

• 支持平台：搜相似的未结/近期已解决工单。
• 知识库：查已知问题或现有文档。
• 项目跟踪器：查是否已有缺陷单或需求单。

按下方「判重流程」处理。

4. 确定路由

按下方路由规则，依据分类与复杂度建议由哪个团队/队列接手。

5. 产出分诊结果

按固定模板输出（见下方示例）。

6. 给出下一步

呈现分诊后主动追问：是否要起草完整回复？是否要再搜更多上下文？是否要在跟踪器里查这是不是已知 bug？是否要升级（可用 /customer-escalation 打包）？

指令

分类法（主分类，可选次分类）

分类	说明	信号词
Bug 缺陷	产品行为异常/不符预期	报错、坏了、崩溃、不工作、异常、错误、失败
How-to 用法	客户需要使用指引	怎么做、能不能、在哪里、如何设置、配置、求助
Feature request 需求	想要尚不存在的能力	要是能…就好、希望可以、有没有计划、申请
Billing 账单	支付/订阅/发票/定价	扣费、发票、付款、订阅、退款、升级、降级
Account 账户	访问/权限/设置/用户管理	登录、密码、权限、SSO、被锁、登不上
Integration 集成	第三方/API 对接	API、webhook、集成、连接、OAuth、同步、第三方
Security 安全	安全/数据访问/合规	数据泄露、未授权、合规、GDPR、SOC 2、漏洞
Data 数据	数据质量/迁移/导入导出	数据丢失、导出、导入、迁移、数据错误、重复
Performance 性能	速度/可靠性/可用性	慢、超时、延迟、宕机、不可用、降级

判定要点：同时有 bug 和需求时，bug 为主分类；因 bug 导致登不上，归 Bug 而非 Account（按根因归类）；「以前能用现在不行」= Bug；「想换种方式工作」= Feature request；「怎么才能用」= How-to；拿不准时偏向 Bug（宁可排查也别误判）。

优先级框架

• P1 危急：生产宕机、数据丢失/损坏、安全事件、全部或多数用户受影响。SLA：1 小时内响应，持续处理直至解决/缓解，每 1-2 小时更新。
• P2 高：核心功能损坏、关键流程受阻、多用户受影响、无变通方案。SLA：4 小时内响应，当天积极排查，每 4 小时更新。
• P3 中：功能部分损坏但有变通方案、单用户或小团队受影响。SLA：1 个工作日内响应，3 个工作日内解决/更新。
• P4 低：轻微不便、外观问题、一般咨询、需求建议。SLA：2 个工作日内响应，正常节奏解决。

优先级自动上调触发器：等待已超 SLA；多客户报同一问题（出现模式）；客户明确升级或提及高管介入；原有变通方案失效；问题范围扩大（更多用户/数据/新症状）。

路由规则

路由至	何时
一线支持 Tier 1	How-to、有文档解法的已知问题、账单咨询、重置密码
二线支持 Tier 2	需排查的 bug、复杂配置、集成排障、账户问题
工程 Engineering	已确认需改代码的 bug、基础设施问题、性能劣化
产品 Product	需求量大的功能请求、设计决策、流程缺口
安全 Security	数据访问顾虑、漏洞报告、合规问题
账单/财务	退款、合同争议、复杂账单调整

判重流程

1. 按症状搜：相似报错/描述。2. 按客户搜：该客户是否已有同问题工单。3. 按产品域搜：同功能区近期工单。4. 对比已知问题文档。

命中重复时：把新单关联到既有单；告知客户这是正在跟踪的已知问题；把新报告中的新信息补进既有单；若新报告增加紧急度（更多客户受影响等）则上调优先级。

示例

输入：客户反映今早起仪表盘一直白屏

输出模板：

## 分诊：[一句话问题概述]

分类：[主] / [次（若有）]
优先级：[P1-P4] — [简要依据]
产品域：[区域/团队]

### 问题概述
[2-3 句话描述客户遭遇]

### 关键细节
- 客户：[姓名/账号（若知）]
- 影响：[谁、什么受影响]
- 变通方案：[有 / 无 / 未知]
- 相关工单：[相似问题链接（若找到）]
- 已知问题：[是—链接 / 否 / 排查中]

### 路由建议
路由至：[团队或队列]
理由：[简要说明]

### 建议初步回复
[首响草稿：确认问题、设定预期、若有变通方案则给出。
可用下方各分类自动回复模板作为起点。]

### 内部备注
- [接手者所需的额外上下文]
- [若为 bug 的复现线索]
- [需留意的升级触发条件]

各分类首响模板（要点）：

• Bug：感谢上报 + 共情具体影响 + 已按[优先级]登记并在排查 +（有则给变通）+ [SLA 时限]内更新。
• How-to：直接给答案/文档链接，复杂则分步引导，结尾邀请追问。
• 需求：感谢建议 + 认可价值 + 已记录并同步产品团队（不承诺具体时间）+（有则给替代方案）。
• 账单：表示会优先处理 + 简单则直接给结论，复杂则说明正在核对、[时限]内答复。
• 安全：感谢上报 + 已立即升级安全团队 + [时限]内反馈 +（需要则给防护措施建议）。

注意事项

1. 先读完整张工单再归类——后续消息里的上下文常改变判断。
2. 按根因归类，而非仅看表面症状。
3. 优先级拿不准时往高了定——降级比补救漏掉的 SLA 容易。
4. 路由前务必查重与已知问题。
5. 写清内部备注，让下一个人快速接上上下文。
6. 注明已检查/已排除的项，避免重复排查。
7. 标记模式——同一问题反复出现时升级该模式，即便单张工单优先级低。

互见

• 升级处理：/customer-escalation（把工单打包上报）。
• 完整回复撰写、知识库检索等后续技能（按本仓库同域条目）。

---

采编自 anthropics/knowledge-work-plugins（customer-support/ticket-triage），许可证 Apache-2.0。