工单路由规则表把工单特征映射到处理组，让分派有据可查。设计时要先确定分派维度，再按优先级排列规则，写明目标组、备选组和兜底去向，最后用历史工单回放验证。本文给出可直接填写的字段清单、五步建表流程、角色分工、示例规则表和上线检查项。
要点总览（TL;DR）
- 规则表的核心结构是“匹配条件 + 目标处理组 + 优先级”，字段要能直接判定，避免“紧急”“重要”这类模糊描述。
- 建表按五步推进：盘点历史工单与改派记录、确定分派维度、按具体到宽泛排列规则、与处理组确认承接范围、用历史工单回放校验。
- 规则表由服务台或工单管理员维护，处理组负责人确认承接范围，规则变更经评审后发布，误分派通过改派原因回流为修订项。
- 上线前重点检查条件无歧义、同优先级规则互斥、兜底规则可达；运行期按月看命中分布与改派数据，每季度全表复核。
- 规则表只负责处理权分配，跨团队升级时限与SLA计时、工单状态流转节点设计属于相邻主题，分别维护。
规则表先定哪些字段：一张可执行的表长什么样
规则表要能直接执行，每条规则必须回答三个问题：什么条件下命中、命中后交给谁、多条规则同时命中时谁优先。字段设计围绕这三点展开，缺一项都会让分派依赖人工判断。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 规则编号 | 唯一且稳定，便于引用和变更记录 | R-001 |
| 优先级 | 整数，数值越小越先裁决；同一优先级内规则必须互斥 | 10 |
| 匹配条件 | 写成“字段 + 运算符 + 取值”，多个条件用且/或连接 | 工单类型 = 账号权限 且 客户等级 = 重点 |
| 目标处理组 | 填写实际承接的团队或岗位，不写个人姓名 | 账号支持组 |
| 备选处理组 | 目标组不可用时的接收方，需对方确认承接范围 | 一线服务台 |
| 兜底标记 | 标记该规则是否为兜底规则，全表只保留一条 | 是 |
| 生效时间 | 规则开始生效的日期，变更时保留历史版本 | 2025-03-01 |
| 负责人 | 对该条规则内容和效果负责的人 | 服务台管理员 |
匹配条件是最容易写坏的一栏。“比较紧急”“重要客户”这类描述无法判定，应改为可枚举的取值，例如“优先级 = P1”“客户等级 ∈ {重点, 核心}”。条件涉及的字段必须已在工单表单中存在，否则规则无法命中。
优先级解决多条规则同时命中的裁决问题。排列原则是从具体到宽泛：限定条件越多的规则优先级越高，覆盖范围越大的规则越靠后。同一优先级内的规则条件必须互斥，即一张工单不可能同时满足两条，否则结果取决于执行顺序，难以复现。
兜底规则保证任何工单都有去处。它通常放在最低优先级，条件为“全部工单”，目标组为服务台或值班组。没有兜底规则时，条件未覆盖的工单会滞留在未分派状态，需要人工逐条处理。
从分派维度到规则条目：五步建表流程
建表从历史数据出发，逐步收敛为可执行的规则条目。每一步都有明确输入和输出，完成标志是输出物通过对应检查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 盘点现状 | 近3–6个月历史工单样本 | 统计工单类型分布、现有分派方式、人工改派记录 | 工单类型清单与现有分派方式说明 | 覆盖主要工单类型，改派原因已归类 |
| 2. 确定维度 | 工单类型清单 | 选出对分派结果影响最大的字段，为每个字段定义取值枚举 | 分派维度与取值枚举表 | 每个取值都能在工单表单中找到对应字段 |
| 3. 排列规则 | 维度与取值枚举 | 按具体到宽泛组合条件，逐条编号并设定优先级 | 规则条目初稿 | 同优先级规则互斥，兜底规则已就位 |
| 4. 指定处理组 | 规则条目初稿、组织分工 | 为每条规则填写目标组与备选组，与各组负责人确认 | 处理组已确认的规则表 | 每个处理组书面确认承接范围 |
| 5. 回放校验 | 历史工单样本、规则表 | 用样本逐条套用规则，统计命中与误分派 | 回放报告与修订后的规则表 | 命中率与误分派率达到约定标准 |
第一步的关键是看改派记录。人工改派集中的类型，往往说明现有分派方式缺少可判定条件，这些类型应优先纳入规则。第二步确定维度时，字段数量控制在三到五个即可，维度过多会让规则条目迅速膨胀，维护成本上升。
第三步排列规则时，先写条件最具体的条目，再逐层放宽。例如先写“账号权限类 + 重点客户”，再写“账号权限类”，最后写兜底。第四步必须让处理组负责人确认，规则表上的目标组与实际承接能力不一致，上线后会产生大量二次转派。
第五步回放是验证规则表的主要手段。把历史工单按字段值套入规则，记录每条工单命中的规则编号和最终处理组，与当时的实际处理组对比。命中但分错组的记为误分派，未命中任何具体规则而落入兜底的记为兜底命中。两类数据分别统计，才能判断问题出在条件覆盖还是处理组归属。
角色与交付物：谁维护规则表、谁确认分派结果
规则表的有效性依赖明确的责任分工。建表、确认、评审、反馈四个环节各有负责人，缺一个环节规则表就会逐渐与实际脱节。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 服务台或工单管理员 | 建表与日常维护，处理规则变更申请，统计命中与改派数据 | 规则表主版本、变更记录、月度运行报告 |
| 各处理组负责人 | 确认本组承接范围与备选组安排，反馈误分派 | 承接范围确认记录、误分派反馈单 |
| 规则评审人 | 评审新增与修改规则，判断是否与现有规则冲突 | 评审结论与发布记录 |
| 一线处理人 | 执行分派结果，对不合理分派提交改派并说明原因 | 改派记录及原因分类 |
规则变更需要评审后发布。评审关注三点：新规则与现有规则是否冲突、目标组是否已确认承接、兜底规则是否仍然可达。发布时保留旧版本和生效时间，便于回溯某张工单当时适用的规则。
误分派反馈要有固定回流渠道。处理人在工单系统中改派时选择原因类别，例如“条件未覆盖”“处理组归属错误”“备选组不应接收”，管理员按月汇总，把高频原因转化为规则修订项。反馈渠道与工单改派动作合并，避免额外填报负担。
规则表落地需要工单系统承载字段、处理组和流转状态。ONES Desk 支持自定义工单属性，可把分派维度配置为工单字段；工作流可灵活调整，处理组与流转节点可在其中组织；工单还可关联待办事项，便于服务团队与研发团队交接。规则表中的条件字段与目标组，需要先在系统中建立对应字段和团队结构，规则才能稳定执行。
示例：一张覆盖三类工单的路由规则表
以下示例设定一个企业服务台场景，覆盖账号权限类、系统故障类、咨询类三类工单，分派维度取工单类型、客户等级、影响范围三项。
| 规则编号 | 优先级 | 匹配条件 | 目标处理组 | 备选处理组 | 兜底 |
|---|---|---|---|---|---|
| R-001 | 10 | 工单类型 = 系统故障 且 影响范围 = 多部门 | 系统运维组 | 值班技术组 | 否 |
| R-002 | 20 | 工单类型 = 系统故障 | 系统运维组 | 一线服务台 | 否 |
| R-003 | 30 | 工单类型 = 账号权限 且 客户等级 = 重点 | 账号支持组 | 一线服务台 | 否 |
| R-004 | 40 | 工单类型 = 账号权限 | 账号支持组 | 一线服务台 | 否 |
| R-005 | 50 | 工单类型 = 咨询 | 客户服务组 | 一线服务台 | 否 |
| R-006 | 99 | 全部工单 | 一线服务台 | 服务台主管 | 是 |
走查一张工单：某重点客户提交“无法登录业务系统”，工单类型填“账号权限”，客户等级为“重点”，影响范围为“单人”。系统按优先级从10开始匹配，R-001要求系统故障，不命中；R-002同样不命中；R-003两项条件均满足，命中，分派至账号支持组。若账号支持组当日无人值班，工单转至备选组一线服务台。
兜底规则的触发情形出现在条件未覆盖时。例如一张工单类型填“其他”、客户等级为空，R-001至R-005均不满足，落入R-006，由一线服务台接收并判断后续去向。兜底命中率高说明维度取值枚举不完整，应回到第二步补充取值，而不是继续增加具体规则。
上线前与运行中的完成检查
规则表是否可上线，用一组可核对的检查项判断。上线前关注规则本身的质量，运行期关注规则与实际分派的偏差。
上线前检查清单：
- 每条匹配条件都能用字段值判定，没有“紧急”“重要”等模糊描述；
- 同一优先级内不存在两条规则可被同一张工单同时满足；
- 兜底规则存在且条件为全部工单，目标组已确认可接收；
- 每个目标处理组与备选处理组均已书面确认承接范围；
- 规则涉及的字段已在工单表单中建立，取值枚举与规则表一致；
- 历史工单回放已完成，命中率与误分派率有统计结果和修订记录。
回放验证的观察口径要事先约定。命中率指样本中命中具体规则（不含兜底）的比例，反映条件覆盖是否充分；误分派率指命中规则但目标组与实际处理组不一致的比例，反映处理组归属是否准确。两个指标分开统计，避免用总体准确率掩盖某一类问题。具体阈值按团队历史数据设定，没有统一标准。
运行期复核清单：
- 规则命中分布：各规则命中次数是否与预期一致，是否存在从未命中的规则；
- 长期未命中规则：连续多个周期零命中的规则，检查条件是否过严或字段取值已变化；
- 频繁改派工单：统计改派率高的规则，分析是条件问题还是处理组承接问题；
- 兜底命中比例：兜底占比持续上升，说明维度枚举需要补充。
规则变更与复核按固定节奏进行。建议每月查看一次命中分布与改派数据，每季度做一次全表复核，组织调整、业务线变化或新工单类型上线时触发临时复核。复核输出修订后的规则表版本和变更说明，旧版本保留备查。跨团队升级时限与SLA计时、工单状态流转节点设计属于相邻主题，规则表只负责处理权分配，两者在流程中衔接但分别维护。
常见问题
工单类型很多，规则表要不要为每一种类型都单独建一条规则？
不必逐类建规则。先看历史工单中哪些类型的分派结果不同，只有目标处理组确实不同的类型才需要独立规则。目标组相同的类型可以合并为一条条件，用“工单类型 ∈ {A, B, C}”表达。类型过多时，优先把高频类型和改派集中的类型纳入规则，其余交给兜底规则接收后再判断，避免规则表条目膨胀到难以维护。
同一张工单同时满足两条规则时，怎么保证分派结果稳定可复现？
靠优先级和互斥两个机制。优先级数值小的先裁决，排列时让条件更具体的规则排在前面；同一优先级内的规则条件必须互斥，即一张工单不可能同时满足两条。如果发现两条同优先级规则可能同时命中，说明它们本应处于不同优先级，或者条件需要收窄。规则上线前用历史样本逐条套用，检查是否存在多规则同时命中的情况。
兜底规则命中比例一直很高，应该怎么处理？
兜底命中高说明具体规则的条件覆盖不足，通常有两种原因：分派维度的取值枚举不完整，或者某些工单类型根本没有对应规则。处理方式是回到建表第二步，统计落入兜底的工单在类型、客户等级、影响范围等字段上的分布，把集中出现的取值补进枚举，再为这些取值组合新增规则。直接增加兜底之上的宽泛规则只能暂时缓解，取值枚举补齐后规则才稳定。
处理组负责人不认可规则表上分配给本组的工单，怎么办？
这类分歧应在规则发布前解决，而不是上线后靠改派消化。建表第四步要求每个目标组和备选组书面确认承接范围，负责人确认的是“这类工单由本组处理”这一判断，而非某张具体工单。若上线后仍出现归属争议，通过改派原因类别记录，例如“处理组归属错误”，由管理员按月汇总，提交规则评审调整目标组。争议集中的规则应优先复核。
规则表设计好后，在工单系统里落地需要注意什么？
规则表依赖的字段必须先在工单系统中存在，取值枚举与规则表保持一致，否则规则无法命中。处理组也要在系统中建立对应的团队或岗位结构，备选组同样需要可被指定。ONES Desk 支持自定义工单属性，可把分派维度配置为工单字段；工作流可灵活调整，处理组与流转节点可在其中组织；工单还可关联待办事项，便于服务团队与研发团队交接。规则表中的条件字段与目标组，需要先在系统中建立对应字段和团队结构，规则才能稳定执行。
