工单优先级与 SLA 管理要分开处理两件事：优先级决定先做哪张单，依据影响范围、紧急程度和业务重要性判定；SLA 决定承诺多久响应、多久解决，按服务等级设定可计时的目标。本文给出优先级判定字段表、SLA 目标对照表、端到端流程步骤与上线检查清单，帮助服务台把分级规则落到可执行、可核验的日常动作中。
要点总览（TL;DR）
- 优先级决定处理顺序，由影响范围、紧急程度、业务重要性三类字段组合判定；SLA 决定承诺时限，按服务等级设定响应与解决目标，两者绑定但不等同。
- 优先级档位建议控制在三到四档，映射规则二选一写进规则文档；优先级调整需授权并记录调整人、时间、前后档位与理由。
- SLA 目标要同时确定目标类型、目标值与计时口径，工作时间与自然时间不能在同一优先级上混用，暂停计时须记录原因与恢复时间。
- 流程按受理、分级、派单、升级、关闭五环节定义输入、动作、输出与完成标志，升级触发条件写成可判断的硬规则。
- 上线前检查字段覆盖与暂停漏洞，运行后按月看超时率、按时完成率、暂停时长占比与优先级调整频次，每季度复审规则。
先分清优先级与 SLA：各自回答什么问题
优先级和 SLA 经常被混在同一个字段里，结果是既说不清处理顺序，也算不出是否守约。把两者拆开，各自回答一个明确问题，后续的字段设计和流程设计才有稳定基础。
优先级回答“先做哪张单”。它是一张工单在待处理队列中的相对位置，由影响范围、紧急程度、业务重要性三类信息共同判定。影响范围看受影响的人数、系统或业务线数量；紧急程度看问题是否正在扩大、是否存在可接受的临时绕行方案；业务重要性看该业务在当期的重要程度，例如是否涉及结算、对外服务或关键节点。三个维度组合后映射到有限档位，避免单看“用户说很急”就给出最高级。
SLA 回答“承诺多久响应、多久解决”。它是服务方对服务对象作出的时限承诺，按服务等级设定目标值，再与优先级绑定：高优先级对应更短的响应与解决时限，低优先级允许更长时限。绑定关系意味着优先级变化会带动 SLA 目标变化，但两者并不等同——优先级是内部排序依据，SLA 是对外或跨团队的服务约定，一个工单可以优先级不高却因服务等级较高而适用较严的时限。
需要说明边界：软件缺陷的严重程度分级属于缺陷分类与分级范畴，人员派单与路由策略属于工单分派与路由范畴，本文聚焦服务承诺与紧急性判定，不展开这两部分。下面的内容按“定义字段—设定时限—串起流程—明确角色—示例验证—上线检查”的顺序展开。
第一步：定义优先级判定字段与取值
分级要可执行，前提是判定依据能落到具体字段和取值上，让不同受理人对同一张工单能得出接近的结论。建议设置三类判定字段，每类给出有限取值，再通过映射规则得出优先级档位。
| 判定字段 | 取值示例 | 分值或档位 | 判定说明 |
|---|---|---|---|
| 影响范围 | 单人 / 单团队 / 多团队 / 全公司或对外服务 | 1 / 2 / 3 / 4 | 按受影响对象数量与是否波及外部用户判定 |
| 紧急程度 | 可等待 / 有临时绕行 / 业务受阻 / 业务中断且在扩大 | 1 / 2 / 3 / 4 | 看是否存在可用替代方案、问题是否持续扩大 |
| 业务重要性 | 一般 / 重要 / 关键 | 1 / 2 / 3 | 按业务线在当期的重要程度，由服务负责人维护清单 |
档位数量建议控制在三到四档，例如 P1 紧急、P2 高、P3 中、P4 低。档位过多会导致边界模糊、判定成本上升；档位过少则无法区分处理顺序。映射规则可采用“取最高维度档位”或“分值加总后落区间”两种方式，前者简单、后者更细，团队按工单量选择一种并写进规则文档。
优先级调整需要授权与留痕。建议明确：受理人可做初判，分级复核人可上调或下调一档，跨档调整需服务负责人确认；每次调整记录调整人、调整时间、调整前后档位与理由。留痕既用于事后复盘，也用于发现判定字段是否被频繁误用。
第二步：为每个优先级设定 SLA 目标与计时口径
SLA 目标要可计时、可核验，需要同时确定三件事：目标类型、目标值、计时规则。目标类型通常分响应时限与解决时限两类。响应时限从工单受理时刻起算，到首次有效回复为止；解决时限从受理时刻起算，到工单达到关闭条件为止。两类目标分别考核，避免“回复很快但一直没解决”被算作达标。
计时口径要在规则中写死。工作时间口径只累计服务台排班时段，适合以人工处理为主、非工作时段不承诺响应的服务；自然时间口径按 7×24 小时连续累计，适合对外服务或系统类工单。两种口径不能在同一优先级上混用，否则统计结果无法比较。
暂停计时条件同样需要明确列举，常见的有等待客户补充信息、等待第三方厂商处理、等待变更窗口。暂停需由处理人发起并记录暂停原因与恢复时间，暂停时长从计时中扣除；未记录原因的暂停不计入扣除，防止用暂停规避超时。
| 优先级 | 响应时限 | 解决时限 | 计时口径 | 可暂停条件 |
|---|---|---|---|---|
| P1 紧急 | 15 分钟 | 4 小时 | 自然时间 | 仅等待第三方，需服务负责人确认 |
| P2 高 | 30 分钟 | 8 工作小时 | 工作时间 | 等待客户、等待第三方 |
| P3 中 | 2 工作小时 | 3 工作日 | 工作时间 | 等待客户、等待第三方、等待变更窗口 |
| P4 低 | 1 工作日 | 5 工作日 | 工作时间 | 等待客户、等待第三方、等待变更窗口 |
表中数值为示例，团队应结合自身排班、人员规模和历史处理时长确定目标值。设定时参考近三个月同类工单的实际处理分布，把目标定在多数工单可达成、少数需要改进的位置，目标过严会催生虚假关闭，过松则失去约束意义。
第三步：串起受理、分级、派单、升级与关闭流程
规则只有嵌入流程才会被执行。下表按环节列出输入、动作、输出与完成标志，团队可据此配置工单状态与流转条件。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 受理 | 用户提交的工单内容、联系方式、受影响对象 | 核对必填信息，补齐影响范围与业务线，做初步分级 | 信息完整的工单与初判优先级 | 必填字段齐全，工单进入待分级状态 |
| 分级 | 初判优先级与判定字段 | 复核三类字段取值，确认或调整档位，记录调整理由 | 确认后的优先级与 SLA 目标 | 优先级字段锁定，SLA 计时启动 |
| 派单 | 确认后的工单与处理团队 | 按业务线或系统归属指派处理人，注明期望完成时间 | 已指派工单 | 处理人接单，状态变为处理中 |
| 升级 | 计时进度与处理状态 | 临近时限时提醒处理人；跨团队或超出处理人权限时上报服务负责人 | 升级记录与新的处理安排 | 升级动作被记录，责任人或资源已调整 |
| 关闭 | 处理结果与验证信息 | 确认问题解决或给出可接受的替代方案，请客户确认 | 关闭记录与处理小结 | 客户确认或约定确认期届满，工单关闭 |
升级触发条件建议写两条硬规则：剩余时限低于目标时长的四分之一时自动提醒处理人与直属负责人；工单需要跨两个以上团队协作时，由服务负责人协调并更新预计完成时间。关闭条件要区分“已解决”和“已答复”，前者需客户确认，后者适用于咨询类工单，两类关闭方式在统计时分开计数。
在工具承载上，ONES Desk 支持自定义工单属性与灵活调整工作流，可以把上述判定字段、状态和流转条件配置到工单中；工单还可一键关联到 ONES Project 的需求或缺陷工作项，便于跨团队处理时持续跟踪。SLA 计时与超时提醒的具体配置方式，建议在实施阶段结合所用版本核验。
角色与交付物分工
流程能否稳定运行，取决于每个角色是否清楚自己产出什么。下表列出四类核心角色及其交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 服务台受理人 | 接收工单、补齐必填信息、做初步分级 | 信息完整的工单、初判优先级 |
| 分级复核人 | 复核判定字段与档位，处理优先级调整申请 | 确认后的优先级、调整记录 |
| 处理人 | 按 SLA 目标处理工单，发起暂停与升级 | 处理记录、暂停原因说明、解决说明 |
| 服务负责人 | 维护 SLA 规则与业务重要性清单，协调跨团队升级 | SLA 规则文档、升级协调记录、周期复盘报告 |
SLA 规则的维护责任归服务负责人，修订需经过一次规则评审并留存版本记录。分级复核人通常由服务台资深成员兼任，负责在日常工单中校准判定尺度；处理人对时限负责，但没有调整优先级的权限，需要调整时提交给复核人。各角色的交付物应能在工单记录中直接找到，避免依赖个人记忆或线下沟通。
示例：一张高优先级工单的完整流转
以下为演示情景，用于说明字段填写、SLA 计时与升级动作如何衔接。
周一 9:10，某业务团队提交工单：报销系统无法提交单据，影响该团队全体成员，且临近月度结算。受理人核对信息后填写判定字段：影响范围为“单团队”（2 分），紧急程度为“业务受阻且有结算时限”（3 分），业务重要性为“关键”（3 分），按取最高档规则初判为 P2 高。
9:20 分级复核人复核，确认影响范围实际波及两个关联团队，将影响范围调整为“多团队”（3 分），优先级维持 P2，并记录调整理由。工单绑定 P2 的 SLA 目标：30 分钟响应、8 工作小时解决，计时口径为工作时间，计时起点为 9:10 受理时刻。
9:25 工单派给应用支持组处理人。9:40 处理人首次回复并说明排查方向，响应时限达成。排查中发现需数据库团队配合，处理人于 10:30 发起跨团队升级，服务负责人协调数据库团队加入，工单记录升级动作与新的预计完成时间。11:50 问题定位为配置项错误并修复，处理人提交解决说明，请提交人验证。13:30 提交人确认恢复，工单关闭，解决时限在 8 工作小时内达成。全过程记录保留在工单中，包括字段取值、优先级调整、升级动作与关闭确认。
完成检查：规则是否可执行、可核验
上线前先做一轮静态检查，确认规则本身没有缺口；运行后按月检查指标，判断机制是否真正运转。
上线前检查清单：
- 判定字段与档位是否覆盖近三个月出现过的常见工单类型，是否存在无法归类的工单；
- 每个优先级是否都有明确的响应时限、解决时限、计时口径与暂停条件；
- 暂停条件是否要求记录原因与恢复时间，是否存在未记录即可暂停的漏洞；
- 升级触发条件是否写成可判断的规则，而不是“视情况而定”；
- 关闭条件是否区分已解决与已答复，客户确认方式是否明确；
- 各角色是否知道自己的交付物以及在工单中的记录位置。
运行期观察指标包括：超时率（按优先级分别统计响应超时与解决超时）、按时完成率、暂停时长占比、优先级调整频次与调整方向、升级次数与升级后达成率。指标按月汇总，连续两个月某优先级超时率明显偏高时，先检查目标值是否合理，再检查人员与流程瓶颈。
规则复审建议每季度一次，出现以下情况时提前修订：业务重要性清单发生较大变化、新增服务类型导致现有档位无法覆盖、暂停被频繁用于规避超时、优先级调整集中在某一判定字段。修订后更新规则版本并通知相关角色，保持字段、目标与流程三者一致。
常见问题
优先级档位设三档还是四档，工单量大的团队怎么选？
档位数量取决于工单类型的分化程度和受理人的判定成本。类型集中、处理路径接近的团队，三档（高、中、低）通常够用，边界清晰、判定快；工单来源多、涉及对外服务与内部支持的团队，四档能把“紧急”和“高”区分开，避免所有急事挤在同一档。
工单量大的团队还要考虑映射规则的成本：取最高维度档位判定快，适合受理环节人手有限的情况；分值加总后落区间更细，但要求受理人逐项打分。无论选哪种，档位与映射规则写进同一份规则文档，并在一段时间内保持稳定，频繁改档位会让历史统计失去可比性。
SLA 计时用工作时间还是自然时间，同一套规则里能混用吗？
可以按优先级分别设定，但同一优先级上不能混用。工作时间口径只累计排班时段，适合非工作时段不承诺响应的人工服务；自然时间口径按 7×24 小时连续累计，适合对外服务或系统类工单。
实际操作中常见做法是：最高优先级用自然时间，保证夜间和周末也有人响应；其余优先级用工作时间，与排班匹配。混用的前提是每个优先级的计时口径在规则中写死，并在工单上可见，否则统计超时率时无法横向比较。切换口径属于规则修订，需要留存版本记录并通知处理人。
暂停计时经常被用来规避超时，怎么约束？
约束的关键是让暂停有成本、可追溯。规则上要求暂停必须由处理人发起并记录暂停原因与恢复时间，未记录原因的暂停不计入扣除；暂停类型限定为等待客户、等待第三方、等待变更窗口等列举情形，超出列举范围需服务负责人确认。
运行期把暂停时长占比纳入月度指标，按优先级和暂停类型分别统计。某一优先级或某一处理人的暂停占比持续偏高时，先核查暂停记录是否完整，再判断是外部依赖确实多，还是目标值定得过严导致处理人倾向暂停。后一种情况应调整目标值，而不是继续收紧暂停审批。
升级触发条件写成“视情况而定”会有什么问题，应该怎么改？
“视情况而定”意味着升级依赖个人判断，不同处理人对同一进度会做出不同选择，结果是有的工单临近超时无人介入，有的工单过早升级占用负责人精力。改法是把触发条件写成可判断的规则，例如剩余时限低于目标时长的四分之一时自动提醒处理人与直属负责人，工单需要跨两个以上团队协作时由服务负责人协调并更新预计完成时间。
规则写完后还要确认升级动作被记录：谁发起、何时发起、升级后责任人或资源如何调整。升级记录同时是复盘材料，用于判断目标值是否合理、跨团队协作是否存在固定瓶颈。
规则上线后多久复审一次，什么情况下要提前修订？
常规节奏建议每季度复审一次，检查判定字段是否仍覆盖常见工单类型、SLA 目标值与实际处理分布是否匹配、暂停与升级规则是否被频繁触发。复审输出规则版本记录，并通知相关角色。
出现以下情况时提前修订：业务重要性清单发生较大变化、新增服务类型导致现有档位无法覆盖、暂停被频繁用于规避超时、优先级调整集中在某一判定字段。修订时同步更新字段、目标与流程三处，保持三者一致，避免只改时限不改判定依据造成统计口径断裂。
