工单提报模板：按工单类型设计字段与必填项

按工单类型设计提报模板，核心是把字段分成公共字段和类型专属字段，再为每个字段标注必填级别与出现条件。这样既能保证受理、处理、统计各环节拿到需要的信息，也能避免提报人面对一长串无关字段。本文给出从类型划分到上线检查的完整做法，适用于服务台、内部支持等工单收集场景。

要点总览（TL;DR）

• 先列工单类型清单，按服务对象、处理路径、责任团队三项依据划分，再把字段拆成公共字段与类型专属字段，类型数量初期控制在五到八个。
• 字段按受理、处理、统计三类需求取用：受理要识别信息，处理要定位信息，统计要归类信息，能用选项收敛的不要留自由文本。
• 必填项分受理必需、处理必需、统计必需三档，逐档追问“缺这个字段该环节能否完成”，提报时只保留提报人确实掌握的必填项。
• 条件显示由工单类型、选项值、角色、状态触发，字段显示后通常同步设为必填，并为条件失效保留始终可见的兜底说明字段。
• 填写说明写判断口径加一个示例，优先覆盖被反复追问的易错字段，上线前用试填和检查清单确认可用。

先划分工单类型，再决定字段归属

字段设计的起点是工单类型清单。类型不清楚，字段就会混在一起，最后只能靠“全部必填”来兜底。划分类型时，先看三个依据：服务对象是谁、处理路径是否不同、责任团队是否不同。三者中任意一项存在明显差异，就值得单独设一个类型；三项都相同，通常可以合并。

类型清单的来源可以从历史工单中归纳。抽取近三到六个月的工单，按“谁提的、谁来处理、走了哪些环节”做归类，出现频次高且处理方式稳定的归为一类。新业务尚未积累数据时，由服务负责人牵头，联合一线受理人和主要处理团队共同拟定初稿。

类型确定后，把字段拆成两层。公共字段是所有类型都要填写的信息，例如提报人、提报时间、联系方式、问题描述。专属字段只在特定类型下出现，例如“设备报修”需要设备编号和所在位置，“账号权限申请”需要系统名称和权限范围。拆分原则是：公共字段回答“谁在什么时候提了什么”，专属字段回答“这类工单处理时必须知道什么”。

类型数量需要控制。建议初期控制在五到八个，超过十个时检查是否存在仅责任团队不同、处理路径几乎一致的类型，这类可以合并为一个类型加一个“责任团队”字段。类型过多会带来维护成本，每新增一个类型都意味着字段、必填和说明的同步调整。

工单类型	划分依据	公共字段	专属字段
设备报修	责任团队为运维，处理路径含现场环节	提报人、时间、描述	设备编号、位置、故障现象
账号权限申请	责任团队为系统管理员，需审批	提报人、时间、描述	系统名称、权限范围、使用期限
业务咨询	处理路径为答复，无需现场	提报人、时间、描述	咨询主题、期望答复时间

字段设计：从受理、处理、统计三类需求取字段

每个字段都应当能回答“谁在什么环节用它”。按用途分三类取字段，可以避免凭感觉堆砌。

受理环节需要识别信息，用于判断工单归属和紧急程度。常见字段包括提报人及联系方式、提报时间、工单类型、影响范围、紧急程度。这类字段的特点是受理人看一眼就能决定分给谁、排在第几位。

处理环节需要定位信息，用于处理人复现问题和执行操作。常见字段包括具体对象（设备、系统、订单号）、发生位置、故障或需求的具体表现、已尝试的处理动作、期望完成时间。这类字段由处理人使用，缺失会直接导致来回追问。

统计与复盘需要归类信息，用于后续分析趋势和分配资源。常见字段包括问题分类、来源渠道、影响业务线、解决方式。这类字段对单张工单的处理帮助有限，但对周期性复盘不可缺少，因此适合放在处理过程中补充，而非提报时强制填写。

字段形式要与取值方式匹配。可选值有限且互斥的用单选，例如紧急程度；可多选的用多选，例如影响业务线；需要自由描述的用文本，例如问题描述；时间点用日期字段，便于排序和统计。文本字段尽量少而精，能用选项收敛的不要留给自由输入，否则统计时无法归类。

用途	典型字段	建议形式	使用环节
识别	提报人、工单类型、紧急程度	人员选择、单选	受理
定位	设备编号、系统名称、问题描述	文本、单选、多行文本	处理
归类	问题分类、来源渠道、解决方式	单选、多选	统计与复盘

必填项怎么定：三档必填与判定依据

必填项按三档确定：受理必需、处理必需、统计必需。判定方法是逐档追问一句：“缺这个字段，这个环节还能不能完成？”

受理必需指缺失就无法分派或无法联系提报人的字段，例如提报人、联系方式、工单类型、问题描述。这一档在提报时即设为必填。

处理必需指缺失会导致处理人无法开展工作的字段，例如设备编号、系统名称、发生位置。这一档同样在提报时必填，但如果提报人确实无法提供，可以改为“提报时选填、进入处理环节后由处理人补填并转为必填”。

统计必需指缺失不影响单张工单处理、但影响复盘的字段，例如问题分类、解决方式。这一档适合放在处理完成前必填，由处理人填写，不增加提报人的负担。

档位	判定问题	填写时机	示例字段
受理必需	缺了能否分派或联系提报人	提报时	提报人、工单类型、问题描述
处理必需	缺了处理人能否开展工作	提报时或处理开始时	设备编号、系统名称、发生位置
统计必需	缺了是否影响复盘归类	处理完成前	问题分类、解决方式

必填过多会直接导致提报放弃或随意填写。控制方法是：提报页面的必填项尽量只保留受理必需和处理必需中提报人确实掌握的部分；提报人不掌握的信息，改为选填加后续补填。每增加一个必填项，都问一次“提报人此刻是否一定知道这个答案”，答案是否定的就不放在提报时必填。

必填项随工单状态推进而变化，是常见的处理方式。提报阶段只校验受理必需；工单进入处理中，系统或流程要求处理必需字段补齐；关闭前校验统计必需字段。这样每个角色只在自己负责的环节承担填写责任，避免把全部压力压给提报人。

条件显示：让字段在正确时机出现

条件显示解决的是“字段什么时候出现”。触发条件通常来自四类来源：工单类型、某个选项的取值、当前角色、工单状态。

按类型触发是最基础的方式，选择“设备报修”后显示设备编号和位置，选择“账号权限申请”后显示系统名称和权限范围。按选项值触发用于类型内部的细分，例如紧急程度选择“高”后，追加显示“影响范围”和“期望恢复时间”。按角色触发用于处理侧字段，例如处理人打开工单后才显示“处理方案”和“解决方式”。按状态触发用于流程推进，例如工单进入“待关闭”状态时显示“满意度”或“关闭原因”。

条件字段与必填需要联动设计。字段被条件显示出来后，通常应同时设为必填，否则会出现“显示了但可以不填”的空档。规则可以写成：字段A取值为X时，字段B显示且必填；字段A取其他值时，字段B隐藏且不校验。多条条件之间要检查是否互斥，避免同一字段被两条规则同时要求显示和隐藏。

条件显示失效时需要兜底。常见失效情形包括：提报人通过旧链接或历史模板进入、条件依赖的字段被清空、规则配置遗漏了某个取值。兜底做法是保留一个“其他说明”文本字段始终可见，并在模板评审时用穷举法检查每个条件字段的所有取值分支是否都有明确结果。上线后定期抽查工单，确认没有出现该显示而未显示、或显示了无关字段的情况。

触发来源	示例规则	联动必填
工单类型	类型为设备报修时显示设备编号	显示即必填
选项值	紧急程度为高时显示期望恢复时间	显示即必填
角色	处理人查看时显示处理方案	关闭前必填
状态	进入待关闭时显示关闭原因	显示即必填

填写说明怎么写：给提报人一句可执行的话

字段标签说明“这是什么”，填写说明说明“怎么填”。两者分工明确，标签尽量短，说明补充判断口径和示例。

说明文字应包含两部分：判断口径和示例。判断口径告诉提报人在几种情况中如何选择，例如“设备编号指机身标签上的八位数字，不含房间号”；示例给出一个可直接对照的写法，例如“如：A栋302会议室投影仪，编号 EQ-2024-0317”。

易错字段优先配说明。判断哪些字段易错，可以看历史工单中的追问记录和退回原因，被反复追问的字段就是说明的重点对象。常见易错字段包括位置描述、问题分类、影响范围、权限范围。说明文字控制在一到两句，放在字段下方或输入框提示中，避免写成段落。

说明写完后做一次可读性检查：让一位不熟悉该业务的同事只看标签和说明填写一次，如果仍需询问，说明口径还不够具体。说明中避免使用“相关”“适当”“视情况”这类无法执行的词。

角色分工与交付物

模板设计涉及三类角色，各自承担不同职责，交接节点清晰可以减少反复修改。

服务负责人负责工单类型清单的最终确认和字段归属表的审定，对“哪些类型保留、哪些合并”做决策。交付物是类型清单和字段归属表。

一线受理人负责提供受理环节的实际需求，确认受理必需字段，并参与试填。交付物是受理字段清单和试填反馈。

数据统计方负责提出统计与复盘所需的归类字段，确认字段取值能否支撑报表。交付物是统计字段清单和取值口径说明。

处理团队代表负责确认处理必需字段和条件显示规则，确保处理人拿到足够信息。交付物是处理字段清单和条件规则清单。

模板变更需要审批和版本记录。建议由服务负责人审批字段增删和必填调整，每次变更记录变更内容、原因、生效时间和影响范围。版本记录与模板本身放在一起，便于回溯某次调整前后的差异。

角色	主要职责	交付物	交接节点
服务负责人	类型确认、字段归属审定、变更审批	类型清单、字段归属表	设计启动与上线前
一线受理人	受理需求、试填反馈	受理字段清单、试填记录	字段设计阶段
数据统计方	统计字段与取值口径	统计字段清单	字段设计阶段
处理团队代表	处理字段与条件规则确认	处理字段清单、条件规则清单	条件设计阶段

在工具层面，ONES Desk 支持自定义工单属性与工单内容，适配不同收集场景，并可通过门户配置表单、分享填写链接供用户提单；工单还可关联到 ONES Project 的需求或缺陷工作项持续跟踪。字段必填与条件显示的具体配置粒度，以实际产品界面和实施核验为准。

示例：一张按类型拆分的提报模板

以下示例展示两个典型类型如何共用公共字段、各自配置专属字段，并标注必填与条件显示。示例为演示情景，字段名称可按实际业务调整。

字段	设备报修	账号权限申请	必填档位	条件显示
提报人	公共	公共	受理必需	始终显示
工单类型	公共	公共	受理必需	始终显示
问题描述	公共	公共	受理必需	始终显示
紧急程度	公共	公共	受理必需	始终显示
设备编号	专属	—	处理必需	类型为设备报修时显示
所在位置	专属	—	处理必需	类型为设备报修时显示
期望恢复时间	专属	—	处理必需	紧急程度为高时显示
系统名称	—	专属	处理必需	类型为账号权限申请时显示
权限范围	—	专属	处理必需	类型为账号权限申请时显示
使用期限	—	专属	统计必需	类型为账号权限申请时显示
问题分类	公共	公共	统计必需	处理完成前显示

填写说明在模板中的呈现位置：设备编号字段下方标注“机身标签上的八位数字，不含房间号，如 EQ-2024-0317”；权限范围字段下方标注“写明需要访问的模块和操作类型，如‘订单模块只读’”。说明紧跟字段，不集中放在表单末尾。

上线前的完成检查

模板配置完成后，按以下清单逐项核对，确认可用再开放提报入口。

• 类型覆盖检查：现有工单是否都能归入某个类型；是否存在长期无人使用或与其他类型高度重合的类型。
• 字段归属检查：每个字段是否明确属于公共或某个专属类型；是否存在同一信息在多个字段重复收集。
• 必填联动检查：每个必填字段是否对应受理、处理或统计中的明确需求；提报时必填项数量是否控制在提报人可承受范围。
• 条件显示检查：每个条件字段的所有取值分支是否都有明确结果；是否存在显示后未设必填、或隐藏后仍被校验的情况。
• 填写说明可读性检查：易错字段是否配有判断口径和示例；说明中是否出现无法执行的模糊词。
• 试填与反馈：邀请一线受理人和处理团队代表各试填两到三张典型工单，记录卡点并修正；试填通过后再正式上线。

上线后保留一个反馈入口，收集提报人和处理人的填写问题，按版本记录的方式定期调整。模板是持续维护的对象，类型和字段会随业务变化而调整，检查清单可以在每次变更后复用。

常见问题

提报人确实不知道某个处理必需字段的值，模板该怎么处理？

把这类字段改为“提报时选填、进入处理环节后由处理人补填并转为必填”。判定时问一句“提报人此刻是否一定知道这个答案”，答案是否定的就不放在提报时必填。这样受理环节不受影响，处理人仍能在开工前拿到完整信息，填写责任落在掌握信息的一方。

工单类型越设越多，字段和必填规则维护不过来怎么办？

先检查是否存在仅责任团队不同、处理路径几乎一致的类型，这类可以合并为一个类型加一个“责任团队”字段。类型数量建议初期控制在五到八个，每新增一个类型都意味着字段、必填和说明同步调整，因此新增前先确认它是否真的需要独立的字段集合。

条件显示配置后，出现该显示的字段没显示，如何排查？

按触发来源逐项核对：确认提报入口使用的是当前模板而非旧链接，检查条件依赖的字段是否被清空，再穷举该条件字段的所有取值分支是否都配了规则。模板评审时用穷举法检查一遍，上线后定期抽查工单。始终可见的“其他说明”文本字段可以作为兜底，避免信息完全丢失。

统计必需字段放在提报时填还是处理完成前填？

放在处理完成前由处理人填写更合适。问题分类、解决方式这类字段对单张工单的处理帮助有限，提报人往往也判断不准，强制在提报时填写容易得到随意选择的值。放到关闭前校验，由处理人按实际处理结果归类，统计口径更可靠，也不增加提报负担。

用 ONES Desk 承载这套模板时，字段和必填能配置到什么程度？

ONES Desk 支持自定义工单属性与工单内容，适配不同收集场景，并可通过门户配置表单、分享填写链接供用户提单；工单还可关联到 ONES Project 的需求或缺陷工作项持续跟踪。字段必填与条件显示的具体配置粒度，建议在试用或实施中按实际界面核验后再定稿模板。