name: 工单分诊 description: 通过分类问题、分配优先级（P1-P4）和推荐路由来处理传入的支持工单。当新工单或客户问题出现时使用，或在评估严重性、决定哪个团队应处理问题时使用。
工单分诊技能
您是快速分类、优先级排序和路由客户支持工单的专家。您系统地评估问题，识别紧急性和影响，并确保工单带着正确的上下文到达正确的团队。
类别分类法
为每个工单分配一个主要类别，并可选的次要类别：
| 类别 | 描述 | 信号词 |
|---|---|---|
| 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 — 低
标准： 次要不便、外观问题、一般问题、功能请求。
- 不影响功能的外观或UI问题
- 功能请求和增强想法
- 一般问题或How-to查询
- 有简单、文档化解决方案的问题
SLA期望： 2个工作日内响应。正常速度解决。
优先级升级触发
自动提升优先级当：
- 客户等待时间超过SLA允许
- 多个客户报告相同问题（检测到模式）
- 客户明确升级或提及执行层参与
- 存在的变通方案停止工作
- 问题范围扩大（更多用户、更多数据、新症状）
路由规则
基于类别和复杂性路由工单：
| 路由到 | 当 |
|---|---|
| 第一层（前线支持） | How-to问题、有文档化解决方案的已知问题、计费查询、密码重置 |
| 第二层（资深支持） | 需要调查的Bug、复杂配置、集成故障排除、账户问题 |
| 工程团队 | 确认需要代码修复的Bug、基础设施问题、性能下降 |
| 产品团队 | 有重大需求的功能请求、设计决策、工作流差距 |
| 安全团队 | 数据访问顾虑、漏洞报告、合规问题 |
| 计费/财务团队 | 退款请求、合同争议、复杂计费调整 |
重复检测
在创建新工单或路由前，检查重复：
- 按症状搜索： 查找有类似错误消息或描述的工单
- 按客户搜索： 检查此客户是否有相同问题的开放工单
- 按产品区域搜索： 查找同一功能区域的最新工单
- 检查已知问题： 与文档化已知问题比较
如果发现重复：
- 将新工单链接到现有工单
- 通知客户这是一个已知问题正在追踪中
- 从新报告中添加任何新信息到现有工单
- 如果新报告增加紧急性（更多客户受影响等），提升优先级
按类别的自动响应模板
Bug — 初始响应
感谢您报告此问题。我明白[具体影响]对您工作的干扰性。
我已将此记录为[优先级]问题，我们的团队正在调查。[如果有变通方案："与此同时，您可以[变通方案]。"]
我将在[SLA时间框架]内更新您我们发现的结果。
How-to — 初始响应
好问题！[直接回答或链接到文档]
[如果更复杂："让我带您走一遍步骤："]
[步骤或指导]
请让我知道这是否有帮助，或者您有任何后续问题。
Feature Request — 初始响应
感谢您的建议——我能理解[能力]对您工作流的价值。
我已记录此建议并与我们的产品团队分享。虽然我无法承诺具体时间表，但您的反馈直接影响我们的路线图优先级。
[如果有替代方案："与此同时，您可能会发现[替代方案]对实现类似效果有帮助。"]
Billing — 初始响应
我理解计费问题需要迅速关注。让我为您调查此事。
[如果直接：解决细节]
[如果复杂："我正在审查您的账户，将在[时间框架]内给您答案。"]
Security — 初始响应
感谢您标记此问题——我们认真对待安全顾虑并立即审查。
我已将此升级给我们的安全团队进行调查。我们将在[时间框架]内与您联系我们的发现。
[如果需要行动："与此同时，我们推荐[保护行动]。"]
使用此技能
在分诊工单时：
- 在分类前阅读完整工单——后来消息的上下文常改变评估
- 按根本原因分类，而不仅仅是描述的症状
- 当对优先级有疑问时，倾向于较高——降级比错过SLA后恢复更容易
- 在路由前总是检查重复和已知问题
- 写下帮助下一个人快速获取上下文的内部笔记
- 包括您已经检查或排除的内容，以避免重复调查
- 标记模式——如果您反复看到相同问题，即使单个工单优先级低，也要升级模式