工单分类规则表用来把“什么工单归到哪一类”写成可执行、可追溯的条目。本文提供一份可直接复制到表格工具的空白模板，按“一条规则一行”组织，并逐项说明字段含义、必填与选填约定、一条完整填写示例，以及后续新增、修改、停用和评审的维护方法。
要点总览（TL;DR）
- 模板按“一条规则一行”组织，核心字段分为标识、分类、判定、管理四组，共15项，可直接复制到表格工具使用。
- 规则编号、规则名称、适用工单类型、分类维度、判定条件、目标分类、优先级、状态、责任人属于必填项，其余字段可在草稿阶段暂缓填写。
- 判定条件建议写成“字段+比较方式+取值”的结构，分类维度与目标分类从同一份分类取值清单中选取，保证口径一致。
- 规则修改采用保留原行、升版本号、追加变更记录的方式，停用不删除，每季度评审一次失效规则与分类清单变化。
- 规则表落地到工单系统时，需与系统中的工单字段、分类选项和处理流程保持同一口径。
可复制空白模板：工单分类规则表
下表可直接复制到 Excel、在线表格或知识库表格中。每一行代表一条独立规则，规则之间通过优先级和互斥说明区分先后；表头下方保留空白行，按需增删行数即可。建议将表头设为冻结行，并对“规则编号”列做唯一性校验。
| 规则编号 | 规则名称 | 适用工单类型 | 分类维度 | 判定条件 | 目标分类 | 优先级 | 互斥与兜底说明 | 生效范围 | 生效时间 | 责任人 | 审批人 | 版本号 | 状态 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
使用方式有三点约定：第一，一条规则只描述一个判定逻辑，避免在一行里塞入多个“或”条件导致难以维护；第二，规则编号按“类型缩写-序号”编排，新增规则只追加编号，不复用已停用编号；第三，表格之外另存一份分类取值清单，列出每个分类维度的可选值，规则表中的“分类维度”和“目标分类”都从该清单取值。
字段说明：每个填写项记录什么
字段分为标识、分类、判定、管理四组。标识类保证规则可被引用，分类类固定归类的口径，判定类决定规则如何命中，管理类记录规则的生命周期。填写口径统一后，不同人维护同一张表也能得到一致结果。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 规则编号 | 规则的唯一标识 | 类型缩写加三位序号，全表唯一，停用后不复用 | INC-001 |
| 规则名称 | 规则的简短描述 | 用“条件+分类”概括，控制在20字以内 | 登录失败类问题归账号访问 |
| 适用工单类型 | 规则作用的工单范围 | 填写已定义的工单类型名称，跨类型规则需逐类型分行 | 事件工单 |
| 分类维度 | 本次归类依据的维度 | 从分类取值清单中选择，如问题现象、影响范围、来源渠道 | 问题现象 |
| 判定条件 | 规则命中的具体条件 | 写清字段、比较方式和取值，多个条件用“且”连接 | 标题或描述包含“登录失败”且来源为门户 |
| 目标分类 | 命中后归入的分类 | 填写分类清单中的末级分类，避免只写到一级分类 | 账号与访问/登录问题 |
| 优先级 | 多条规则同时命中时的执行顺序 | 用正整数，数值越小越先执行，同类型内不重复 | 10 |
| 互斥与兜底说明 | 与其他规则的关系及未命中时的处理 | 写明与哪些规则互斥、是否作为兜底规则 | 与INC-005互斥，命中后不再执行低优先级规则 |
| 生效范围 | 规则适用的组织或渠道范围 | 填写部门、业务线或提单渠道，全局适用写“全部” | 全部渠道 |
| 生效时间 | 规则开始生效的日期 | 填写日期，格式统一为YYYY-MM-DD | 2025-03-01 |
| 责任人 | 规则的日常维护人 | 填写岗位或姓名，负责解释规则和处理疑问 | 服务台值班主管 |
| 审批人 | 规则变更的确认人 | 填写岗位或姓名，新增和修改需经其确认 | 服务台负责人 |
| 版本号 | 规则内容的修订次数 | 采用V主版本.次版本，实质性变更升主版本 | V1.1 |
| 状态 | 规则当前所处的阶段 | 从“草稿、生效、停用”中选一个 | 生效 |
| 变更记录 | 规则修改的简要说明 | 记录日期、修改内容和修改人，追加不覆盖 | 2025-03-10 调整判定关键词，张三 |
判定条件是整张表最容易写歪的字段。建议把条件写成“字段+比较方式+取值”的结构，例如“影响范围等于多个部门”，避免只写“影响较大”这类无法核对的描述。分类维度与目标分类应来自同一份分类清单，维度决定看哪个角度，目标分类决定落到哪个末级节点，两者混用会让规则难以复用。
必填与选填：哪些字段不能空
必填字段是规则能够被执行和追溯的最低要求，缺一项就会导致规则无法判断或无法追责。选填字段用于补充管理信息，在规则刚起草或范围尚未确定时可以暂缓填写。
| 字段 | 必填/选填 | 理由或适用情形 |
|---|---|---|
| 规则编号 | 必填 | 唯一标识，用于引用、互斥说明和变更追溯 |
| 规则名称 | 必填 | 评审和沟通时的主要识别信息 |
| 适用工单类型 | 必填 | 决定规则在哪些工单上执行 |
| 分类维度 | 必填 | 固定归类依据，避免同一规则口径漂移 |
| 判定条件 | 必填 | 规则可执行的核心，缺失则无法命中 |
| 目标分类 | 必填 | 命中后的落点，缺失则规则无意义 |
| 优先级 | 必填 | 多条规则并存时决定执行顺序 |
| 状态 | 必填 | 区分草稿与生效，防止未确认规则被使用 |
| 责任人 | 必填 | 规则疑问和异常的处理入口 |
| 互斥与兜底说明 | 选填 | 存在规则交叉或需要兜底时填写 |
| 生效范围 | 选填 | 全局适用可写“全部”，局部试点时填写具体范围 |
| 生效时间 | 选填 | 草稿阶段可暂不填写，转为生效前补齐 |
| 审批人 | 选填 | 草稿阶段可暂缺，提交审批前补齐 |
| 版本号 | 选填 | 首次发布填V1.0，之后随修改更新 |
| 变更记录 | 选填 | 首次创建可写“初始版本”，后续每次修改追加 |
留空需要区分三种情况并统一标注：尚未确定的内容写“待定”，并在责任人处注明补齐时间；当前场景不适用的内容写“不适用”，例如全局规则的范围字段；确实无内容的写“无”，例如首版规则的变更记录。三种标注不要混用，也不要直接留白，否则评审时无法判断是遗漏还是有意为之。
填写示例：一条完整规则怎么填
以下示例演示一条已生效规则在模板中的完整填写结果，内容为演示情景，不代表任何真实企业的实际配置。
| 字段 | 填写内容 |
|---|---|
| 规则编号 | INC-003 |
| 规则名称 | 登录失败类问题归账号访问 |
| 适用工单类型 | 事件工单 |
| 分类维度 | 问题现象 |
| 判定条件 | 标题或描述包含“登录失败”且来源渠道为门户 |
| 目标分类 | 账号与访问/登录问题 |
| 优先级 | 10 |
| 互斥与兜底说明 | 与INC-007互斥，命中后不再执行优先级更低的同类规则 |
| 生效范围 | 全部渠道 |
| 生效时间 | 2025-03-01 |
| 责任人 | 服务台值班主管 |
| 审批人 | 服务台负责人 |
| 版本号 | V1.1 |
| 状态 | 生效 |
| 变更记录 | 2025-03-10 判定条件增加“来源渠道为门户”，张三 |
逐项看取值依据：编号INC-003表示事件工单类型下的第三条规则，序号连续便于查找；规则名称直接概括条件与分类，评审时无需展开判定条件即可理解意图；分类维度选“问题现象”，是因为该规则依据用户描述的现象归类，而非依据影响范围；判定条件写明了字段、关键词和渠道限定，避免把邮件渠道的同类问题误归进来；目标分类写到末级节点，保证统计口径可直接使用。
优先级设为10，是因为该规则需要先于通用兜底规则执行；互斥说明指向INC-007，提示维护人两条规则不会同时生效；生效范围写“全部”，与判定条件中的渠道限定并不矛盾，前者表示规则本身在所有渠道范围内适用，后者是命中条件的一部分。版本号V1.1对应变更记录中的一次条件调整，首次发布为V1.0，增加渠道限定属于实质性修改，因此升次版本并保留原记录。
调整与维护方法：规则表如何长期可用
规则表的价值在于持续可用。业务分类会随产品、渠道和组织调整而变化，维护动作需要固定下来，否则规则会逐渐与实际归类脱节。
新增规则按“提出—起草—评审—发布”推进：由责任人根据漏分类或错分类的工单提出需求，在表中新增一行并填写草稿状态，补齐必填字段后提交审批人确认；审批通过后填写生效时间和版本号V1.0，状态改为生效，并在变更记录中写明创建原因。修改规则时保留原行，调整判定条件或目标分类后升版本号，变更记录追加修改内容和日期，便于回溯旧规则曾如何归类。
停用规则时把状态改为停用，并在变更记录中写明停用原因和替代规则编号，不直接删除行。删除会让历史工单的归类依据失去对应记录，停用则保留了追溯线索。建议每季度做一次评审，重点检查三类问题：长期未命中的规则是否需要停用，分类清单调整后目标分类是否仍然有效，以及新增工单类型是否缺少对应规则。
规则冲突的处理约定写在“互斥与兜底说明”中：同一工单类型下，优先级数值小的规则先执行；两条规则条件重叠时，明确哪条优先并注明互斥关系；所有具体规则之外保留一条兜底规则，条件写“未命中其他规则”，目标分类指向“待分类”，由责任人定期清理待分类工单并反推补充规则。兜底规则同样需要编号、责任人和状态，不能以口头约定代替。
规则表落地到工单系统时，分类维度和目标分类需要与系统中的工单字段、分类选项保持一致。ONES Desk 支持自定义工单属性与工单内容配置，适配不同的收集场景，也支持评估和定义工单优先级；企业版通过统一门户集中接收工单，支持自定义处理流程与字段配置。维护时可以按规则表逐条核对系统字段的命名和取值，规则调整后同步更新字段选项与处理流程，使表上的规则和系统中的实际归类保持同一口径。规则变更的审批与版本管理仍以规则表自身的约定为准。
常见问题
规则表里的判定条件写多细才算够用？
判定条件的详细程度以“另一名维护人照着写能得出同样归类结果”为准。建议写成“字段+比较方式+取值”的结构，例如“标题或描述包含‘登录失败’且来源渠道为门户”。如果条件里出现“影响较大”“比较紧急”这类需要主观判断的描述，说明还需要补充可核对的字段和取值。条件过粗会导致误归类，过细则会让规则数量膨胀，可以先按主要现象归类，再对高频误判补充限定条件。
分类维度与目标分类有什么区别，能不能只填一个？
两者承担不同作用：分类维度说明这条规则从哪个角度看工单，例如问题现象、影响范围或来源渠道；目标分类说明命中后落到哪个末级分类节点。只填目标分类，后续维护时无法判断规则依据，新增规则容易与旧规则重叠；只填分类维度，规则没有落点，无法执行。两项都应从同一份分类取值清单中选取，清单调整时同步核对规则表。
多条规则同时命中同一张工单时怎么处理？
处理约定写在“互斥与兜底说明”字段中。同一工单类型下按优先级数值从小到大执行，数值小的先命中；两条规则条件重叠时，明确哪条优先并注明互斥关系。所有具体规则之外保留一条兜底规则，条件写“未命中其他规则”，目标分类指向“待分类”，由责任人定期清理待分类工单并反推补充规则。兜底规则同样需要编号、责任人和状态，避免以口头约定代替。
规则表需要和工单系统里的配置保持一致吗？
需要。规则表是管理约定，实际归类由工单系统中的字段选项和处理流程执行，两边口径不一致时，表上的规则无法反映真实归类结果。落地时可以按规则表逐条核对系统字段的命名和取值，规则调整后同步更新字段选项与流程。ONES Desk 支持自定义工单属性与工单内容配置，适配不同的收集场景，也支持评估和定义工单优先级；企业版通过统一门户集中接收工单，支持自定义处理流程与字段配置。规则变更的审批与版本管理仍以规则表自身的约定为准。
规则表应该由谁维护，多久评审一次？
每条规则指定一名责任人负责解释规则和处理疑问，审批人负责新增与修改的确认，两个角色可以由不同岗位担任。评审频率按业务变化速度确定，分类体系相对稳定的团队每季度评审一次即可；产品线或渠道调整频繁时，可以缩短到每月。评审重点包括长期未命中的规则、分类清单调整后失效的目标分类，以及新增工单类型是否缺少对应规则。
