ticket-triage

/ticket-triage

如果您看到不熟悉的占位符，或需要确认哪些工具已连接，请参阅 CONNECTORS.md。

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

用法

/ticket-triage <ticket text, customer message, or issue description>

示例：

• /ticket-triage Customer says their dashboard has been showing a blank page since this morning
• /ticket-triage "I was charged twice for my subscription this month"
• /ticket-triage User can't connect their SSO — getting a 403 error on the callback URL
• /ticket-triage Feature request: they want to export reports as PDF

工作流程

1. 解析问题

阅读输入内容，提取以下信息：

• 核心问题：客户实际遇到了什么问题？
• 症状：客户看到了什么具体行为或错误？
• 客户背景：客户是谁？有无账户详情、套餐等级或历史记录？
• 紧急信号：客户是否无法继续工作？是否涉及生产环境？受影响用户有多少？
• 情绪状态：沮丧、困惑、就事论事，还是情绪正在升级？

2. 分类与排序优先级

依据下方的分类体系与优先级框架：

• 指定主要类别（bug、how-to、功能请求、账单、账户、集成、安全、数据、性能），并可选指定次要类别
• 根据影响范围与紧急程度指定优先级（P1–P4）
• 确定问题所属的产品领域

3. 检查重复项与已知问题

分派前，检查可用来源：

• ~~支持平台：搜索类似的未关闭或近期已解决的工单
• ~~知识库：检查已知问题或现有文档
• ~~项目跟踪器：检查是否已有对应的 bug 报告或功能请求

应用下方的重复项检测流程。

4. 确定分派方式

依据下方的分派规则，结合类别与复杂度，建议由哪个团队或队列处理。

5. 生成分诊输出

## Triage: [One-line issue summary]

**Category:** [Primary] / [Secondary if applicable]
**Priority:** [P1-P4] — [Brief justification]
**Product area:** [Area/team]

### Issue Summary
[2-3 sentence summary of what the customer is experiencing]

### Key Details
- **Customer:** [Name/account if known]
- **Impact:** [Who and what is affected]
- **Workaround:** [Available / Not available / Unknown]
- **Related tickets:** [Links to similar issues if found]
- **Known issue:** [Yes — link / No / Checking]

### Routing Recommendation
**Route to:** [Team or queue]
**Why:** [Brief reasoning]

### Suggested Initial Response
[Draft first response to the customer — acknowledge the issue,
set expectations, provide workaround if available.
Use the auto-response templates below as a starting point.]

### Internal Notes
- [Any additional context for the agent picking this up]
- [Reproduction hints if it's a bug]
- [Escalation triggers to watch for]

6. 提供后续步骤

呈现分诊结果后：

• "需要我起草一份完整的客户回复吗？"
• "需要我搜索该问题的更多背景信息吗？"
• "需要我在跟踪器中检查这是否为已知 bug 吗？"
• "需要升级此问题吗？我可以使用 /customer-escalation 为其打包。"

---

类别分类体系

每张工单都需指定一个主要类别，并可选指定一个次要类别：

类别	说明	信号词
Bug	产品行为不正确或不符合预期	Error、broken、crash、not working、unexpected、wrong、failing
How-to	客户需要产品使用指导	How do I、can I、where is、setting up、configure、help with
功能请求	客户希望获得尚不存在的功能	Would be great if、wish I could、any plans to、requesting
账单	支付、订阅、发票或定价问题	Charge、invoice、payment、subscription、refund、upgrade、downgrade
账户	账户访问、权限、设置或用户管理	Login、password、access、permission、SSO、locked out、can't sign in
集成	连接第三方工具或 API 时出现的问题	API、webhook、integration、connect、OAuth、sync、third-party
安全	安全问题、数据访问或合规性问题	Data breach、unauthorized、compliance、GDPR、SOC 2、vulnerability
数据	数据质量、迁移、导入/导出问题	Missing data、export、import、migration、incorrect data、duplicates
性能	速度、可靠性或可用性问题	Slow、timeout、latency、down、unavailable、degraded

分类判定提示

• 如果客户同时报告了缺陷和功能需求，以缺陷为主
• 如果客户因缺陷无法登录，分类为缺陷（而非账户）：根本原因决定分类
• “以前能用，现在不能用了”= 缺陷
• “我希望它以不同的方式工作”= 功能需求
• “我该怎么做才能让它工作？”= 操作指导
• 拿不准时，倾向于判定为缺陷：调查总比直接驳回更好

优先级框架

P1 — 严重

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

• 客户完全无法使用产品
• 数据正在丢失、损坏或暴露
• 安全事件正在进行中
• 问题正在恶化或影响范围扩大

SLA 预期： 1 小时内响应。持续处理直至解决或缓解。每 1-2 小时更新一次。

P2 — 高

标准： 主要功能故障、重要工作流受阻、大量用户受影响、没有临时解决方案。

• 核心工作流中断，但产品仍部分可用
• 多名用户受影响，或关键客户受到影响
• 问题阻碍了时间敏感的工作
• 不存在合理的临时解决方案

SLA 预期： 4 小时内响应。当天开展积极调查。每 4 小时更新一次。

P3 — 中

标准： 功能部分故障、存在临时解决方案、单个用户或小团队受影响。

• 某项功能无法正常工作，但存在临时解决方案
• 问题带来不便，但不阻碍关键工作
• 单个用户或小团队受影响
• 客户没有紧急升级诉求

SLA 预期： 1 个工作日内响应。3 个工作日内解决或提供更新。

P4 — 低

标准： 轻微不便、外观问题、一般性问题、功能需求。

• 不影响功能的外观或界面问题
• 功能需求和改进建议
• 一般性问题或操作指导咨询
• 有简单且有文档记录解决方案的问题

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

优先级升级触发条件

在以下情况下自动提高优先级：

• 客户等待时间超出 SLA 允许的范围
• 多名客户报告同一问题（检测到规律性模式）
• 客户明确要求升级，或提及高层介入
• 原本有效的临时解决方案失效
• 问题影响范围扩大（更多用户、更多数据、出现新症状）

路由规则

根据分类和复杂度路由工单：

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

重复工单检测

在创建新工单或进行路由之前，先检查是否存在重复：

1. 按症状搜索：查找错误信息或描述相似的工单
2. 按客户搜索：检查该客户是否已有针对同一问题的未关闭工单
3. 按产品领域搜索：查找同一功能领域的近期工单
4. 检查已知问题：与已记录的已知问题进行比对

如果发现重复：

• 将新工单关联到已有工单
• 告知客户该问题是已知问题，目前正在跟踪
• 将新报告中的新信息补充到已有工单中
• 如果新报告增加了紧迫性（如受影响客户增多等），提高优先级

按分类的自动回复模板

缺陷 — 初始回复

Thank you for reporting this. I can see how [specific impact]
would be disruptive for your work.

I've logged this as a [priority] issue and our team is
investigating. [If workaround exists: "In the meantime, you
can [workaround]."]

I'll update you within [SLA timeframe] with what we find.

操作指导 — 初次回复

Great question! [Direct answer or link to documentation]

[If more complex: "Let me walk you through the steps:"]
[Steps or guidance]

Let me know if that helps, or if you have any follow-up
questions.

功能请求 — 初次回复

Thank you for this suggestion — I can see why [capability]
would be valuable for your workflow.

I've documented this and shared it with our product team.
While I can't commit to a specific timeline, your feedback
directly informs our roadmap priorities.

[If alternative exists: "In the meantime, you might find
[alternative] helpful for achieving something similar."]

账单 — 初次回复

I understand billing issues need prompt attention. Let me
look into this for you.

[If straightforward: resolution details]
[If complex: "I'm reviewing your account now and will have
an answer for you within [timeframe]."]

安全 — 初次回复

Thank you for flagging this — we take security concerns
seriously and are reviewing this immediately.

I've escalated this to our security team for investigation.
We'll follow up with you within [timeframe] with our findings.

[If action is needed: "In the meantime, we recommend
[protective action]."]

工单分诊最佳实践

1. 在分类之前通读完整工单，后续消息中的上下文往往会改变判断
2. 按根本原因分类，而不只是按所描述的表面现象
3. 对优先级存疑时，宁可调高——降级比补救漏掉的 SLA 更容易
4. 路由之前，务必检查是否有重复工单和已知问题
5. 撰写内部备注，帮助下一位接手者快速了解上下文
6. 记录你已经检查或排除过的内容，避免重复排查
7. 留意模式——如果同一问题反复出现，即使单个工单优先级较低，也应将该模式上报升级