工单类型体系可以按“处理路径”划分一级类型，再用“对象+动作”命名，最后用字段和准入规则把清单固化下来。这样划分的依据是受理后走哪条流程、由谁处理、需要哪些信息，而不是按部门或提交人情绪分类。本文给出一套可执行的划分规则、命名词表、类型清单字段与上线检查项，适合正在建立或重整工单分类的服务台、IT支持和内部支持团队参照。
要点总览（TL;DR）
- 一级类型按处理路径划分：受理后走同一条流程、由同一类角色承接、需要同一组信息的工单归为一类，部门、情绪和渠道不进入类型层级。
- 命名采用“对象+动作”两段式，同一层级统一词性与粒度，长度控制在2–6字，新增类型必须从动作词表和对象词表取词。
- 类型清单以表格维护，每个类型写明定义、典型示例、必填字段、受理角色、升级路径和状态，新增需审批，停用保留历史原值。
- 服务台负责人做划分与命名决策，一线受理人按清单选择并反馈不适配，流程运营角色负责清单维护与季度复核。
- 上线前逐项核对互斥性、覆盖完整性、命名合规、字段与角色齐备、历史映射和系统配置一致性。
划分工单类型的判断依据
一级类型的划分标准是处理路径：一张工单从受理、处理到交付或关闭，走的是同一条流程、由同一类角色承接、需要同一组信息，就归为同一类型。处理路径不同的工单，即使提交人来自同一部门，也应分到不同类型。这条标准的好处是类型直接对应后续动作，受理人选中类型后就知道该转给谁、该向提交人要什么。
二级细分按责任团队和所需信息的差异展开。一级类型确定流程大类后，如果同一大类下不同工单由不同团队处理，或受理时必须收集的字段明显不同，就拆成二级类型。例如“设备”下，办公电脑报修由IT桌面支持处理，需要设备编号和故障现象；门禁设备报修由行政或安保团队处理，需要位置和门禁点编号。两者处理人和必填信息都不同，值得分开。
以下做法不适合作为划分依据：按提交部门命名类型，会让同一处理路径的工单散落在多个类型里；按提交人情绪或紧急程度划分，情绪无法稳定判断，紧急程度应作为优先级字段而非类型；按提交渠道划分，电话、邮件、门户只是入口，同一诉求从不同渠道进来仍应归入同一类型。渠道和优先级可以作为独立字段保留，不占用类型层级。
对现有工单做一次聚类，可以按以下步骤操作：
- 收集近3–6个月的工单样本，数量以能覆盖主要业务为原则，样本量少的团队可拉长到12个月。
- 逐条标注每张工单的处理路径：受理角色、处理团队、关键处理动作、交付物或关闭条件。
- 把处理路径相同的工单聚为一组，统计每组工单量和涉及团队。
- 为每组写出一个候选类型名，记录该组共有的必填信息。
- 检查候选类型之间是否有重叠，重叠的合并，样本过少的先归入相近类型并标注观察。
完成标志是：每张样本工单都能归入唯一一个候选类型，且每个候选类型都能说清受理角色和必填字段。做不到唯一归类的，说明划分粒度还需要调整。
工单类型的命名规则与词表
类型名称采用两段式结构：对象加动作或诉求。对象说明工单涉及什么，动作或诉求说明提交人希望发生什么。例如“账号-权限申请”“设备-故障报修”“网络-访问开通”。两段式让受理人一眼判断归属，也让名称在列表中保持可读。
同一层级保持统一词性和统一粒度。一级类型用名词性对象词，如“账号”“设备”“网络”“软件”；二级类型用“对象+动作”的完整结构。长度控制在2–6个字，超过6个字通常说明把多个诉求塞进了一个名称，应拆分或简化。同一层级不混用“申请”“报修”“咨询”之外的动词，避免“处理”“解决”“支持”这类含义模糊的词进入名称。
受控词表是命名可扩展的关键。维护两份词表：动作词表和对象词表。新增类型必须从词表取词，词表里没有的词，先提交词表增补，再建类型。这样可以避免“权限申请”和“权限开通”这类同义类型反复增生。
| 词表 | 可用词示例 | 使用说明 |
|---|---|---|
| 动作词 | 申请、开通、报修、变更、咨询、投诉、回收 | 表示提交人的诉求或期望动作，一个类型只用一个动作词 |
| 对象词 | 账号、权限、设备、软件、网络、会议室、门禁、邮箱 | 表示工单涉及的业务对象，优先使用提交人能理解的通用词 |
命名禁忌需要写进规范：“其他”“综合”“一般”“ miscellaneous”不作为正式类型，这类名称会让受理人无法判断，最终变成什么都往里放；内部缩写和项目代号不进类型名，提交人看不懂，新同事也无法维护；同一含义不保留两种写法，发现同义类型时合并并停用旧名。
类型清单的字段设计与维护机制
划分和命名的结果要固化到一张类型清单里，清单以表格维护，每个类型一行。字段设计如下：
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 类型ID | 稳定编号，如TP-001，停用后不复用 | 系统配置和历史统计的锚点 |
| 名称 | 按命名规则填写，2–6字 | 受理人选择时看到的内容 |
| 定义 | 一句话说明该类型覆盖什么、不覆盖什么 | 减少误选和争议 |
| 典型示例 | 2–3条真实工单描述 | 帮助一线判断边界 |
| 必填字段 | 受理时必须收集的信息项 | 保证处理所需信息完整 |
| 受理角色 | 首接团队或岗位 | 决定分派方向 |
| 升级路径 | 超时或无法处理时的转交对象 | 避免工单滞留 |
| 状态 | 启用、观察、停用 | 控制清单生命周期 |
新增类型需要满足准入条件：现有类型确实无法覆盖，且有近3个月的实际工单样本支撑；名称能从受控词表取词；必填字段和受理角色已明确。新增由服务台负责人审批，流程运营角色登记入清单并同步到工单系统。审批人不宜过多，一人决策、一人登记即可，避免流程拖长。
停用与合并规则同样要写清：连续两个季度工单量低于约定阈值、或与另一类型高度重叠的类型，进入合并评估；合并时保留新类型，旧类型状态改为停用，历史工单保留原类型不做批量改写，统计时通过映射表归并。这样既保持历史可追溯，又避免清单持续膨胀。
复核按季度进行，责任人为流程运营角色。复核内容包括各类型的使用频次、误选率、必填字段完整率和新增停用记录。复核输出一份清单变更记录，作为下一季度调整的依据。
清单落到工单系统时，类型对应工作项的类型字段，必填字段对应表单配置。ONES Desk 支持自定义工单属性和工单内容配置，可用于承载不同收集场景的字段；其工作流可按团队方式调整，工单还可关联到 ONES Project 的需求或缺陷工作项继续跟踪。具体字段类型、必填校验和按类型联动的配置范围，以实际环境中的产品能力为准。
角色分工与各环节交付物
类型体系无人维护，通常是因为责任没有落到具体角色。以下分工把划分、命名、录入和复核分配到人，每个角色都有明确输入和输出。
| 角色 | 输入 | 动作 | 交付物 |
|---|---|---|---|
| 服务台负责人 | 工单样本聚类结果、词表 | 决定一级与二级类型划分，审批新增和合并 | 类型划分决策、新增审批记录 |
| 一线受理人 | 类型清单、必填字段 | 按清单选择类型，记录无法归类或字段不适配的情况 | 类型选择记录、不适配反馈 |
| 流程/运营角色 | 审批结果、使用数据 | 维护清单、同步系统配置、季度复核 | 类型清单、变更记录、季度复核报告 |
| 处理团队负责人 | 本团队工单 | 确认受理角色和升级路径，反馈处理路径变化 | 受理角色与升级路径确认 |
交接点要明确：一线反馈的不适配情况由流程运营角色汇总，达到准入条件的提交服务台负责人审批；处理路径发生变化时，处理团队负责人提出，流程运营角色更新清单和系统配置。每个季度复核结束后，清单版本号更新并通知一线。
填写示例：一张完整的类型清单
以下是一份已填写的类型清单示例，覆盖账号、设备、软件、网络和咨询等常见场景，可参照调整后使用。
| 类型ID | 名称 | 定义 | 典型示例 | 必填字段 | 受理角色 |
|---|---|---|---|---|---|
| TP-001 | 账号-权限申请 | 为员工开通或调整业务系统账号与权限 | 新员工开通邮箱；申请财务系统查询权限 | 申请人、所属部门、目标系统、权限范围、生效时间 | IT服务台 |
| TP-002 | 账号-权限回收 | 员工离职或转岗时回收账号与权限 | 离职员工账号停用；转岗后移除原系统权限 | 员工姓名、工号、离职或转岗日期、需回收系统 | IT服务台 |
| TP-003 | 设备-故障报修 | 办公设备无法正常使用，需要维修或更换 | 笔记本无法开机；显示器花屏 | 设备编号、故障现象、发生时间、所在位置 | IT桌面支持 |
| TP-004 | 软件-安装申请 | 申请安装或升级办公软件 | 安装设计软件；升级办公套件版本 | 软件名称与版本、使用理由、设备编号 | IT桌面支持 |
| TP-005 | 网络-访问开通 | 开通网络访问权限或调整网络策略 | 开通外网访问；申请访客网络账号 | 申请人、访问目标、使用期限、设备信息 | 网络运维 |
| TP-006 | 网络-故障报修 | 网络连接异常，需要排查恢复 | 办公区无法上网；VPN连接失败 | 故障位置、影响范围、故障现象、联系方式 | 网络运维 |
| TP-007 | 咨询-使用咨询 | 对系统或流程使用方法提出询问，无需变更配置 | 如何提交报销；系统报表在哪里导出 | 咨询对象、问题描述 | 服务台一线 |
新增类型的完整记录示例如下：一线受理人反馈“会议室设备报修”长期归入“设备-故障报修”，但处理团队是行政而非IT，必填信息需要会议室编号。流程运营角色核对近3个月共18张相关工单，确认处理路径不同，提交新增申请。服务台负责人审批通过，从对象词表取“会议室”、动作词表取“报修”，命名为“会议室-报修”，类型ID为TP-008，状态设为观察。流程运营角色在系统中配置该类型及必填字段，通知一线启用，并在季度复核时评估使用情况。
上线前的完成检查
类型体系上线前，逐项核对以下检查项，全部通过再正式启用：
- 互斥性：任意一张工单只能归入一个类型，抽查样本中不存在同时符合两个类型定义的情况。
- 覆盖完整性：近3–6个月样本工单全部能映射到某个类型，没有大量工单落入“其他”。
- 命名合规：所有类型名称符合“对象+动作”结构，长度在2–6字，用词来自受控词表，无内部缩写。
- 字段与角色齐备：每个类型都填写了必填字段和受理角色，升级路径无空缺。
- 历史映射：历史工单能通过映射表对应到新类型，停用类型保留原值可追溯。
- 责任与节奏：维护责任人、审批人和季度复核时间已确定并通知相关团队。
- 系统配置一致：工单系统中的类型选项、必填字段与清单版本一致，试运行期间误选和字段缺失情况已记录。
检查中发现的问题按类型逐条修正，修正后更新清单版本号。上线后第一个季度重点观察误选率和字段完整率，用实际数据判断类型粒度是否需要微调。
常见问题
现有工单类型太多太乱，应该先合并还是先重新划分？
建议先做一次样本聚类，再决定合并还是重划。收集近3–6个月工单，逐条标注受理角色、处理团队和必填信息，把处理路径相同的工单聚为一组。如果聚类结果显示多数现有类型可以归入少数几条处理路径，就以聚类结果为基础重新划分一级类型，再把原类型作为二级类型或停用。如果聚类后大部分类型仍然对应不同处理路径，只是名称混乱，则优先做命名规范和同义合并，不必推翻层级。两种做法都建议保留旧类型到新类型的映射表，历史工单不改写原值。
类型名称里要不要体现优先级或紧急程度？
不建议。优先级和紧急程度应作为独立字段，与类型分开维护。类型回答的是“这张工单走哪条处理路径、由谁处理、需要哪些信息”，优先级回答的是“多快处理”。把紧急程度写进类型名称，会导致同一处理路径的工单被拆成多个类型，统计时无法合并，受理人也容易在“紧急报修”和“普通报修”之间误选。如果团队需要按紧急程度分流，可以在工单表单中设优先级字段，并在升级路径中约定不同优先级的响应时限。
一线受理人经常选错类型，清单应该怎么调整？
先记录误选的具体情况：是类型定义边界不清，还是名称太接近，还是必填字段让受理人回避某个类型。如果是定义边界问题，在清单的“定义”字段中补充“不覆盖什么”，并增加典型示例；如果是名称接近，检查是否违反受控词表，合并同义类型；如果是必填字段过多导致回避，评估哪些字段可以后置到处理环节收集。调整后更新清单版本号，并在季度复核中观察误选率是否下降。误选率持续偏高的类型，可以考虑拆分为两个粒度更细的类型。
小团队工单量少，也需要完整的类型清单和季度复核吗？
字段可以精简，机制可以简化，但类型清单和复核节奏仍建议保留。工单量少的团队可以把类型数量控制在5–8个，清单字段保留名称、定义、典型示例、必填字段和受理角色即可，升级路径可以合并到受理角色中说明。复核节奏可以从季度放宽到半年，但需要指定一名责任人，否则清单容易在人员变动后失效。样本量少时，聚类可以拉长到12个月，避免因样本不足把偶发工单误设为独立类型。
类型清单落到工单系统时，需要注意什么？
系统配置要与清单版本保持一致：类型选项的名称和顺序按清单设置，必填字段按类型配置，停用类型在系统中保留但不再对一线展示。上线前用一批历史工单做试运行，检查类型选项是否覆盖主要场景、必填字段是否可填、分派规则是否指向正确的受理角色。试运行期间记录误选和字段缺失情况，作为上线后第一次复核的输入。如果系统支持按类型联动不同表单字段，可以把清单中的必填字段差异直接配置进去；具体配置范围以实际环境中的产品能力为准。
