设计工单分类规则表，先确定分类结果要驱动哪些动作，再决定分几层、每层怎么命名，最后把判定条件写成可观察的字段组合。规则表同时承载类目层级、判定规则、归属范围和维护责任，缺一项都会导致分类口径随执行人变化。下文按这一顺序给出可填写、可评审、可试分类验证的完整结构。
要点总览（TL;DR）
- 分类层级深度由分类结果要驱动的动作决定：只用于统计两层够用，要驱动分派与SLA通常需要三层，取所有用途中最细的粒度作为上限。
- 推荐“业务域—问题类型—具体事项”三层结构，每层只回答一个问题，同级互斥，全表只保留一个兜底类目并进入人工复核。
- 判定条件写成“字段+取值+组合关系”的可观察表达式，每条规则配正例与反例，冲突按优先级取第一条命中，未命中走兜底。
- 每条规则登记适用范围、唯一归口团队、唯一维护责任人和生效版本，变更走提出—评审—生效—通知—回溯流程。
- 上线前用历史工单试分类，统计未命中率与人工改判率并设定阈值，结果留档作为下一版调整基线。
先定分类要服务哪些动作
分类层级不是越细越好，深度由消费分类结果的动作决定。设计前先列出：谁会用分类结果做什么。只用于月度统计的团队，两层通常够用；分类结果要直接驱动工单分派、SLA计时和优先级判定时，两层往往无法同时区分“哪个业务域”和“哪类问题”，需要三层。
把用途、消费方和所需粒度写进一张对照表，作为后续层级设计的依据。
| 分类用途 | 消费方 | 所需粒度 | 对层级的要求 |
|---|---|---|---|
| 工单分派到处理团队 | 服务台调度、一线坐席 | 能区分业务域与问题类型 | 至少两层，跨团队共用的业务域需三层 |
| 统计报表与趋势分析 | 服务负责人、业务方 | 按业务域汇总，按问题类型看构成 | 两层可满足，第三层用于下钻 |
| SLA与优先级判定 | 服务台、值班经理 | 能识别故障类与咨询类、影响范围 | 问题类型层必须独立，且与优先级规则对齐 |
| 知识沉淀与自助服务 | 知识库维护人、终端用户 | 能对应到具体事项与解决方案 | 需要第三层具体事项 |
对照表填完后，取所有用途中要求最细的粒度作为层级深度上限，避免为个别报表单独加深层级。本文讨论范围限于服务数据规范中的分类规则表本身；缺陷报告规范、研发平台跨对象字段治理属于相邻主题，不在此展开。
分类层级怎么分层与命名
推荐三层结构：业务域—问题类型—具体事项。每层只回答一个问题，上层回答“这件事属于哪块业务”，中层回答“这是哪类诉求”，下层回答“具体是什么事”。三层之外不再加深，更细的区分交给标签或工单描述，避免类目数量失控。
| 层级 | 编码 | 名称示例 | 定义 | 示例 | 上级 |
|---|---|---|---|---|---|
| 第一层 业务域 | ACC | 账号与登录 | 与用户身份、认证、权限入口相关的问题 | 登录失败、账号被锁 | — |
| 第二层 问题类型 | ACC-F | 故障 | 功能未按预期工作，需要修复 | 验证码收不到 | ACC |
| 第三层 具体事项 | ACC-F-02 | 验证码接收异常 | 短信或邮件验证码未送达、延迟或校验失败 | 用户多次点击未收到短信 | ACC-F |
命名遵循几条硬规则：使用名词短语，同一层级词性和长度尽量统一；同级类目互斥，任意一张工单在同类目下只能落入一个选项；不使用“其他”“杂项”作为常规类目，全表只保留一个兜底类目，且兜底类目必须进入人工复核。
新增类目设准入条件：现有类目无法容纳、近三个月有稳定量的工单落入兜底、且有明确归口团队承接。满足条件后走变更评审，避免个人临时加类目造成口径分裂。
判定条件怎么写才可执行
判定条件要写成“字段+取值+组合关系”的表达式，字段取自工单上可观察的信息：来源渠道、请求动作、影响范围、报错对象、涉及系统模块。描述性语言如“用户很着急”“问题比较严重”不能作为判定依据，因为它们无法被不同人复核出一致结果。
| 规则ID | 条件表达式 | 目标类目 | 优先级 | 正例 | 反例 |
|---|---|---|---|---|---|
| R-ACC-01 | 来源=电话 且 请求动作=无法登录 且 报错对象=验证码 | ACC-F-02 验证码接收异常 | 10 | 用户来电称收不到短信验证码，无法登录 | 用户来电称忘记密码，可正常收到验证码 |
| R-ACC-02 | 请求动作=修改绑定手机 且 影响范围=单用户 | ACC-R-01 账号信息变更 | 20 | 用户申请更换绑定手机号 | 批量用户手机号显示异常，属故障 |
| R-ACC-99 | 未命中以上任一规则 | ACC-X 待复核 | 999 | 描述模糊、无法判断诉求的工单 | 已明确为验证码问题的工单 |
冲突处理按优先级取第一条命中规则，优先级数值越小越先匹配；所有规则都未命中时进入唯一兜底类目并转人工复核，复核结论定期回流，用于补充规则或修正条件。每条规则必须配正例和反例，正例说明该规则该命中什么，反例说明容易误判的边界情形，这是让不同坐席分出一致结果的关键材料。
归属范围与维护责任怎么落到人
规则表失管通常不是缺规则，而是缺责任。每条规则要写明适用范围：适用的产品线、渠道、地区或客户分层，以及明确的不适用范围。跨产品线共用的业务域，按产品线拆成独立规则，避免一条规则被多方解释。
| 角色 | 动作 | 产出 | 时点 |
|---|---|---|---|
| 规则提出人 | 提交新增或修改申请，附正反例与影响范围 | 变更申请单 | 发现缺口后 |
| 归口团队负责人 | 评审类目归属与条件是否可执行 | 评审意见 | 申请提交后约定工作日内 |
| 规则维护人 | 更新规则表、升版本号 | 新版本规则表 | 评审通过后 |
| 服务台运营 | 通知坐席并更新培训材料 | 通知记录、培训更新 | 生效前 |
| 数据负责人 | 回溯历史工单，标注版本 | 重分类记录 | 生效后约定周期内 |
每个类目指定唯一归口团队，每条规则指定唯一维护责任人，避免多人可改导致口径漂移。变更流程固定为提出—评审—生效—通知—回溯五个环节，并明确生效时点，例如“评审通过后次月1日生效”，让统计口径有清晰的分界。历史工单的追溯口径也要事先约定：规则变更后是否重分类、重分类结果如何标注版本，通常建议保留原分类并附加版本标记，便于对比变更前后的分布。
完整示例：一张可用的分类规则表
以下示例以“账号与登录”业务域展示三层类目与两条判定规则如何组合成一张表，字段可直接迁移到其他业务域。
| 规则ID | 层级路径 | 条件 | 目标类目 | 优先级 | 归口团队 | 维护人 | 生效版本 |
|---|---|---|---|---|---|---|---|
| R-ACC-01 | ACC / ACC-F / ACC-F-02 | 来源=电话 且 请求动作=无法登录 且 报错对象=验证码 | 验证码接收异常 | 10 | 账号服务组 | 张（账号服务组指定） | V1.2 |
| R-ACC-02 | ACC / ACC-R / ACC-R-01 | 请求动作=修改绑定手机 且 影响范围=单用户 | 账号信息变更 | 20 | 账号服务组 | 张（账号服务组指定） | V1.2 |
逐项说明填写依据：层级路径用编码串联三层，保证类目唯一可定位；条件只使用工单上可采集的字段，来源渠道决定受理方式，请求动作和报错对象区分故障与咨询；优先级数值留出间隔，便于后续插入新规则；归口团队对应实际承接处理的团队，维护人对该规则的内容准确性负责；生效版本与规则表版本号一致，便于追溯某张工单按哪版规则分类。
迁移到其他业务域时，调整点集中在三处：业务域编码与名称、问题类型的取值集合（故障、咨询、需求是否都适用）、判定字段中与业务强相关的部分（如支付域用“交易状态”“支付渠道”替代“报错对象”）。层级结构和责任字段保持不变。
规则表需要有承载它的工单系统。ONES Desk 支持自定义工单属性与工单内容，可以把业务域、问题类型、具体事项和来源渠道等字段配置到工单上；工作流可灵活调整，分类结果能衔接后续分派与流转；优先级可评估定义，分析报表可用于观察各类目的工单分布。规则表本身仍以文档形式维护版本，系统字段与文档规则表保持同一套编码即可。
上线前怎么检查规则表是否可用
规则表能否投入使用，用一组可逐项核对的检查来判断，而不是靠评审会上的主观认可。
- 层级检查：同级类目互斥，无空类目，兜底类目全表唯一且指向人工复核。
- 条件检查：每条规则有正例和反例，冲突有明确优先级，未命中路径唯一且可执行。
- 责任检查：每条规则有唯一维护人，每个类目有唯一归口团队，适用范围与不适用范围均已写明。
- 口径检查：抽取一批历史工单试分类，统计未命中率与人工改判率，事先设定可接受阈值，例如未命中率低于5%、改判率低于10%，超出则回到条件设计环节修正。
- 维护检查：版本号、评审记录、生效通知机制已就位，历史工单的追溯口径已确认。
| 检查项 | 通过标准 | 记录方式 |
|---|---|---|
| 试分类样本量 | 覆盖各业务域与各来源渠道 | 样本清单与抽样说明 |
| 未命中率 | 低于预设阈值 | 试分类结果统计表 |
| 人工改判率 | 低于预设阈值，改判原因可归类 | 改判记录与原因分布 |
| 规则覆盖 | 每条规则在样本中至少命中一次或有正例佐证 | 规则命中次数表 |
试分类结果要留档，作为下一版规则调整的基线。规则表上线后按固定周期复查未命中与改判数据，把高频改判情形转化为新规则或条件修正，分类口径才能在执行中保持统一。
常见问题
业务域和问题类型这两层，哪个应该先定？
先定业务域，再定问题类型。业务域对应组织内相对稳定的业务板块，例如账号、订单、支付，变更频率低；问题类型是跨业务域复用的诉求分类，例如故障、咨询、需求，需要与SLA和优先级规则对齐。先固定业务域，问题类型才能在各业务域下保持一致取值，避免出现“账号域叫故障、支付域叫异常”的口径分裂。
判定条件里用到的字段，工单上采集不到怎么办？
优先调整采集方式，而不是放宽条件。可以在工单提交表单中增加必填字段，例如来源渠道、涉及模块、影响范围，让判定条件有据可依。确实无法采集的信息，不要写进自动判定条件，改为在人工复核环节补充。判定条件只使用工单上稳定可观察的字段，是保证不同人分出一致结果的前提。
规则变更后，历史工单要不要重新分类？
通常保留原分类并附加版本标记，便于对比变更前后的分布。是否重分类取决于统计用途：需要看长期趋势时，保留原分类更稳妥；需要按新口径回溯分析时，可对指定时间段重分类，但必须记录重分类规则与版本，避免同一张工单在不同报表中归属不一致。这一口径应在变更评审时一并确认。
试分类的未命中率和改判率设多少算合理？
没有统一标准，取决于业务复杂度和工单量。可以先设定初始阈值，例如未命中率低于5%、人工改判率低于10%，试分类后再根据实际结果调整。阈值的作用是给出明确的通过判断，而不是追求数字好看。改判原因要归类记录，高频改判情形应转化为新规则或条件修正，这是规则表持续收敛的主要输入。
规则表放在文档里维护，还是直接配置到工单系统里？
两者可以并存，关键是编码一致。规则表以文档形式维护版本、评审记录和正反例，便于评审与追溯；工单系统承载业务域、问题类型、具体事项、来源渠道等字段，让分类结果衔接分派与流转。ONES Desk 支持自定义工单属性与工单内容，工作流可灵活调整，优先级可评估定义，分析报表可用于观察各类目工单分布，系统字段与文档规则表使用同一套编码即可保持口径统一。
