/ticket-triage

如果您看到不熟悉的占位符或需要检查已连接的工具,请参阅 CONNECTORS.md

对收到的支持工单或客户问题进行分类、优先级排序和路由。生成结构化的分类评估,并附带建议的初始回复。

用法

/ticket-triage <工单文本、客户消息或问题描述>

示例:

工作流

1. 解析问题

读取输入并提取:

2. 分类和优先级排序

使用下面的类别分类法和优先级框架:

3. 检查重复和已知问题

在路由之前,检查可用来源:

应用下面的重复检测流程。

4. 确定路由

使用下面的路由规则,根据类别和复杂性建议应由哪个团队或队列处理。

5. 生成分类输出

## 分类:[一句话问题摘要]

**类别:** [主要] / [次要(如适用)]
**优先级:** [P1-P4] — [简要理由]
**产品领域:** [领域/团队]

### 问题摘要
[2-3句话总结客户遇到的情况]

### 关键详情
- **客户:** [姓名/账户如已知]
- **影响:** [谁和什么受影响]
- **变通方案:** [有 / 无 / 未知]
- **相关工单:** [如发现类似问题的链接]
- **已知问题:** [是——链接 / 否 / 正在检查]

### 路由建议
**路由至:** [团队或队列]
**理由:** [简要推理]

### 建议的初始回复
[给客户的第一个回复草稿——确认问题、
设定预期、如有变通方案则提供。
使用下面的自动回复模板作为起点。]

### 内部备注
- [接手此工单的人员需要的任何额外背景]
- [如果是错误,提供复现提示]
- [需要注意的升级触发条件]

6. 提供后续步骤

呈现分类信息后:


类别分类法

为每个工单分配一个主要类别和可选的一个次要类别

类别 描述 信号词
错误 产品行为不正确或意外 错误、坏了、崩溃、不工作、意外、不对、失败
操作指南 客户需要产品使用指导 如何、能不能、在哪里、设置、配置、帮助
功能请求 客户想要一个尚不存在的功能 如果能就好了、希望可以、有计划吗、请求
计费 支付、订阅、发票或定价问题 扣费、发票、支付、订阅、退款、升级、降级
账户 账户访问、权限、设置或用户管理 登录、密码、访问、权限、SSO、被锁、无法登录
集成 连接到第三方工具或 API 的问题 API、webhook、集成、连接、OAuth、同步、第三方
安全 安全问题、数据访问或合规询问 数据泄露、未授权、合规、GDPR、SOC 2、漏洞
数据 数据质量、迁移、导入/导出问题 数据丢失、导出、导入、迁移、数据错误、重复
性能 速度、可靠性或可用性问题 慢、超时、延迟、宕机、不可用、降级

类别判断提示

优先级框架

P1 — 严重

标准: 生产系统宕机、数据丢失或损坏、安全漏洞、所有或大部分用户受影响。

SLA 期望: 1 小时内响应。持续工作直至解决或缓解。每 1-2 小时更新一次。

P2 — 高

标准: 主要功能损坏、重要工作流受阻、许多用户受影响、无变通方案。

SLA 期望: 4 小时内响应。当天积极调查。每 4 小时更新一次。

P3 — 中

标准: 功能部分损坏、有变通方案、单个用户或小团队受影响。

SLA 期望: 1 个工作日内响应。3 个工作日内解决或更新。

P4 — 低

标准: 轻微不便、外观问题、一般问题、功能请求。

SLA 期望: 2 个工作日内响应。按正常节奏解决。

优先级升级触发条件

在以下情况下自动提升优先级:

路由规则

根据类别和复杂性路由工单:

路由至 适用情况
第一级(一线支持) 操作指南问题、有文档记录的已知问题、计费咨询、密码重置
第二级(高级支持) 需要调查的错误、复杂配置、集成故障排除、账户问题
工程 已确认需要代码修复的错误、基础设施问题、性能下降
产品 有较大需求的功能请求、设计决策、工作流缺口
安全 数据访问问题、漏洞报告、合规问题
计费/财务 退款请求、合同争议、复杂的计费调整

重复检测

在创建新工单或路由之前,检查是否有重复:

  1. 按症状搜索:查找具有类似错误消息或描述的工单
  2. 按客户搜索:检查该客户是否有关于同一问题的开放工单
  3. 按产品领域搜索:查找同一功能领域最近的工单
  4. 检查已知问题:对照已记录的已知问题进行比对

如果发现重复:

按类别的自动回复模板

错误——初始回复

感谢您报告此问题。我能理解 [具体影响]
会对您的工作造成干扰。

我已将此记录为 [优先级] 问题,我们的团队正在
调查。[如有变通方案:"在此期间,您可以
[变通方案]。"]

我将在 [SLA 时间范围] 内向您更新我们的发现。

操作指南——初始回复


好问题![直接答案或文档链接]

[如果更复杂:"让我为您逐步说明:"]
[步骤或指导]

如果有帮助请告知,或者如果您有任何后续问题。

功能请求——初始回复

感谢您的建议——我能理解 [功能]
对您的工作流程会很有价值。

我已记录此请求并与我们的产品团队分享。
虽然我无法承诺具体的时间线,但您的反馈
直接影响了我们的路线图优先级。

[如有替代方案:"在此期间,您可能会发现
[替代方案] 有助于实现类似目的。"]

计费——初始回复

我理解计费问题需要及时处理。让我为您
查一下。

[如果是直接的问题:解决方案详情]
[如果复杂:"我正在审阅您的账户,将在 [时间范围] 内
给您答复。"]

安全——初始回复

感谢您报告此事——我们严肃对待安全问题,
正在立即审查。

我已将此问题升级给我们的安全团队进行调查。
我们将在 [时间范围] 内与您跟进我们的发现。

[如需采取行动:"在此期间,我们建议
[保护措施]。"]

分类最佳实践

  1. 在分类之前阅读完整的工单——后面消息中的上下文通常会改变评估
  2. 根本原因分类,而不仅仅是所描述的症状
  3. 对优先级有疑问时,倾向于更高的级别——降级总比因错过 SLA 而补救要容易
  4. 在路由之前始终检查重复工单和已知问题
  5. 编写有助于下一个人快速了解上下文的内部备注
  6. 包含您已经检查或排除的内容,以避免重复调查
  7. 标记模式——如果您反复看到同一问题,即使单个工单优先级较低,也要升级该模式