工单优先级是根据"影响范围"和"紧急程度"两个维度综合计算出的处理顺序，用来回答"这么多工单，先处理哪一张"。 在 ITIL流程 中，最常用的做法是"影响×紧急度"优先级矩阵：影响衡量问题波及多少人、多少业务，紧急度衡量问题需要多快解决。优先级不由提交人的语气决定，也不由工程师的直觉决定，而是由一套统一、可解释的规则决定。
很多 IT服务台 的优先级形同虚设：员工一律选"紧急"，工程师按先来后到处理，真正影响全公司的故障反而被埋在队列里。本文梳理矩阵的设计方法、常见问题和在 工单系统 中的落地做法。
一、优先级的三个基本概念
1. 影响（Impact）
影响描述的是问题造成的业务后果范围，通常按波及对象分级：
- 高：影响整个公司、某个关键业务系统或大量用户
- 中：影响一个部门或一组用户
- 低：只影响单个用户，且有替代方式
2. 紧急度（Urgency）
紧急度描述的是业务对解决速度的容忍程度，比如问题是否正在阻断关键工作、是否临近重要节点（月末结账、发布窗口）。同样是影响一个人，财务人员在结账日无法登录系统，紧急度就远高于平时。
3. 优先级（Priority）
优先级由影响与紧急度交叉得出，决定响应与处理的先后顺序，并对应不同的SLA目标。
| 影响＼紧急度 | 高 | 中 | 低 |
|---|---|---|---|
| 高 | P1 紧急 | P2 高 | P3 中 |
| 中 | P2 高 | P3 中 | P4 低 |
| 低 | P3 中 | P4 低 | P4 低 |
这只是一个常见示例，企业应根据自身业务调整层级和命名。
二、设计矩阵时的关键原则
1. 分级定义要具体，避免主观判断
"影响大"和"影响小"如果没有清晰定义，每个人理解都不同。建议用可核对的标准描述，比如"影响超过多少用户""涉及哪类核心系统""是否直接造成营收损失"，让不同工程师得出一致的结果。
2. 级别不宜过多
三到四个级别通常足够。级别太多，工程师分不清P3和P4的区别；级别太少，又无法区分处理节奏。关键是每个级别对应的响应动作和SLA要有明显差异。
3. 让员工提供事实，由系统计算优先级
员工往往倾向于把自己的问题标为紧急。更稳妥的做法是：员工只回答几个事实性问题，如"影响几个人""是否无法继续工作"，由系统根据规则自动计算优先级，而不是让员工直接选择P1。
4. 为VIP和关键业务设置调整规则
某些用户（如高管）或关键业务（如收银、生产线）可以设置优先级加成，但必须有明确的规则和审批，否则"特殊照顾"会不断扩大，最终让矩阵失去意义。
5. 优先级与SLA挂钩
每个优先级对应不同的响应时间和解决时间，比如P1要求几分钟内响应并持续跟进，P4可以在若干个工作日内处理。没有SLA支撑的优先级只是一个标签。
6. 允许有依据地调整
工单处理过程中情况会变化：影响扩大了，或者临时找到了替代方案。系统应允许工程师调整优先级，但要求填写原因并留痕，方便后续复盘。
三、在工单系统中落地的做法
1. 表单里只问事实
在服务台入口设置简短的问题，例如受影响人数、是否阻断工作、是否涉及关键系统，答案用于自动计算优先级，减少员工选择的随意性。
2. 用自动化规则计算与提醒
在 工单系统 中配置规则：根据影响和紧急度自动生成优先级，并对高优先级工单触发即时通知、自动升级和更严格的SLA计时。工程师打开队列时，看到的就是已排好序的工单。
3. 与重大事件流程衔接
当P1级别的工单影响范围很大时，应能一键升级为重大事件，启动专门的响应小组和沟通机制，而不是仍按普通工单处理。
4. 区分事件与服务请求
事件的优先级依据影响和紧急度；服务请求更多依据业务所需日期。两类请求最好使用各自的优先级逻辑，避免把"申请一个新鼠标"和"系统宕机"放在同一套规则下比较。
5. 用数据回头校准
定期统计各级别工单的数量、平均解决时长和优先级被手动调整的比例。如果P1占比过高，说明定义过松；如果大量工单被人工上调，说明矩阵没有反映真实业务重要性，需要重新校准。
6. 一个简单的例子
同一天里有三张工单：一位员工的鼠标坏了（影响低、紧急度低）；销售部门十几个人无法访问客户系统（影响中、紧急度高）；电商支付接口全面异常（影响高、紧急度高）。矩阵会自动给出P4、P2和P1，工程师无需争论，就知道先处理支付接口，再处理销售系统，最后才是鼠标。
四、常见问题解答（FAQ）
Q1：优先级和严重程度（Severity）是一回事吗？ 不完全是。严重程度通常描述问题本身的技术严重性，优先级则综合业务影响和时间要求决定处理顺序。有些企业把两者合并使用，关键是内部定义一致。
Q2：员工总是选紧急，怎么办？ 不要让员工直接选优先级，而是通过事实性问题由系统计算，同时在工单中公示各级别含义，减少随意性。
Q3：小团队有必要用矩阵吗？ 有必要，哪怕只分高、中、低三级。成本很低，却能避免最常见的"谁喊得响谁先处理"。
Q4：优先级可以随时间自动变化吗？ 可以。例如工单接近SLA上限时自动提示或升级，让即将超时的工单更显眼。
Q5：矩阵多久调整一次？ 建议每半年或每年回顾一次，结合业务变化与数据分布，必要时调整定义。
Q6：VIP用户的工单一定要提高优先级吗？ 不必一概而论。可以按业务影响判断，同时在流程中给VIP提供更主动的沟通和更清晰的进度通知，既照顾体验，又不扭曲整体排序。
Q7：服务请求也要用同一个矩阵吗？ 建议分开。服务请求的优先级更多来自业务需要的交付日期，可单独设计规则，避免与故障类工单互相干扰。
五、结语：让"先做什么"成为一件有依据的事
优先级矩阵 的价值，在于把"先处理哪张工单"从个人判断变成团队共识。它让 IT服务台 在高峰期也能保持秩序，让重要的问题得到应有的速度，也让SLA和报表有了可靠的口径。
如果你正在为工单优先级混乱而烦恼，可以了解一下 ManageEngine ServiceDesk Plus。它支持基于影响与紧急度的优先级矩阵、按优先级触发的SLA与升级规则，适合作为搭建规范化工单优先级机制时的参考选项之一。