/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. 标记模式——如果您反复看到同一问题,即使单个工单优先级较低,也要升级该模式