工单优先级要按“影响范围×紧急程度×服务承诺”三项判断：先定义级别和判定字段，再把每级映射到响应与解决时限，最后用角色分工、升级规则和复盘机制保证执行。本文按分级判定、SLA 对应、落地配置、角色分工、示例和完成检查的顺序展开，并在配置环节说明 ONES 可承载的优先级字段与工单流转。
要点总览（TL;DR）
- 工单优先级按影响范围、紧急程度、服务承诺三项判断，三项落到可填写字段，由一线受理人定级并记录依据。
- 优先级与严重程度分开维护：严重程度归缺陷分级，优先级看业务影响与时限承诺，避免两套口径混用。
- 每级优先级对应首次响应时限、解决时限和更新频率，并写明计时口径、暂停条件与超时预警点。
- 落地按四步推进：梳理服务目录与影响范围口径、设置必填字段与判定提示、配置时限与升级规则、小范围试运行校准分级分布。
- 用分级分布、判定字段填写完整率、SLA 达成率与超时归因、升级处置记录按月检查，形成检查—归因—修订—再检查的循环。
工单优先级按什么标准分级
优先级回答的是“这张工单应当多快被处理”，判断依据是业务影响和时限承诺，而非提交人的主观感受。为了让不同受理人得出接近的结论，需要把判断拆成三个可填写的维度：影响范围、紧急程度、服务承诺。三项分别打分或分档，再按统一规则合成级别。
三项判定依据
影响范围看受影响的用户、业务线、系统数量以及是否存在替代方案。紧急程度看问题是否随时间恶化、是否卡住关键业务节点、是否有明确的外部截止时间。服务承诺看该服务对象或服务目录中约定的响应时限，例如核心业务系统与内部工具的服务承诺本身不同，同样的技术问题在两类服务上可能对应不同优先级。
三项依据需要落到具体字段上，例如“影响用户数”“受影响业务”“是否存在替代方案”“承诺响应时限”。字段值由报单人和受理人共同确认，受理人对最终级别负责。
P1–P4 级别定义与典型场景
下表给出四级划分的参考模板，组织可按服务规模合并为三级，但级别定义、判定条件和判定人三项应保持完整。
| 级别 | 判定条件 | 典型场景 | 判定人 |
|---|---|---|---|
| P1 紧急 | 核心业务整体不可用，或影响大量外部用户，且无替代方案；承诺时限最短 | 核心交易系统无法登录、对外服务大面积中断 | 一线受理人初判，服务负责人确认 |
| P2 高 | 核心业务部分功能受阻，或重要部门多人受影响，存在临时绕行方案 | 某业务模块报错但主流程可用、关键岗位批量无法导出数据 | 一线受理人 |
| P3 中 | 单个用户或小范围受影响，业务可正常推进 | 个别账号权限异常、单台设备软件故障 | 一线受理人 |
| P4 低 | 咨询、建议、体验优化类请求，无业务中断 | 功能使用咨询、界面文案建议 | 一线受理人或按服务目录默认 |
优先级与严重程度的区分
严重程度描述问题本身的技术破坏力，归入缺陷分级；优先级描述业务影响与处理时限，归入工单管理。一个技术上的严重缺陷，如果发生在备用系统且当前无人使用，工单优先级可以较低；一个技术上的小问题，如果卡住了对外交付节点，优先级就应当提高。两套口径分开维护，可以避免开发团队按缺陷等级排期、服务团队按业务影响承诺，双方各说各话。
判定冲突时的取舍顺序
当三项依据指向不同级别时，按以下顺序取舍：先看是否存在业务中断或外部承诺违约风险，满足则取较高级别；其次看影响范围是否覆盖核心业务或大量用户；最后参考报单人的紧急描述。报单人的主观紧急程度作为参考信息记录，不单独决定级别。争议由服务负责人裁定，裁定结果和理由写入工单，作为后续规则修订的输入。
从分级到 SLA：时限如何对应
优先级只有落到具体时限才有约束力。每一级优先级需要对应三项指标：首次响应时限、解决时限、处理期间的更新频率。时限取值来自服务目录中的承诺，而非临时拍定。下表为对应关系模板，具体数值需按组织服务能力确定。
| 优先级 | 首次响应时限 | 解决时限 | 更新频率 | 超时预警点 |
|---|---|---|---|---|
| P1 | 15 分钟内 | 4 小时内 | 每 30 分钟同步进展 | 响应时限过半、解决时限剩余 25% |
| P2 | 1 小时内 | 1 个工作日内 | 每 2 小时同步进展 | 解决时限剩余 25% |
| P3 | 4 小时内 | 3 个工作日内 | 每日同步一次 | 解决时限剩余 20% |
| P4 | 1 个工作日内 | 按排期处理 | 状态变化时同步 | 不设强制预警 |
SLA 计时口径
计时口径必须在规则中写明，否则同一张工单会被算出不同剩余时间。需要明确四点：一是按自然时间还是工作时段计时，P1 通常按自然时间，其余级别按工作时段；二是暂停条件，等待报单人补充信息、等待第三方厂商处理等状态是否暂停计时，暂停需有状态记录和恢复时间；三是跨时区与节假日处理，多地服务团队需约定以哪个时区的工作日历为准；四是计时起点，从工单提交时间还是受理确认时间开始计算，两者对响应指标影响明显，需在服务目录中统一。
超时预警与升级触发
预警点设在时限消耗的关键比例上，触发后通知当前处理人和服务负责人。升级触发条件通常包括：响应时限超时、解决时限超时、工单在某一状态停留超过约定时长、报单人对处理进展提出异议。升级动作要具体，例如提升一级优先级、更换处理人、拉入服务负责人协调资源，并记录升级原因与处置结果。
SLA 目标与分级规则不一致时的调整
运行一段时间后，如果某级工单持续大面积超时，先判断是规则问题还是执行问题。规则问题的信号是：该级工单的实际处理时长中位数明显超过承诺时限，且超时原因集中在资源不足或流程等待；此时应调整该级的时限目标或收窄该级的判定条件。执行问题的信号是：超时集中在少数处理人或少数环节，此时应改进入口校验和交接动作，而非放宽承诺。调整需保留历史版本，便于对比调整前后的达成情况。
落地步骤：字段、入口与流程配置
建立这套机制可以按四步推进，每步都有明确的输入、动作、输出和完成标志，避免一次性铺开导致规则悬空。
步骤一：梳理服务目录与影响范围口径
输入是现有服务清单、历史工单记录和各部门的服务期望。动作是列出服务项，为每项标注服务对象、业务重要度和承诺时限，并统一“影响范围”的填写口径，例如按受影响用户数分档、按业务系统分档。输出是一份服务目录和影响范围分档说明。完成标志是每个服务项都能对应到至少一个优先级判定条件，且受理人对分档口径理解一致。
步骤二：设置优先级必填字段、下拉选项与判定提示
输入是步骤一的服务目录和分级判定表。动作是在工单表单中设置优先级字段，采用固定下拉选项，并把影响范围、紧急程度、服务承诺作为必填判定字段；在字段旁给出判定提示，例如“核心业务整体不可用且无替代方案时选 P1”。输出是可提交的工单表单和字段说明。完成标志是提交一张测试工单时，未填写判定字段无法提交，且受理人能依据提示独立完成定级。ONES Desk 支持自定义工单属性并评估、定义工单优先级，可作为承载这些字段的工具方向；字段的具体选项与校验方式需在配置时按实际版本确认。
步骤三：配置 SLA 计时、预警与升级规则
输入是优先级—SLA 对应表和计时口径说明。动作是把每级优先级的响应、解决时限写入规则，设置预警触发点和升级路径，明确暂停计时的状态。输出是可在工单流转中执行的时限规则和升级规则清单。完成标志是用测试工单验证：达到预警点时通知到人，超时后按预设路径升级，暂停与恢复后剩余时间计算正确。ONES Desk 支持灵活调整工作流，可用于承载工单状态流转；SLA 计时与自动升级的具体配置方式需结合所选版本向厂商确认。
步骤四：小范围试运行并校准分级分布
输入是已配置好的表单、规则和一支试点团队。动作是选择一个服务项或一个部门试运行两到四周，统计各级工单占比、判定依据填写率、SLA 达成率和超时原因。输出是试运行报告和规则修订清单。完成标志是分级分布不出现单一级别占比过高，判定字段填写完整率达到约定水平，且超时原因可以归类。校准完成后再向其他服务项推广。
角色分工与各自交付物
规则能否执行，取决于每个环节是否有人对具体产物负责。下表按角色列出职责、交付物和交接时点。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 报单人 | 提供影响范围、受影响业务、是否存在替代方案和业务截止时间 | 信息完整的工单描述与判定字段 | 提交工单时 |
| 一线受理人 | 初判优先级，记录判定依据，确认或退回信息不全的工单 | 优先级结论与判定依据记录 | 首次响应时 |
| 服务负责人 | 维护分级标准、服务目录与 SLA 目标，裁定优先级争议 | 分级规则版本、SLA 目标表、争议裁定记录 | 规则修订时、争议发生时 |
| 处理人 | 按优先级时限处理，按更新频率同步进展 | 处理记录、状态更新、解决说明 | 每次状态变化时 |
| 升级责任人 | 超时或争议时协调资源、调整优先级或更换处理人 | 升级记录与处置结果 | 预警触发或超时后 |
交接时点需要与工单状态对应：报单人提交后进入待受理，受理人定级后进入处理中，处理人每次更新状态时同步进展，升级责任人介入时记录升级原因。服务负责人定期汇总争议裁定和超时归因，作为规则修订依据。ONES Desk 可将工单关联到 ONES Project 的需求或缺陷工作项持续跟踪，适合需要把服务工单与研发处理打通的场景。
示例：一张高优先级工单的完整流转
以下为演示情景，用于说明判定与升级的连续过程，不代表真实客户案例。
周一 9:00，某业务部门报单人提交工单：对外订单查询页面无法打开，影响全部外部客户，当前无替代入口，当天 14:00 有促销活动。报单人填写影响范围为“全部外部用户”，紧急程度为“业务中断且有明确截止时间”，服务承诺为“核心业务系统”。
9:05，一线受理人核对字段，依据判定表得出 P1：核心业务整体不可用、影响大量外部用户、无替代方案，三项均指向最高级。受理人在工单中记录判定依据，工单进入处理中，SLA 开始按自然时间计时，首次响应时限 15 分钟、解决时限 4 小时。
9:12，处理人首次响应，确认问题出在查询服务依赖的接口超时。9:30，处理人按更新频率同步进展，工单状态保持处理中。10:00，解决时限剩余 25%，系统触发预警，通知处理人和服务负责人。服务负责人判断当前处理人缺少数据库权限，按升级规则协调 DBA 加入处理，工单记录升级原因和新增处理人。
11:20，接口恢复，处理人验证查询页面可用，工单转为待确认。11:40，报单人确认恢复，工单关闭。整张工单从提交到关闭用时 2 小时 40 分钟，在解决时限内；升级发生在预警之后、超时之前，处置有效。
这个示例体现的可迁移规律是：判定依据在提交时填全，受理人按表定级并留痕，预警触发后由升级责任人协调资源而非等待超时，关闭前由报单人确认结果。规则中的每个环节都对应一个具体动作和记录。
完成检查：规则是否真的在运行
机制建立后，需要用数据判断它是否被执行，而不是只看规则文档是否存在。以下检查项可按月执行，每项给出通过标准。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 分级分布是否合理 | 统计各级工单占比 | 无单一级别占比超过约定上限，P1、P2 占比处于可解释范围 |
| 判定依据填写完整率 | 抽查影响范围、紧急程度、服务承诺字段 | 完整率达到约定水平，缺失工单有补录记录 |
| SLA 达成率与超时归因 | 按级别统计响应与解决达成率，归类超时原因 | 达成率不低于目标，超时原因可归入资源、流程或规则三类 |
| 升级规则是否被触发并有效处置 | 检查预警和升级记录 | 预警有通知记录，升级有原因和处置结果，超时前升级比例合理 |
| 规则复核与修订节奏 | 查看规则版本和修订记录 | 按约定周期复核，修订有依据并保留历史版本 |
检查结果指向两类动作：如果填写完整率和升级处置不达标，改进入口校验、受理培训和交接动作；如果分级分布长期失衡或某级持续超时，回到分级判定表和 SLA 对应表修订规则。ONES Desk 提供工单分析报表，可用于观察工单分布与团队处理情况；报表中是否包含 SLA 达成率、超时归因等具体指标，需按实际版本确认。规则修订后重新执行上述检查，形成“检查—归因—修订—再检查”的循环，优先级与 SLA 机制才能持续有效。
常见问题
报单人坚持要求提高优先级，受理人应该怎么处理？
把报单人的紧急描述作为参考信息记录，级别仍按影响范围、紧急程度、服务承诺三项判定。受理人可以在工单中写明报单人的诉求和实际判定依据，双方意见不一致时提交服务负责人裁定，裁定结果和理由一并写入工单。这样既回应了报单人的关切，也让后续规则修订有据可查。
SLA 计时应该从工单提交开始，还是从受理确认开始？
两种口径都可用，关键是同一服务目录内保持一致。从提交时间起算，能反映报单人的真实等待，但会把信息不全导致的退回时间也算进去；从受理确认起算，更贴近处理团队的实际投入，但可能弱化对首次响应的约束。常见做法是响应时限从提交起算、解决时限从受理确认起算，并在服务目录中写明，避免同一张工单被算出不同剩余时间。
等待报单人补充信息的时间要不要暂停计时？
可以暂停，但必须有状态记录和恢复时间，否则暂停会成为规避超时的手段。建议只对明确的状态开放暂停，例如等待报单人补充信息、等待第三方厂商处理，并约定单次暂停上限和累计暂停上限。暂停期间工单状态、暂停原因、恢复时间都要留痕，检查时按扣除暂停后的净时长计算达成率。
试运行后发现 P1 工单占比过高，是规则问题还是执行问题？
先看超时和定级依据的分布。如果 P1 集中在少数受理人或少数服务项，且判定字段填写不完整，多半是入口校验和定级培训的问题，应改进入口必填校验和判定提示。如果 P1 普遍存在、实际处理时长中位数明显低于承诺时限，说明判定条件过宽，应收窄 P1 的判定条件或把部分场景下移到 P2，并保留修订前后的对比数据。
ONES Desk 能直接支撑这套优先级与 SLA 机制吗？
ONES Desk 支持自定义工单属性并评估、定义工单优先级，也支持灵活调整工作流，可作为承载优先级字段与工单流转的工具方向；工单还可关联到 ONES Project 的需求或缺陷工作项持续跟踪。SLA 计时、超时预警与自动升级的具体配置方式，以及分析报表包含的指标口径，需结合所选版本向厂商确认后再落地。
