工单类型、分类层级和字段分别回答三个不同问题：这是哪一类服务请求、它落在服务目录的哪个位置、这张工单需要记录哪些信息。三者分工明确——类型定流程，层级定归属，字段定信息，再通过类型绑定字段方案、层级限定可选范围组合成稳定的数据结构。本文面向设计或梳理工单表单与流转规则的管理者，说明三者的定义、边界与组合方式。
要点总览（TL;DR）
- 工单类型回答“这是哪一类服务请求”，决定流程走向、处理角色与时限；分类层级回答“它落在服务目录的哪个位置”，用于统计、检索与归口；字段回答“需要记录哪些信息”，承载描述、判定与处理依据。
- 三者是分工关系：类型定流程，层级定归属，字段定信息。组合方式是类型绑定字段方案、类型限定可选分类范围、字段按类型和层级状态决定出现与必填。
- 边界要划清：类型不独自承担统计口径，层级不直接决定审批流转，字段不替代类型做流程分支。用字段值代替类型、用层级深度表达流程复杂度，都是常见越界做法。
- 分类层级与标签、优先级、状态是不同维度：层级是唯一归属的树，标签是多对多补充标记，优先级表达紧急程度，状态表达处理阶段，后三者不替代归口统计。
- 新增或合并类型时需同步字段方案、层级挂载点和流程分支；层级深度按服务目录实际粒度确定，字段按处理判定真正需要的信息设置，避免为对称加深层级、为求全堆字段。
工单类型、分类层级和字段各指什么
要讨论三者关系，先要把三个概念放在同一套语言里。它们都是工单数据结构中的组成部分，但承担的职责不同，回答的问题也不同。
工单类型：这是哪一类服务请求
工单类型是按服务请求性质划分的类别，例如账号权限申请、设备故障报修、软件使用咨询、数据导出申请。类型的作用是决定流程走向与责任归属：不同类型的请求往往需要不同的处理角色、审批环节和响应时限。提交人选择类型，相当于声明“我需要的是哪一类服务”，系统据此把工单送入对应的处理路径。
分类层级：它落在服务目录的哪个位置
分类层级是服务目录式的树状结构，从大类到子类逐层细化。例如“IT 服务”下分“办公设备”“网络与通信”“账号与权限”，其中“办公设备”再分“打印机”“笔记本”“外设”。层级回答的是归属问题：这张工单属于服务目录中的哪个节点。它的主要用途是统计、检索与归口，让管理者能按服务条线汇总工单量、发现高频问题、明确由哪个团队负责。
字段：这张工单需要记录哪些信息
字段是工单上承载信息的表单项，例如标题、描述、申请人部门、设备编号、期望完成时间、影响范围。字段通常分为两类：通用字段是所有工单都要填的基础信息，类型专属字段只在特定类型下出现，用于采集该类请求判定与处理所必需的信息。字段回答的是“需要记录什么”，它承载描述、判定依据和处理过程中需要回填的结果。
| 对象 | 回答的问题 | 主要作用 | 典型示例 |
|---|---|---|---|
| 工单类型 | 这是哪一类服务请求 | 决定流程、处理角色与时限 | 账号权限申请、设备报修 |
| 分类层级 | 归到服务目录的哪个位置 | 统计、检索与归口 | IT 服务 / 办公设备 / 打印机 |
| 字段 | 需要记录哪些信息 | 承载描述、判定与处理依据 | 设备编号、影响范围、期望时间 |
三者的边界：各自管什么、不管什么
三者容易混用的原因，是它们都出现在同一张表单上，看起来都是“给工单分类或填信息”。划清边界的关键，是看每个对象主要影响哪一类后续动作。
工单类型管流程与责任，不承担统计口径的全部职责
类型直接关联流程分支、处理角色和时限规则，是流转的开关。它不适合独自承担统计口径：同一类型下可能包含多个服务条线的请求，仅按类型汇总会丢失归口信息。统计需要类型与层级配合，类型给出请求性质，层级给出服务目录位置。
分类层级管归属与检索，不直接决定审批与流转
层级描述的是“这项服务在目录中的位置”，它帮助派单到对应团队、支持按条线统计，但审批要不要走、走几级、由谁处理，应由类型及其绑定的流程决定。把层级节点当作流程开关，会导致目录调整时流程被动变化，维护成本上升。
字段管信息采集，不替代类型做流程分支
字段记录的是事实与依据，例如设备编号、故障现象、影响人数。用某个字段的取值去决定走哪条审批路径，短期可行，长期会让流程规则散落在表单里，难以审计和复用。流程分支应回到类型层面表达。
常见的越界做法有三类：用字段值代替类型做流程判断；用层级深度表达流程复杂度，认为层级越深流程越完整；把类型当成统计维度，忽略服务目录归口。本文讨论范围限于服务数据规范，缺陷报告规范与平台跨对象字段治理不在本文展开。
三者如何组合：类型定流程、层级定归属、字段定信息
三者不是并列堆在表单上，而是通过绑定关系组合成一套结构。组合的核心是：类型作为入口，决定带出哪些字段、限定哪些层级；层级作为归口维度，支撑统计与派单；字段作为信息载体，随类型和层级状态出现。
类型与字段的绑定
通用字段所有类型共用，例如申请人、部门、联系方式、期望完成时间。类型专属字段按类型追加：设备报修类型带出设备编号、故障现象、是否影响多人；账号权限申请类型带出目标系统、权限角色、授权期限。绑定关系让提交人只看到与当前请求相关的表单项，减少无效填写。
类型与层级的关联
类型可以限定可选分类范围，例如“设备报修”类型只允许在“办公设备”子树下选择，避免提交人把报修工单挂到“账号与权限”节点。反过来，层级节点也可以反查适用类型，帮助管理员检查某个服务节点下有哪些类型在挂载，发现遗漏或重复。
层级深度按服务目录实际粒度确定
层级层数应由服务目录的真实粒度决定。服务条线清晰、请求差异大的组织，可能需要三到四层；服务种类有限的小团队，两层足够。为追求结构对称而强行加深层级，会让提交人难以判断该选哪一层，也会让统计口径变得零碎。
字段的必填与条件显示
字段是否出现、是否必填，应结合类型和层级状态设定。例如“设备编号”在设备报修类型下必填，在咨询类工单中隐藏；“影响范围”在故障类请求中必填，在权限申请中不出现。条件显示的依据是处理人做判定时真正需要的信息，字段越多并不等于信息越全。
变更时的联动
新增一个类型时，需要同步完成三件事：为该类型配置专属字段方案，确定它在服务目录中的挂载位置与可选层级范围，检查流程分支与处理角色是否已就绪。删除或合并类型时，同样要检查历史工单的统计口径是否受影响，避免报表出现断档。
和相邻概念的区别：分类层级与标签、优先级、状态
分类体系容易被其他维度挤占，常见情形是把标签、优先级、状态当成分类使用。区分它们的关键，是看每个维度是否承担唯一归属。
| 概念 | 表达什么 | 与分类层级的关系 | 使用建议 |
|---|---|---|---|
| 分类层级 | 服务目录中的唯一归属 | 本身即归属维度 | 一张工单落在一个叶子节点 |
| 标签 | 多对多的补充标记 | 补充而非替代层级 | 用于跨条线的临时主题，如“季度活动支持” |
| 优先级 | 紧急程度 | 与归属维度正交 | 不用于统计服务条线分布 |
| 状态 | 处理阶段 | 与归属维度正交 | 表达待受理、处理中、已关闭等阶段 |
分类层级与标签的区别在于归属的唯一性：层级要求一张工单落在服务目录的一个节点上，标签可以打多个，用于补充跨条线的观察视角。分类层级与优先级的区别在于表达对象：优先级表达多急，不表达属于哪项服务。分类层级与状态的区别在于维度方向：状态描述处理进行到哪一步，与归属维度互不替代。
字段与分类的取舍原则是：能用固定选项表达归属时优先用层级，自由文本留给描述性信息。例如“所属系统”如果是有限枚举，适合做成层级或固定选项字段；故障现象的细节描述则适合自由文本。
一个具体例子：三类对象如何在一张工单上落地
以下为演示情景，用于说明三者如何在一张工单上协同，不指向真实客户案例。
某员工发现办公室打印机无法连接，通过服务门户提交工单。提交时，他先选择类型“设备报修”，系统随即带出该类型的专属字段：设备编号、故障现象、是否影响多人、期望完成时间。随后他在分类层级中选择“IT 服务 / 办公设备 / 打印机”，完成归口。提交后，工单按“设备报修”类型绑定的流程进入桌面支持组，状态从“待受理”推进到“处理中”。处理人依据设备编号定位设备，依据“是否影响多人”判断是否需要升级处理。工单关闭后，统计报表按分类层级汇总办公设备条线的报修量，按类型观察报修在各类请求中的占比。
这个例子对应三条常见误解的纠正。其一，层级越深越专业：本例中“打印机”已是足够细的叶子节点，再往下分品牌或楼层，会让提交人难以选择，统计也未必更有用。其二，字段越多信息越全：本例只保留判定和处理真正需要的字段，咨询类工单不会出现设备编号。其三，类型可以随意新增：每新增一个类型，都要同步字段方案、层级挂载点和流程分支，否则会出现选了类型却带不出对应字段、或工单无处归口的情况。
在协作工具中承载这套分类结构
当类型、层级和字段的关系确定后，需要一套配置机制把它们稳定承载下来，让提交、处理、统计三个环节使用同一套结构。
提交环节，提交人选择工单类型与服务目录节点，系统带出该类型对应的字段方案，专属字段按需出现。处理环节，处理人依据字段中的设备编号、影响范围等信息做判定，工单状态随流程推进而变化，流转路径由类型绑定的工作流决定。配置环节，管理员统一维护类型清单、层级树和字段方案，类型新增或层级调整时按联动清单评审变更，确认字段、挂载点和流程同步到位。
ONES Desk 提供自定义工单属性与工单内容配置，可适配不同的收集场景，并支持灵活调整工作流以适应不同工作方式；企业版通过统一门户集中接收工单，支持自定义处理流程与字段配置，并提供多维度数据统计与分析。将这些能力用于上述结构时，类型与字段方案的对应、层级树的维护和流程分支的设置仍需按组织自身的服务目录来设计，工具承载的是配置与流转动作，分类口径本身由管理规则决定。这样落地后，工单的数据结构保持稳定，统计口径与派单规则可以追溯到具体的类型、层级和字段配置。
常见问题
小团队服务种类不多，是否也需要建立多层级分类？
层数应由服务目录的真实粒度决定。服务种类有限、请求差异不大的团队，两层通常足够，例如“办公支持 / 设备报修”。层级的作用是归口与检索，只要每个叶子节点能对应到明确的负责团队和统计口径，就不必为了结构对称继续往下分。层级过深会让提交人难以判断该选哪一层，统计口径也会变得零碎。
工单类型和分类层级能否合并成一个维度，减少提交人的选择负担？
两者可以设计得相互对应，但职责不同，合并后容易丢失信息。类型决定流程分支、处理角色和时限，层级决定服务目录归口和统计口径。如果只保留类型，跨条线的统计会缺少归口维度；如果只保留层级，流程分支就要挂到目录节点上，目录一调整流程就跟着变。较稳妥的做法是让类型限定可选层级范围，提交人先选类型、再在限定范围内选节点，选择负担可控，两个维度也都保留。
字段的必填和条件显示应该由谁定，按什么标准定？
字段规则应由负责该类服务的处理团队提出、管理员统一维护。判断标准是处理人做判定和回填时真正需要的信息：设备编号在设备报修类型下必填，在咨询类工单中隐藏；影响范围在故障类请求中必填，在权限申请中不出现。字段越多并不等于信息越全，无关字段会增加提交成本，也会稀释关键信息的可见度。规则变更时建议同步检查历史工单的统计口径是否受影响。
已有工单数据在调整分类层级后，统计报表怎么保持可比？
调整前先梳理受影响的节点和类型，明确哪些历史工单需要重新归口、哪些保留原节点。常见做法是保留旧节点并标记停用，新增节点承接后续工单，报表按新旧节点的映射关系合并统计；合并类型时同样要检查历史工单的字段数据是否仍能支撑原有分析。变更后的一段时间内，建议同时观察新旧口径的差异，确认报表断档风险已消除再停用旧结构。
在协作工具中落地这套结构时，配置工作主要有哪些？
配置工作集中在三处：类型清单及其绑定的字段方案与流程分支，服务目录层级树及每个类型允许选择的节点范围，字段的出现条件与必填规则。ONES Desk 提供自定义工单属性与工单内容配置，可适配不同的收集场景，并支持灵活调整工作流以适应不同工作方式；企业版通过统一门户集中接收工单，支持自定义处理流程与字段配置，并提供多维度数据统计与分析。类型与字段方案的对应、层级树的维护仍需按组织自身的服务目录来设计。
