工单优先级由影响范围、紧急程度和服务承诺共同决定，提交人职位高低或提交时间先后都不应成为定级依据。本文给出一套可直接落地的规则：先定义维度取值，再用矩阵映射出P1–P4等级，为每个等级绑定SLA响应与解决时限，最后明确谁有权定级、何时升级、如何重评，并附示例与上线检查清单。
要点总览（TL;DR）
- 优先级由影响范围、紧急程度和服务承诺三个输入共同决定，提交人职位和提交时间不参与定级。
- 用影响范围×紧急程度的二维矩阵映射P1–P4，每格给出唯一等级，边界情形单独约定并记录判定依据。
- 每个等级绑定响应时限与解决时限，写清起算点、工作时间或7×24口径、暂停条件，改级后按新等级核算。
- 定级权限按提交人、一线受理人、团队负责人、服务经理划分，升级与重评都要记录改级人、理由和时间。
- 上线后通过字段完整性、抽样一致性、时限达成率和升级率检验规则，并设定季度复审周期。
工单优先级由哪几个维度决定
优先级判定需要固定的输入，否则每张工单都会变成一次临时争论。建议采用两个主维度加一个约束维度：影响范围回答“谁受影响、影响多大”，紧急程度回答“业务还能不能运转”，服务承诺回答“这张工单背后有没有必须兑现的对外约定”。三个维度各自有明确取值和判定依据，定级人只需按表填写，不需要临场发挥。
影响范围按受影响对象划分，判定依据是“受影响方能否自行恢复业务”。个人指单个用户的部分工作受阻；团队指一个小组的共同流程中断；全组织指多个部门或核心业务系统受影响；外部客户指客户侧服务不可用或对外承诺受影响。判定时以实际受影响人数和业务链路为准，不按提交人所在部门推断。
紧急程度按业务状态划分，判定依据是“是否存在可用的替代路径”。业务中断指核心流程完全无法进行且无绕行方案；业务降级指流程可运行但效率或质量明显下降；可绕行指存在临时替代手段，业务可在约定时间内继续。紧急程度描述的是业务现状，与提交人的主观焦急程度分开记录。
服务承诺作为第三输入，包括SLA等级、合同约定和关键客户标识。同样的影响范围和紧急程度，如果涉及合同约定的关键客户或对外服务承诺，等级应上调。服务承诺由服务经理维护清单，一线受理人按清单核对，不自行解释合同条款。
有两类信息不进入优先级判定：缺陷严重程度属于缺陷分类与分级的管理范围，人员技能匹配属于派单与路由的考虑因素。把它们混入优先级，会让等级同时承载技术判断和资源调度，规则很快失去一致性。技术严重程度可以作为工单的独立字段记录，供后续缺陷管理使用。
| 维度 | 取值 | 判定依据 | 由谁判定 |
|---|---|---|---|
| 影响范围 | 个人 / 团队 / 全组织 / 外部客户 | 实际受影响人数与业务链路，受影响方能否自行恢复 | 一线受理人初判，团队负责人复核 |
| 紧急程度 | 业务中断 / 业务降级 / 可绕行 | 核心流程是否可运行，是否存在可用替代路径 | 一线受理人初判，必要时与提交人确认 |
| 服务承诺 | 标准 / 合同约定 / 关键客户 | SLA等级清单、合同条款、关键客户名录 | 服务经理维护清单，受理人核对 |
用二维矩阵把维度映射为P1–P4等级
维度定义完成后，需要一张矩阵把组合结果固定下来，让不同受理人对同一张工单得出相同等级。矩阵以影响范围为行、紧急程度为列，每格给出唯一等级；服务承诺作为调整项，在矩阵结果基础上按规则上调，并记录上调理由。
| 影响范围 \ 紧急程度 | 业务中断 | 业务降级 | 可绕行 |
|---|---|---|---|
| 外部客户 | P1 | P1 | P2 |
| 全组织 | P1 | P2 | P3 |
| 团队 | P2 | P3 | P4 |
| 个人 | P3 | P4 | P4 |
等级数量在3级与4级之间取舍。3级适合工单量较小、团队人数有限的场景，规则更易记忆；4级适合工单来源多、需要区分“紧急处理”和“正常排队”的场景，P4承担低影响、可绕行的常规请求。无论选几级，关键是每格有明确结论，不留下“视情况而定”的格子。
边界情形需要单独约定。影响大但可绕行，例如全组织受影响但已有临时方案，按矩阵落在P3，同时在工单中记录绕行方案和失效时间，绕行方案失效时触发重评。影响小但完全中断，例如单个用户的核心操作完全无法进行，按矩阵落在P3，若该用户承担对外交付节点，可由服务承诺维度上调至P2。边界判断的依据必须写进工单，不能只写结论。
定级结果写入工单的“优先级”字段，同时填写“影响范围”“紧急程度”“判定依据”三个字段。判定依据用一句话说明事实，例如“财务部5人无法提交报销，无替代流程”。字段必填是规则可执行的前提，缺少依据的工单在流转到处理环节前应退回补充。
为每个等级绑定SLA响应与解决时限
等级只有转化为时间承诺才具备约束力。响应时限指从工单进入受理队列到责任人首次有效回复的时间，解决时限指从同一时点起到工单关闭或恢复服务的时间。两者起算点应统一写清楚，常见做法是以工单提交时间或首次受理时间为起算点，选择其中一种并在所有等级中保持一致。
| 等级 | 响应时限 | 解决时限 | 计时口径 | 暂停条件 |
|---|---|---|---|---|
| P1 | 15分钟 | 4小时 | 7×24 | 仅限等待第三方厂商，需服务经理确认 |
| P2 | 30分钟 | 8工作小时 | 工作时间 | 等待用户回复、第三方依赖 |
| P3 | 2工作小时 | 3工作日 | 工作时间 | 等待用户回复、第三方依赖 |
| P4 | 1工作日 | 5工作日 | 工作时间 | 等待用户回复、排期确认 |
表中的数值是示例口径，实际取值应结合团队值班安排和服务能力确定。P1通常采用7×24计时，因为业务中断不分工作日；P2及以下采用工作时间计时，需要同时定义工作日历，包括上下班时间、午休和节假日。计时口径写不清，时限达成率就无法比较。
暂停计时需要约定条件与恢复规则。等待用户回复时暂停，用户回复后恢复；等待第三方依赖时暂停，需记录第三方名称和预计返回时间。暂停不能由处理人单方面决定，P1的暂停应经服务经理确认。每次暂停记录起止时间，作为时限核算的依据。
时限与优先级不一致时，处理顺序以优先级为主、时限为约束。若某张P2工单临近解决时限，应触发升级提醒，由团队负责人决定是否调配资源，不能通过临时改级来规避超时。反过来，若工单实际影响已超出原等级，应先重评等级，再按新等级时限核算，重评时间点之前的计时按原等级计算。
谁定级、谁升级：角色分工与重评机制
定级权限分散会导致同一类工单等级不一，权限过度集中又会让受理环节堵塞。建议按角色划分：提交人只负责如实描述影响和现象，不选择等级；一线受理人依据矩阵初判等级并填写判定依据；团队负责人复核P1、P2等级，并对边界情形做最终判断；服务经理维护服务承诺清单、审批P1暂停和跨团队升级。
| 角色 | 定级权限 | 升级权限 | 记录责任 |
|---|---|---|---|
| 提交人 | 无，仅描述影响与现象 | 可申请升级并说明理由 | 补充受影响范围和复现信息 |
| 一线受理人 | 按矩阵初判P1–P4 | 可发起升级申请 | 填写等级、判定依据、影响范围、紧急程度 |
| 团队负责人 | 复核P1、P2，裁定边界情形 | 批准团队内资源调配 | 记录复核结论 |
| 服务经理 | 审批服务承诺上调 | 批准跨团队升级与P1暂停 | 维护承诺清单，审核重评记录 |
升级触发条件应写成可观察的信号：工单剩余时间低于解决时限的25%、影响范围从团队扩大到全组织、外部客户投诉或合同约定节点临近。触发后由受理人发起升级申请，团队负责人在约定时间内审批，审批结果和资源安排写入工单。升级不等于改级，资源调配可以在等级不变的情况下进行。
重评是等级变更的正式动作，必须记录改级人、改级理由和改级时间。理由要指向维度取值的变化，例如“影响范围由团队扩大为全组织”，而不是“客户催得急”。重评记录保留在工单历史中，供后续一致性抽查使用。
“优先级只升不降”适合对外承诺严格、客户可见等级的场景，可以避免处理人为缩短计时而临时降级。例外情形包括：初判时信息不全导致定级偏高，经核实后由团队负责人批准降级；重复工单合并到主工单，被合并工单关闭并注明合并关系。例外同样需要记录理由和审批人。
这些字段和流转需要在工单系统中承载。ONES Desk 支持评估和定义工单优先级，优先解决紧急事件，并支持自定义工单属性以满足不同角色的收集需求，可将影响范围、紧急程度、判定依据设为必填字段；其工作流可灵活调整，用于配置复核、升级与重评的流转节点。等级变更和暂停记录能否按上述口径自动核算时限，需结合实际版本配置确认。
一个完整示例：从提单到定级再到SLA计时
以下为演示情景，用于说明规则如何串联，数值沿用上文的示例口径。
周一10:00，财务部一名员工提交工单：“报销系统提交页面一直转圈，无法提交单据。”受理人联系提交人确认：同部门5人均无法提交，月末结账节点临近，暂无替代流程。判定影响范围为“团队”，紧急程度为“业务中断”，服务承诺为“标准”，矩阵映射结果为P2，判定依据填写“财务部5人无法提交报销，无替代流程”。按P2绑定响应时限30分钟、解决时限8工作小时，工作时间计时。
10:20，受理人首次回复并告知处理进展，响应时限达成。11:30排查发现为接口超时，需要外部厂商配合，受理人发起暂停并记录第三方名称和预计返回时间，服务经理确认暂停。14:00厂商恢复接口，计时恢复。
14:30，提交人反馈销售部门也无法提交，影响范围扩大为“全组织”。受理人发起重评，改级为P1，理由为“影响范围由团队扩大为全组织”，团队负责人复核通过，服务经理批准跨团队升级。重评时间点之前的计时按P2核算，之后按P1的7×24口径核算。
16:10工单关闭，服务恢复。按P1口径，从14:30起算的解决时限为4小时，实际用时1小时40分钟，时限达成；P2阶段累计计时未超出8工作小时。工单记录中包含两次等级、判定依据、暂停起止时间和重评审批人，可直接用于后续抽查。
规则上线后的完成检查
规则写完不等于机制运行。上线后需要按以下清单逐项核对，确认字段、判定和统计都能支撑管理动作。
- 字段完整性：优先级、影响范围、紧急程度、判定依据为必填；SLA响应时限与解决时限随等级自动带出；暂停和重评有独立记录字段。
- 一致性抽查：每周抽取一定数量的已关闭工单，核对等级是否符合矩阵，判定依据是否指向事实；偏差率持续偏高时，回到维度定义检查取值是否清晰。
- 时限达成率：按等级分别统计响应达成率和解决达成率，区分工作时间与7×24口径，避免混合计算。
- 升级率与重评率：观察各等级的升级次数和重评次数，重评集中在某一格说明矩阵该区域定义模糊，升级集中在某一等级说明资源或时限设置不合理。
- 暂停使用情况：统计暂停次数和暂停时长占比，暂停过多可能意味着依赖管理或信息收集环节存在问题。
- 复审周期：建议每季度复审一次矩阵和时限，触发调整的条件包括业务量明显变化、组织调整、合同承诺变更，以及连续两个周期某等级时限达成率明显偏离。
检查结果应形成简短记录，列出偏差项、原因和调整动作。规则的价值在于让定级可解释、时限可核算、变更可追溯，做到这三点，优先级机制才算真正上线。
常见问题
工单量不大、团队人数有限时，用3级还是4级优先级更合适？
3级适合工单来源单一、受理人少、等级容易记忆的场景；4级适合工单来源多、需要把“紧急处理”和“正常排队”分开的场景，P4承担低影响、可绕行的常规请求。等级数量本身不决定规则好坏，关键是矩阵每一格都有明确结论，不留下“视情况而定”的格子。若选3级，可把原P3与P4合并，但要在判定依据中写清合并后的处理顺序。
工单处理到一半，影响范围扩大了，SLA时限怎么算？
先做重评，再按新等级核算。重评时间点之前的计时按原等级口径计算，之后按新等级口径计算，两段分别记录。重评理由要指向维度取值的变化，例如“影响范围由团队扩大为全组织”，并记录改级人、改级时间和审批人。若新等级采用不同的计时口径（如从工作时间改为7×24），起算点从重评时间点开始，不追溯调整已发生的计时。
等待用户回复或第三方厂商时暂停计时，需要注意什么？
暂停要有明确条件和恢复规则：等待用户回复时暂停，用户回复后恢复；等待第三方依赖时暂停，需记录第三方名称和预计返回时间。暂停不能由处理人单方面决定，P1的暂停应经服务经理确认。每次暂停记录起止时间，作为时限核算依据。暂停次数和暂停时长占比过高，通常说明依赖管理或信息收集环节存在问题，应在复审时检查。
优先级只升不降的规则，什么情况下可以例外降级？
“只升不降”适合对外承诺严格、客户可见等级的场景，可以避免处理人为缩短计时而临时降级。例外情形主要有两类：初判时信息不全导致定级偏高，经核实后由团队负责人批准降级；重复工单合并到主工单，被合并工单关闭并注明合并关系。例外同样需要记录理由和审批人，并在一致性抽查中单独观察，避免例外变成常规操作。
在工单系统里落地这套规则，需要配置哪些字段和流转？
至少需要把优先级、影响范围、紧急程度、判定依据设为必填字段，SLA响应时限与解决时限随等级带出，暂停和重评各自有独立记录字段。流转上要配置P1、P2的复核节点、升级审批节点和重评记录节点。ONES Desk 支持评估和定义工单优先级，支持自定义工单属性以满足不同角色的收集需求，工作流可灵活调整，可用于配置复核、升级与重评的流转节点；等级变更和暂停记录能否按上述口径自动核算时限，需结合实际版本配置确认。
