工单分类目录是一张以“分类”为记录单位的台账，每条记录描述一个可被受理、分派和统计的工单类别。它至少应包含分类标识、名称、层级与父级、定义与适用范围、受理边界、默认责任团队、典型示例、优先级或服务时限约定、状态与生效时间、维护责任人。下面给出一张可直接复制填写的空白表，并逐项说明填写口径、必填规则与维护方法。
要点总览（TL;DR）
- 工单分类目录以“分类”为记录单位，至少包含分类标识、名称、层级与父级、定义、受理边界、默认责任团队、典型示例、优先级/服务时限、状态、生效时间、维护责任人。
- 分类标识与名称、层级与父级、定义与受理边界、默认责任团队、至少一条典型示例、状态、生效时间、维护责任人为必填；优先级/服务时限可先沿用上级约定，后续补齐。
- 分类定义说明“是什么”，受理边界说明“什么进、什么不进”，两者分开填写，能减少误归类和反复转派。
- 分类目录按季度复核，新增需说明触发条件并审批，改名保留标识，合并与停用保留历史记录，便于回溯历史工单口径。
- 目录落地到工单系统时，分类字段与责任团队需在系统中承载；ONES Desk 支持自定义工单属性与内容配置，具体层级与校验能力需结合所选版本核验。
可复制空白模板：工单分类目录表
将下表复制到表格工具中，一行填写一个分类。列头顺序与后文字段说明、必填规则和填写示例保持一致，便于多人协作时对照填写。
| 分类标识 | 分类名称 | 层级 | 父级分类 | 分类定义 | 受理边界 | 默认责任团队 | 典型示例 | 优先级/服务时限 | 状态 | 生效时间 | 维护责任人 |
|---|---|---|---|---|---|---|---|---|---|---|---|
填写前先确定两件事：目录覆盖的受理范围（例如仅IT服务台，还是包含行政、人事等共享服务），以及层级深度上限。范围与深度确定后，再逐行补充分类记录，避免边填边改结构。
每个字段记录什么：字段说明与填写口径
字段说明的作用是让不同填写人对同一列给出同一种写法。以下逐项对应模板列头，说明含义、填写方式和常见写法。
分类标识与分类名称
分类标识是分类在系统与报表中的稳定代号，建议采用“父级缩写-序号”或“业务域-序号”的短代码，如 IT-NET-01，一经使用不再随名称调整而变更。分类名称是面向受理人和提交人的可读名称，使用业务语言，避免内部缩写，同一父级下的名称不得重复。
层级与父级分类
层级填写该分类在目录中的深度，如一级、二级、三级；父级分类填写其直接上级的分类名称或标识，一级分类的父级填“无”。层级与父级必须相互对应：层级为二级的记录，父级必须指向一个已存在的一级分类。建议层级控制在两到三级，过深会增加提交人选择成本。
分类定义与受理边界
分类定义回答“这个分类是什么”，用一到两句话说明它覆盖的业务对象或问题类型。受理边界回答“什么进、什么不进”，列出应归入本类的典型情形，以及容易被误归入、应转到其他分类的情形。两者分开填写，可以避免定义写得笼统、实际受理时靠个人理解判断。
默认责任团队与维护责任人
默认责任团队是该分类工单首次分派时指向的团队，填写团队名称而非个人，避免人员变动导致分派失效。维护责任人是负责本分类定义、边界和示例更新的人，通常来自默认责任团队，承担目录复核与变更发起职责。两者可以相同，但职责不同：前者承接工单，后者维护分类本身。
典型示例
典型示例用具体场景描述，每条一行，写清“现象+对象”，如“办公区无线网络无法连接”“新员工邮箱账号开通”。示例数量建议两到五条，覆盖本类最常见的情形，并至少包含一条与相邻分类容易混淆的边界示例。
优先级/服务时限、状态与生效时间
优先级/服务时限填写该分类工单的默认优先级，以及约定的首次响应或解决时限，注明单位，如“P3，首次响应4工作小时”。状态填写“启用”“停用”或“草稿”，表示该分类当前是否可被选用。生效时间填写该记录开始适用的日期，状态变更时同步更新，便于回溯某一时点目录的实际口径。
必填与选填：哪些字段不能留空
必填字段决定一条分类记录能否被受理人正确使用；选填字段用于补充管理信息，可在分类运行一段时间后补齐。下表给出对照。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 分类标识 | 必填 | 系统与报表的稳定引用，缺失会导致统计无法归集 |
| 分类名称 | 必填 | 提交人与受理人选择分类的直接依据 |
| 层级 | 必填 | 决定目录结构与展示顺序 |
| 父级分类 | 必填 | 一级分类填“无”，其余必须指向已有分类 |
| 分类定义 | 必填 | 缺失时分类之间无法区分 |
| 受理边界 | 必填 | 减少误归类与反复转派 |
| 默认责任团队 | 必填 | 缺失时工单无法自动分派 |
| 典型示例 | 必填（至少一条） | 帮助提交人判断是否属于本类 |
| 优先级/服务时限 | 选填 | 分类上线初期可先沿用上级分类约定，稳定后补齐 |
| 状态 | 必填 | 控制分类是否可被选用 |
| 生效时间 | 必填 | 支持目录口径回溯 |
| 维护责任人 | 必填 | 明确谁对分类内容负责 |
新增分类时的最小必填集合为：分类标识、分类名称、层级、父级分类、分类定义、受理边界、默认责任团队、至少一条典型示例、状态、生效时间、维护责任人。优先级/服务时限可在分类上线后一个复核周期内，由维护责任人根据实际工单分布补齐；补齐前应在目录中注明“沿用上级约定”，避免受理人自行判断。
填写示例：一条完整的分类记录
以下示例演示一条二级分类记录各字段如何配合。示例中的组织名称与时限为演示取值，实际填写时替换为本组织的真实约定。
| 字段 | 填写内容 |
|---|---|
| 分类标识 | IT-NET-01 |
| 分类名称 | 办公网络故障 |
| 层级 | 二级 |
| 父级分类 | IT基础设施（IT-INF） |
| 分类定义 | 员工在办公场所使用有线或无线网络时遇到的连接、断网、网速异常等问题 |
| 受理边界 | 受理：办公区无线无法连接、有线网络频繁掉线、访问内部系统网速明显异常。不受理：家庭宽带问题、个人设备硬件故障、VPN账号权限申请（转“账号与权限”分类） |
| 默认责任团队 | IT网络运维组 |
| 典型示例 | 办公区无线网络无法连接；会议室有线网口无信号；访问内部系统页面加载缓慢 |
| 优先级/服务时限 | 默认P3；首次响应4工作小时，解决时限2工作日；整层断网按P2处理 |
| 状态 | 启用 |
| 生效时间 | 2025-03-01 |
| 维护责任人 | 网络运维组值班负责人 |
这条记录中，层级“二级”与父级“IT基础设施”相互对应；受理边界里“VPN账号权限申请转账号与权限分类”的写法，把容易混淆的情形明确指向相邻分类；典型示例三条均落在定义范围内，其中“访问内部系统页面加载缓慢”同时呼应了边界中的网速异常情形。责任团队填团队而非个人，维护责任人填岗位，人员轮换时无需改动分类记录。
调整与维护：分类目录怎么增、改、合并和下线
分类目录的价值在于长期保持可用。缺少维护规则时，常见结果是分类只增不减、名称各自演化、停用分类仍被旧入口引用。以下规则可作为目录维护的基本约定。
新增分类的触发条件与审批
出现以下情形时考虑新增分类：某类工单连续一个复核周期内数量占比明显上升，且现有分类的受理边界无法清晰覆盖；或某类工单频繁被转派，说明现有分类与责任团队不匹配。新增由维护责任人发起，填写完整必填字段，经默认责任团队负责人确认后生效。仅因个别工单不便归类而新增分类，通常应先补充现有分类的典型示例。
改名与合并的处理方式
分类改名只调整分类名称，分类标识保持不变，并在目录中记录变更日期。分类合并时，保留目标分类的标识与名称，将待合并分类的状态改为“停用”，并在其受理边界中注明“已并入某分类”，同时把待合并分类的典型示例迁入目标分类。合并前应确认两个分类的默认责任团队一致，否则先明确合并后的承接团队。
下线与停用的状态处理
分类不再使用时，将状态改为“停用”而非直接删除记录，保留标识、定义和历史生效时间，便于回溯历史工单的归类口径。停用分类应从提交入口的可选项中移除，避免新工单继续落入。停用满一个复核周期且无新增工单后，可在目录归档区集中存放。
定期复核的节奏与责任人
建议每个季度复核一次目录，由各分类的维护责任人核对定义、边界、示例与责任团队是否仍然准确，汇总变更后由目录总负责人统一发布。复核时重点看三类信号：长期零工单的分类、工单量集中度过高的分类、以及受理边界中频繁出现“转某分类”的分类，它们分别对应下线、拆分和边界重写的候选。
历史工单与分类变更的对应关系
分类改名、合并或停用后，历史工单保留其提交时的分类标识，统计时按标识归集，不随名称变化而改写。需要按新口径查看历史数据时，在目录中维护一张“旧标识—新标识”的对照记录，作为报表换算依据。这样既保证历史记录可追溯，也让新口径的统计有明确来源。
目录落地到工单系统时，分类字段与默认责任团队需要在系统中实际承载。ONES Desk 支持自定义工单属性与工单内容配置，可按收集场景设置字段；工单可关联到 ONES Project 的需求或缺陷工作项持续跟踪。分类层级、必填校验与生效时间等约束是否能在系统中配置，需结合所选版本的实际配置能力核验后再定稿目录字段。
常见问题
分类目录里已经有分类定义，为什么还要单独写受理边界？
分类定义回答“这个分类是什么”，受理边界回答“什么进、什么不进”。只写定义时，提交人和受理人容易按个人理解判断，遇到相邻分类就产生分歧。受理边界把应归入的典型情形和应转出的情形写清楚，例如“VPN账号权限申请转账号与权限分类”，判断依据就落到文字上，减少反复转派。
新分类刚上线，优先级和服务时限还没定，可以先留空吗？
可以先把该字段标为“沿用上级约定”，由维护责任人在一个复核周期内根据实际工单分布补齐。留空本身不是问题，问题在于受理人不知道按什么标准处理。补齐前应在目录中写明沿用的上级分类及其时限，避免每个受理人自行判断。
分类改名或合并后，历史工单的统计口径怎么处理？
历史工单保留提交时的分类标识，统计时按标识归集，不随名称变化改写。需要按新口径查看历史数据时，在目录中维护“旧标识—新标识”的对照记录，作为报表换算依据。这样历史记录可追溯，新口径统计也有明确来源。
分类目录应该多久复核一次，复核时重点看什么？
建议每季度复核一次，由各分类维护责任人核对定义、边界、示例与责任团队是否仍然准确。复核时重点看三类信号：长期零工单的分类、工单量集中度过高的分类、受理边界中频繁出现“转某分类”的分类，它们分别对应下线、拆分和边界重写的候选。
把分类目录落到工单系统时，需要提前确认哪些配置能力？
至少确认三点：系统能否承载分类字段及其层级关系，能否设置必填校验与默认值，能否按分类绑定默认责任团队。ONES Desk 支持自定义工单属性与工单内容配置，可按收集场景设置字段，工单可关联到 ONES Project 的需求或缺陷工作项持续跟踪；分类层级、必填校验与生效时间等约束能否配置，需结合所选版本的实际配置能力核验后再定稿目录字段。
