工单类型和分类目录解决的是两个不同问题：类型决定这张工单走哪条处理流程、由谁处理、必须填什么；分类目录决定它归在哪个业务位置，方便检索、归集和统计。实际设计时，先判断一项差异是否改变处理路径，会改变就落到类型上；只影响查找和汇总，就放到目录里。下面按同一口径对照两者，并给出划分规则和落地约定。
要点总览（TL;DR）
- 工单类型是流程入口，决定处理流程、必填字段和责任角色；分类目录是信息组织骨架，用于归集、检索和按维度统计。
- 判断标准：一项差异会改变工单“怎么走”就建类型，只改变工单“算哪一类”就建目录。
- 完整分类设计包含三层要素：类型管流程、字段记事实、分类层级管归属，混用会带来维护成本。
- 按类型汇总看流程效率，按目录汇总看业务分布，两类报表回答不同问题，可用类型作行、目录作列交叉统计。
- 小团队类型精简、目录浅层；多业务线用类型区分流程、目录承载归属，先试点再扩展，变更代价更可控。
工单类型与分类目录的核心区别
工单类型是流程入口。用户提交工单时选定类型，系统据此确定处理流程、必填字段和责任角色。例如“故障报修”和“账号权限申请”需要不同的审批环节、不同的必填信息和不同的处理团队，它们就应当是不同的类型。类型的变化会直接改变工单的处理路径。
分类目录是信息组织骨架。它回答的是“这类工单在业务上归在哪里”，用于归集同类工单、支持检索和按维度统计。目录调整通常不改变工单怎么流转，只影响工单被归入哪个统计口径、能否被快速找到。
把两者放在同一组维度下对照，差异会更清楚：
| 对照维度 | 工单类型 | 分类目录 |
|---|---|---|
| 控制对象 | 处理流程、必填字段、责任角色 | 信息归属、检索路径、统计维度 |
| 是否影响处理流程 | 影响，类型是流程分支的入口 | 不影响，流程在类型确定后已固定 |
| 是否支持多级 | 通常为平铺的有限集合，按流程区分 | 通常支持多级层级，按业务结构组织 |
| 变更影响范围 | 新增或调整类型会牵动流程配置、字段配置和角色分工 | 新增或调整目录主要影响统计口径和历史数据的归类 |
| 典型使用场景 | 区分报修、咨询、投诉、权限申请等处理方式不同的工单 | 区分产品线、业务区域、客户群体等归属维度 |
一句话判断标准：一项差异如果会改变工单“怎么走”，就建类型；如果只改变工单“算哪一类”，就建目录。这条标准在后续所有设计决策中都可以复用。
工单分类设计的三层要素：类型、分类层级与字段
完整的工单分类设计由三层要素构成：类型是流程入口，字段是信息载体，分类层级是组织骨架。三者各司其职，混用会带来后续维护成本。
类型承担流程入口职责
类型决定工单进入哪条处理流程，也决定这条流程上有哪些环节、由哪些角色处理。类型数量应当受控，每新增一个类型，都意味着一条流程分支和一套角色分工需要被定义和维护。
字段按类型绑定必填与可见性
字段记录工单的事实信息，例如提交人、影响范围、期望完成时间。字段与类型的绑定关系体现在：不同必填要求挂在不同类型上。故障报修类型可以要求填写影响系统，咨询类型则不必。这样字段配置跟着流程走，用户只看到当前类型真正需要的信息。
分类层级承担组织与筛选职责
分类层级用于把工单归入业务结构，支持按层级筛选和汇总。目录本身不承载流程判断，它承载的是归属关系。字段记录单张工单的事实，目录把这些事实按业务位置聚合起来，两者配合才能形成可用的统计。
常见错误有两类。一类是把流程分支塞进目录层级，例如用“需要审批的报修”“无需审批的报修”作为目录节点，结果流程逻辑藏在目录里，难以维护。另一类是把统计维度做成类型，例如为每个产品线各建一个类型，导致类型数量膨胀、流程重复配置。判断方法仍是那条标准：影响流程的进类型，影响查找统计的进目录。
什么情况该建类型，什么情况该建目录
划分规则可以从三个信号入手，每个信号对应一个明确的设计动作。
应建类型的信号
- 处理流程不同：一类工单需要审批、另一类直接受理，流程路径不一致。
- 责任团队不同：工单需要流转到不同团队处理，交接对象不同。
- 必填信息不同：受理前必须收集的信息集合存在明显差异。
三个信号中任意一个成立，就应考虑建立独立类型。若只是业务归属不同而流程一致，建类型会造成流程重复配置。
应建目录的信号
- 流程相同但业务归属不同：同一套处理流程下，工单分属不同产品线、区域或客户群体。
- 需要按维度统计：管理上要按某个维度汇总工单量、处理时长或积压情况。
这类差异不影响工单怎么处理，只影响它被归到哪里，适合用目录层级表达。
组合使用的典型结构
实践中常见的结构是“类型定流程，目录定归属”：先按处理方式划分少量类型，再在每个类型下挂一套分类层级，用于标注业务归属。例如类型设为“故障报修”“咨询建议”“权限申请”，目录则按产品线或业务区域组织，两类信息同时记录在一张工单上。
变更代价的比较
新增类型的代价在于流程配置：需要定义环节、角色和字段必填规则，还要考虑与现有类型的边界是否清晰。新增目录的代价在于统计口径：历史工单是否需要重新归类、报表口径是否随之变化。设计时把变更代价纳入考虑，可以避免为了短期方便而频繁改动类型。
落地时的字段与统计口径约定
概念区分落到执行层面，主要体现为字段命名、统计口径和维护责任三项约定。约定清楚，后续数据才不容易混乱。
字段命名与取值约定
类型字段和目录字段应使用不同的命名前缀，避免在报表和筛选器中混淆。类型字段的取值应是有限的枚举集合，与流程配置一一对应；目录字段的取值应遵循层级结构，同一层级内的命名保持统一。字段说明中注明该字段影响流程还是仅用于归集，方便后续维护者判断。
统计报表的汇总依据
按类型汇总适合观察流程运行情况，例如各类型的受理量、平均处理时长、超时比例，反映的是流程效率。按目录汇总适合观察业务分布，例如各产品线或区域的工单占比、问题集中度，反映的是业务归属。两类报表回答不同问题，不应互相替代。需要同时观察时，可以用类型作为行、目录作为列做交叉统计。
历史数据的口径一致性
调整类型或目录时，需要明确历史工单是否回溯归类。新增目录节点通常只需对新工单生效，历史数据保持原归类并在报表中注明口径变化时间；调整类型则涉及流程变更，历史工单一般保留原流程记录，不强行迁移到新流程。口径变化应有书面记录，避免前后报表无法对比。
维护责任划分
类型的新增与调整应由流程负责人审批，因为它改变处理路径和角色分工；目录的维护可以交给业务运营角色，按业务结构变化及时增补节点。两类变更都建议保留变更记录，定期评审类型数量是否膨胀、目录层级是否过深。
在工具层面，ONES Desk 支持自定义工单属性与工单内容配置，可适配不同的收集场景，并提供可灵活调整的工作流；企业版通过统一门户集中接收工单，支持自定义处理流程与字段配置，并提供多维度数据统计与分析。这些能力可以承载上述字段约定与统计动作，具体到类型对象与目录层级的配置方式，需以实际产品配置为准。
适配场景与选择建议
不同团队规模和业务结构下，类型与目录的组合方式可以不同。以下建议按场景给出，供设计时参考。
单业务线小团队：类型精简、目录浅层
业务线单一、处理角色集中时，类型保持在三到五个即可，覆盖流程真正不同的工单；目录保持一到两层，够用就好。此时过度细分类型会增加配置负担，过深目录则少有人维护。
多业务线或对外服务：类型区分流程，目录承载归属
存在多个业务线或面向外部用户提供服务时，类型用于区分处理方式差异明显的工单，目录用于标注产品线、区域或客户群体。对外服务场景下，提交表单的字段应按类型配置，让用户只填写当前类型需要的信息；目录信息可以由系统按入口或用户属性自动带入，减少填写负担。
跨部门统计：控制目录层级深度
需要跨部门汇总时，目录层级过深会导致统计口径难以对齐。建议把统计真正依赖的维度控制在两到三层，更细的区分交给字段记录。层级越浅，汇总规则越容易统一，报表也越容易被理解。
先试点再扩展
类型与目录的划分不必一次定全。可以先选一条业务线试点，运行一段时间后观察两个信号：是否有工单因为流程不同而被错误归入同一类型，是否有统计需求无法通过现有目录满足。前者提示需要拆分类型，后者提示需要补充目录节点。试点稳定后再向其他业务线推广，变更代价更可控。
常见问题
工单类型和分类目录可以只保留一个吗？
可以只保留一个，但需要接受相应的代价。只保留类型时，业务归属信息只能靠字段记录，跨产品线、区域的汇总需要依赖字段取值，报表口径调整不如目录层级直观。只保留目录时，流程差异无处表达，不同处理路径的工单会挤在同一套流程里，审批环节和必填信息只能靠人工判断。
如果当前业务只有一条处理流程、统计需求也简单，先只建类型、用少量字段记录归属，是可行的起步方式；等出现按业务维度汇总的需求，再补充目录层级。
分类目录的层级一般做几层比较合适？
建议把统计真正依赖的维度控制在两到三层。层级越深，跨部门汇总时口径越难对齐，报表也越难被理解。更细的区分可以交给字段记录，例如在同一目录节点下用字段标注具体模块或问题类型。
如果确实存在多层业务结构，可以先按最常用的统计维度建两层，观察一段时间后再决定是否加深。加深层级前，先确认现有报表是否真的需要按更深层级拆分。
新增工单类型时，历史工单需要跟着迁移吗？
通常不需要。新增类型意味着新的流程分支，历史工单保留原流程记录更利于追溯当时的处理过程。强行迁移会让历史记录与当时的审批环节、处理人脱节。
需要做的是在报表中注明口径变化的时间点，让前后数据可以分段对比。如果历史工单也需要按新类型统计，可以在报表层做映射，而不改动原始记录。
类型和目录的维护应该由谁负责？
建议分开授权。类型的新增与调整改变处理路径和角色分工，应由流程负责人审批，并评估对现有流程配置的影响；目录的维护可以交给业务运营角色，按业务结构变化及时增补节点。
两类变更都建议保留变更记录，并定期评审：类型数量是否膨胀、目录层级是否过深、是否存在流程分支藏在目录里的情况。
对外服务场景下，目录信息让用户填写还是系统带入？
优先由系统带入。对外提交表单时，用户只应填写当前类型真正需要的信息，目录归属可以由提交入口、用户属性或服务协议自动带入，减少填写负担和误选。
如果确实需要用户选择，例如让客户选择问题所属的产品，可以把选择项控制在浅层目录，深层归属由后台按规则补全。
