工单路由策略要解决的是“这张工单该由谁处理”，把处理权归属写成可执行、可复核的分配规则。本文按“定框架—编规则—分角色—看示例—做验收”的顺序，给出维度清单、规则表字段、角色职责和上线检查清单。文中会自然提到 ONES Desk 可作为承载工单分类、字段配置与流程自定义的工具方向，具体能力以实际配置和厂商确认为准。
要点总览（TL;DR）
- 工单路由策略先回答三个问题：处理权归谁、按什么条件匹配、匹配不上或匹配错时走哪条路径，三层缺一不可。
- 路由维度以工单类型为主干，叠加一到两个区分度高的维度（如产品模块、客户等级），规则按“具体优先、宽泛其次、默认兜底”排序。
- 落地按五步走：盘点类型与团队、定义匹配条件、编写规则表、确定分派动作与通知、用历史工单回放验证后再放开自动分派。
- 规则需要有人维护：调度角色处理无匹配工单并登记错分，处理组负责人维护接收条件，流程负责人审批变更并定期复核。
- 上线前逐项核对归属完整、冲突可控、回放达标、责任到人、异常有路径、通知可达、记录可追溯，先对稳定类型开放自动分派。
路由策略先定三件事：分给谁、按什么分、分不准怎么办
一套能运转的路由策略，先要回答三个问题：处理权归谁、依据什么匹配、匹配不上或匹配错时走哪条路径。三个问题对应策略的三层结构——责任对象、匹配条件、兜底机制。缺少任何一层，规则都会在实际运行中退化成“先到先领”或“调度凭经验指派”。
第一件事：分给谁
处理权归属对象可以是处理组、值班组、具体岗位，也可以是个人。多数服务台以“组”为最小分配单位，再由组内负责人二次分配到人，这样人员变动时规则不需要频繁改动。归属对象要写到可识别的名称，例如“账号权限组”“产品支持一组”，避免使用“相关同事”这类无法自动匹配的描述。
第二件事：按什么分
常见路由维度包括：
- 工单类型：账号权限、产品故障、账单咨询等，是最稳定的主维度。
- 来源渠道：门户提交、邮件、电话记录、内部转交，影响响应方式和受理团队。
- 客户等级：重点客户或合同客户可指定专属处理组。
- 所属产品/模块：多产品线团队按模块划分处理权。
- 值班组与技能标签：用于非工作时间或专业问题的定向分配。
维度并非越多越好。每增加一个维度，规则数量和冲突概率都会上升。建议以工单类型为主干，再叠加一到两个区分度高的维度，例如“类型＋产品模块”或“类型＋客户等级”。
第三件事：分不准怎么办
规则设计要预设两类异常：无匹配和多匹配。无匹配的工单进入默认队列，由调度角色人工确认归属；多匹配的工单按优先级取第一条命中规则，其余规则不再生效。优先级顺序的一般做法是：先匹配条件更具体的规则（如指定客户＋指定模块），再匹配宽泛规则（如仅按类型），最后落到默认队列。这条顺序要写进规则表，而不是靠执行人临场判断。
自动分派与人工调度的取舍
自动分派适合条件清晰、类型稳定的工单，优点是响应快、口径一致；人工调度适合新业务、边界模糊或高价值工单，优点是能结合上下文判断。实际落地常见的是混合方式：规则命中后自动进入目标组，调度角色保留确认和转派权限；规则未命中时直接进入待调度队列。选择哪种方式，取决于工单类型的稳定程度和团队对错分的容忍度，而不是追求全自动。
从工单分类到规则表：一步步建立可执行的路由规则
框架确定后，把设计拆成五步执行。每一步都说明输入、动作、输出和完成标志，便于边做边核对。
第一步：盘点工单类型与处理团队
输入是近三个月的历史工单和现有团队分工。动作是归类工单主题、统计各类占比，并列出每个团队实际承接的范围。输出是一张“工单类型—责任团队”映射表。完成标志是：每一类工单都能在表中找到至少一个承接团队，找不到的单独标出，作为后续要新建队列或调整分工的依据。
第二步：选定路由维度并定义匹配条件
输入是第一步的分类结果。动作是为每类工单选定主维度和辅助维度，并把维度转成可判断的条件，例如“类型＝账号权限”“来源＝客户门户”“客户等级＝重点”。输出是维度清单与条件定义。完成标志是：每个条件都能被受理人员在工单字段中看到并判断，不依赖口头解释。
第三步：编写规则表
规则表建议包含以下字段：
| 字段 | 说明 |
|---|---|
| 规则编号 | 唯一标识，便于变更记录引用 |
| 匹配条件 | 维度与取值的组合，写清“且/或”关系 |
| 目标处理组 | 规则命中后的归属对象 |
| 优先级 | 数字越小越先匹配，用于处理冲突 |
| 兜底标记 | 标识该规则是否为默认路径 |
| 分派方式 | 自动分派或需调度确认 |
| 生效范围 | 适用渠道、时间段或客户范围 |
输出是一份完整规则表。完成标志是：任意一张工单按优先级顺序走一遍，都能得到唯一归属或明确进入兜底队列。
第四步：确定分派动作与通知方式
输入是规则表中的“分派方式”字段。动作是明确命中后系统执行什么、通知谁、以什么方式通知，例如自动进入目标组并通知组负责人，或进入待确认列表由调度角色处理。输出是分派动作说明。完成标志是：处理组能在约定时间内感知到新工单，且知道下一步动作。
第五步：历史工单回放验证
输入是一批已结案的历史工单。动作是按新规则重新计算归属，与当时的实际处理组比对，统计命中率、错分率和无人认领比例。输出是验证报告和规则调整清单。完成标志是：错分和无人认领的工单都有明确原因，且对应规则已修订或补充兜底路径。验证通过后再逐步放开自动分派范围，先覆盖稳定类型，再扩展到边界类型。
谁维护规则、谁处理错分：路由策略的角色与交付物
规则表写出来只是开始，能否长期可用取决于有没有人负责维护。路由机制通常涉及三类角色，各自承担不同的交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 调度/服务台 | 日常确认分派结果，处理无匹配工单，记录错分情况 | 待调度工单处理记录、错分登记 |
| 各处理组负责人 | 维护本组技能标签与接收条件，反馈规则是否贴合实际 | 组内接收条件说明、规则调整建议 |
| 流程负责人 | 审批规则变更，定期复核命中情况，组织错分复盘 | 规则表版本、变更记录、复盘记录 |
错分处理要有固定路径：调度角色发现错分后，先将工单转至正确处理组，再在错分登记中记录原规则编号和错分原因；流程负责人按周期汇总，判断是条件写错、维度缺失还是团队分工变化，据此发起规则变更。变更记录要保留修改前后的条件和生效时间，便于回溯。复核周期可按工单量设定，工单量大的团队按月复核，量小的团队按季度复核即可。
在工具承载上，ONES Desk 支持自定义工单属性与工单内容配置，并可灵活调整工作流，适合把工单类型、来源等路由维度做成字段，把分派与确认动作放进流程中；工单还可关联到 ONES Project 的需求或缺陷工作项，便于服务团队与研发团队交接。自动匹配规则的具体配置方式，建议在选型或实施时向厂商确认。
一个示例：三类工单的路由规则怎么落到表里
以下示例为演示情景，假设一个约二十人的服务团队，同时承接账号权限、产品故障和账单咨询三类工单，设有账号权限组、产品支持组和客户成功组。示例用于说明规则表如何填写，实际条件需按自身团队调整。
| 规则编号 | 匹配条件 | 目标处理组 | 优先级 | 兜底标记 | 分派方式 |
|---|---|---|---|---|---|
| R01 | 类型＝账号权限 且 客户等级＝重点 | 账号权限组 | 1 | 否 | 自动分派 |
| R02 | 类型＝账号权限 | 账号权限组 | 2 | 否 | 自动分派 |
| R03 | 类型＝产品故障 且 模块＝支付 | 产品支持组 | 1 | 否 | 自动分派 |
| R04 | 类型＝产品故障 | 产品支持组 | 2 | 否 | 需调度确认 |
| R05 | 类型＝账单咨询 | 客户成功组 | 1 | 否 | 自动分派 |
| R06 | 未命中以上任一规则 | 服务台待调度队列 | 99 | 是 | 人工调度 |
冲突处理示例：一张重点客户的支付模块故障工单，同时满足 R03 和 R04 的条件。按优先级，R03 先命中，工单进入产品支持组并自动分派，R04 不再生效。若该工单同时带有“账单咨询”标签，由于 R03 优先级高于 R05，仍按产品故障处理，账单问题由产品支持组在处理过程中转交客户成功组。
适用边界：上述规则假设三类工单边界清晰、处理组职责稳定。团队规模更小、工单量较低时，可合并处理组并减少规则条数，保留类型维度和兜底队列即可；工单量大、模块多的团队，则需要增加模块维度和更细的优先级分层，并提高复核频率。
上线前检查：路由策略是否可用的验证清单
规则表、角色分工和示例都准备好后，用以下清单逐项核对，全部通过再放开自动分派。
- 归属完整：每类工单都有明确处理组或兜底队列，不存在无归属的类型。
- 冲突可控：任意两张规则的条件重叠时，优先级能给出唯一结果；无法判断的重叠已合并或改写条件。
- 回放结果达标：历史工单回放中，命中率、错分率和无人认领比例已统计，错分原因已逐条对应到规则修订。
- 责任到人：规则变更审批人、日常调度人、各组接收条件维护人已明确，复核周期已写入约定。
- 异常有路径：无匹配工单进入待调度队列并有处理时限约定；多匹配工单按优先级取第一条，执行人无需临场决策。
- 通知可达：分派后处理组能在约定时间内收到通知，通知方式与团队实际使用的渠道一致。
- 记录可追溯：规则变更保留修改前后条件和生效时间，错分登记可回溯到具体规则编号。
清单通过后，建议先对稳定类型开放自动分派，观察一个复核周期内的错分情况，再逐步扩大范围。路由策略是随团队分工和业务变化持续调整的机制，定期复核比一次设计到位更重要。
常见问题
工单量不大、团队只有几个人，还需要完整的路由规则表吗？
可以简化，但保留最小结构。团队规模小时，处理组可以合并，规则条数随之减少，通常保留“工单类型”一个主维度和一条默认兜底规则即可运转。规则表仍建议保留编号、匹配条件、目标处理组和兜底标记四个字段，原因是后续人员增加或工单类型变多时，有表可改比重新设计省力。简化的是维度和规则数量，兜底路径和错分登记不宜省略。
自动分派和人工调度能不能同时用？怎么划分范围？
可以，混合方式是常见做法。划分依据是工单类型的稳定程度和错分代价：条件清晰、类型稳定的工单（如账号权限、固定模块故障）适合自动分派；新业务、边界模糊或高价值工单适合先进入待调度队列，由调度角色确认后再转派。规则命中后自动进入目标组、调度保留确认和转派权限，也是混合方式的一种。放开顺序建议先覆盖稳定类型，观察一个复核周期内的错分情况，再逐步扩大。
历史工单回放时发现大量工单无人认领，应该先改规则还是先调分工？
先看无人认领的原因再决定。如果这些工单在现有团队分工中本就找不到承接方，属于分工缺口，改规则解决不了，需要新建队列或明确承接团队；如果是条件写得过窄导致本应命中的工单落空，则修订匹配条件或补充规则。实际操作中两类原因常同时出现，建议把无人认领工单按主题归类，逐类标注“缺团队”还是“缺条件”，分别处理，避免用一条兜底规则掩盖分工问题。
规则变更后，正在处理中的工单要不要按新规则重新分派？
一般不建议对已进入处理环节的工单重新分派，避免打断处理节奏和造成责任不清。常见做法是规则变更只对变更生效时间之后新建的工单起作用，已在处理中的工单按原归属继续，确需转派的由调度角色人工处理并记录原因。变更记录中写清生效时间，便于回溯某张工单当时适用的是哪一版规则。若变更涉及处理组撤并，则需要对在途工单做一次集中转派，并单独通知相关方。
路由规则和工单优先级、SLA 是什么关系，设计时要一起考虑吗？
两者解决不同问题：路由规则决定工单由谁处理，优先级与 SLA 决定处理时限和升级节奏。设计时可以分开推进，但需要对齐字段口径，例如客户等级既影响路由归属，也可能影响优先级判定，同一字段在两处的取值定义应保持一致，避免出现“路由按重点客户分到专属组、优先级却按普通客户计算”的矛盾。跨团队升级时限和 SLA 计算的具体设计不在本文范围，可另行规划。
