工单字段是工单中用来记录一类信息的结构化数据项，例如标题、提交人、所属服务、优先级、处理人和状态。它决定了工单能被怎样描述、分派、流转和统计。本文围绕服务工单场景，解释字段的组成、边界，以及字段与表单、模板、属性的区别，帮助读者在阅读工单配置或设计工单表单时建立准确概念。
要点总览（TL;DR）
- 工单字段是工单中记录一类信息的结构化数据项，如标题、所属服务、优先级、处理人和状态，决定工单能被怎样描述、分派、流转和统计。
- 服务工单字段通常分为标识、分类、责任、时间、状态五类；缺陷报告字段规范和平台跨对象字段治理属于相邻主题，不纳入单张服务工单的字段设计。
- 分类字段决定工单进入哪条处理路径，责任字段支撑分派与交接，状态与时间字段支撑流转记录和时效统计，必填设置应只覆盖不填就无法分派或统计的信息。
- 字段是数据项，表单是字段的呈现组合，模板是预置字段组合与默认值，属性与字段在描述对象信息时含义接近，自定义字段与系统字段的区别在于来源和可调整程度。
- 字段并非越多越好，把分派和统计依赖的信息留在描述里会导致无法路由，照搬缺陷字段会增加填写负担；调整字段前需确认报表引用与历史数据回填。
工单字段的准确定义
工单字段是工单记录中一个具有固定含义和取值方式的数据项。每个字段对应一类信息，例如“优先级”字段只记录紧急程度，“处理人”字段只记录当前责任人。字段的取值通常受类型约束，可以是单行文本、下拉选项、日期、人员选择等。用户填写工单时，实际是在为一个个字段赋值，系统再依据这些值完成分派、筛选和统计。
字段与自由文本段落的分工在于：自由文本适合承载经过、补充说明和沟通记录，内容开放、结构弱；字段适合承载需要被机器识别和比较的信息，取值规范、可聚合。把“所属服务”写成描述里的一句话，系统无法据此自动路由；把它设为分类字段，工单才能进入对应的处理队列。
从用途看，工单字段承载四类信息：描述工单是什么，包括标题、问题类型、详细说明；决定工单由谁处理，包括所属团队、处理人、协作人；推动工单按规则流转，包括状态、处理阶段、关闭原因；支撑统计与分析，包括创建时间、解决时间、优先级、来源渠道。四类用途并不要求每个字段只服务一类，例如优先级既影响分派顺序，也进入统计口径。
字段与工单表单、工单模板的关系可以这样理解：字段是数据项本身，表单是字段面向提交人的呈现组合，模板是预置了字段组合与默认值的表单方案。三者层次不同，后文会进一步辨析。
一个服务工单常见的字段示例清单如下：
- 标识类：工单编号、标题、提交人、提交时间
- 分类类：所属服务、问题类型、来源渠道
- 责任类：处理团队、处理人、协作人
- 时间类：期望完成时间、首次响应时间、解决时间
- 状态类：当前状态、关闭原因、满意度评价
工单字段包括什么、不包括什么
工单字段的范围可以按信息类别划定。标识类字段用于唯一识别和追溯一张工单，如编号、标题、提交人；分类类字段用于把工单归入某个服务目录或问题类型，决定后续处理路径；责任类字段记录谁负责、谁协作，支撑分派与交接；时间类字段记录关键节点的时间点，用于时效管理和统计；状态类字段描述工单当前所处环节和结束方式。这五类构成服务工单字段的主体。
有些内容容易被误认为工单字段，实际属于相邻主题。缺陷报告的字段规范，例如复现步骤、影响版本、严重等级的设计，属于缺陷管理的信息规范，服务工单可以借用其中个别字段，但不应把整套缺陷字段照搬为工单字段体系。研发平台跨对象的字段治理，例如统一多个业务对象之间的字段命名和枚举值，属于平台配置与治理范畴，超出单张服务工单的字段设计。这两类内容在本文中不展开。
自由文本描述与结构化字段之间需要明确分工。描述字段通常保留为长文本，用于提交人补充背景、处理人记录沟通结论；结构化字段则承担可筛选、可统计、可触发规则的信息。判断一条信息该放哪里，可以问三个问题：它是否需要被筛选或统计？它是否影响分派或流转？它的取值是否应当统一？三个问题中有一个答案为是，就适合设为结构化字段；都否，放在描述中更合适。
| 信息内容 | 归属 | 说明 |
|---|---|---|
| 工单标题、优先级、处理人 | 服务工单字段 | 直接参与描述、分派与统计 |
| 问题经过、沟通记录 | 自由文本描述 | 内容开放，不要求统一取值 |
| 复现步骤、影响版本、缺陷严重等级 | 缺陷报告规范 | 属于缺陷管理的信息设计，按需借用 |
| 多业务对象间的字段命名与枚举统一 | 平台跨对象字段治理 | 属于平台配置治理范畴 |
字段如何驱动工单的分类与流转
分类字段决定工单进入哪条处理路径。当提交人选择“所属服务”为“办公网络”时，系统可以据此把工单路由到网络支持组；选择“账号权限”则进入应用支持组。分类字段的取值体系实际上就是服务目录的映射，取值划分得越贴近实际处理分工，路由越准确。分类字段设计过粗，工单会集中到少数队列再靠人工二次判断；设计过细，提交人难以选择，反而增加误分类。
责任字段支撑分派与交接。处理人字段记录当前责任人，协作人字段记录需要参与但不主导的角色。当工单在团队之间转交时，责任字段的变更同时留下交接痕迹，便于追溯“谁在什么时间接手”。责任字段与分类字段配合，可以先按分类确定默认处理团队，再由团队负责人指定具体处理人。
状态与时间字段支撑流转记录与统计。状态字段描述工单当前环节，例如待受理、处理中、待确认、已关闭；时间字段记录各环节发生的时间点。两者结合，可以计算首次响应时长、解决时长、各状态停留时间，形成时效统计。缺少时间字段，状态变化只能看到结果，无法衡量过程效率。
必填与选填的设置直接影响填写质量。把影响分派的关键字段设为必填，例如所属服务、问题类型，可以避免工单因信息缺失而滞留；把补充性信息设为选填，可以降低提交门槛。必填项过多会让提交人随意填写凑数，必填项过少则让处理人反复追问。合理的做法是：只把不填就无法分派或无法统计的字段设为必填，其余保持选填并在描述中引导补充。
在工具层面，ONES Desk 支持自定义工单属性以适配不同角色的收集需求，也支持自定义配置工单内容以适配不同收集场景，并可灵活调整工作流以适应不同企业的工作方式。这些能力对应的正是上述分类、责任与状态字段的配置动作：把服务目录映射为分类字段，把处理角色映射为责任字段，把处理环节映射为状态字段。ONES Desk 企业版还提供统一门户集中接收工单，以及多维度的数据统计与分析能力，字段取值因此可以直接进入统计口径。具体字段类型清单与必填规则，需以实际产品配置为准。
工单字段与表单、模板、属性的区别
字段是数据项，表单是字段的呈现组合。同一组字段可以组成不同的表单：面向内部员工的提单表单可能只展示标题、所属服务、描述三个字段；面向外部客户的表单可能增加联系方式、合同编号。表单解决的是“哪些字段在什么场景下展示给谁填写”，字段本身解决的是“这类信息以什么形式被记录”。
模板是预置字段组合与默认值的方案。模板在表单基础上进一步固化：选择“设备报修”模板时，系统自动带出所属服务为“设备支持”、优先级默认为“中”，并展示与报修相关的字段。模板的价值在于减少重复填写和误选，它依赖字段存在，本身不产生新的数据项。
属性与字段在描述对象信息时含义接近，都指对象上承载的一类信息。区别在于使用语境：字段更强调数据结构和取值约束，属性更强调对象具备某项特征。在工单场景中，两者常可互换使用，讨论配置时用“字段”更准确，讨论对象特征时用“属性”更自然。
自定义字段与系统字段的区别在于来源和可调整程度。系统字段由产品预置，通常承载编号、创建时间、状态等基础信息，取值规则由系统维护；自定义字段由管理员按业务需要新增，用于记录产品未预置的信息，例如“所属办公区”“资产编号”。自定义字段应围绕分类、责任归属和统计口径设置，避免把处理过程记录塞进字段，也避免为每一句话都建一个字段。
| 概念 | 回答的问题 | 示例 |
|---|---|---|
| 字段 | 这类信息以什么形式记录 | 优先级：下拉单选，取值高/中/低 |
| 表单 | 哪些字段在什么场景展示给谁填 | 内部提单表单只展示三个字段 |
| 模板 | 预置哪些字段和默认值 | 设备报修模板默认所属服务为设备支持 |
| 属性 | 对象具备哪项特征 | 工单具有“来源渠道”属性 |
| 系统字段 | 产品预置、规则由系统维护 | 工单编号、创建时间 |
| 自定义字段 | 按业务需要新增 | 所属办公区、资产编号 |
一个工单字段设置的具体例子与常见误解
以下是一个服务请求工单的演示情景，用于说明字段类别与取值方式，不代表任何产品的实际配置界面。
| 字段 | 类别 | 取值示例 | 填写要求 |
|---|---|---|---|
| 工单标题 | 标识类 | 申请开通项目文档库权限 | 必填 |
| 提交人 | 标识类 | 张三 | 系统自动带出 |
| 所属服务 | 分类类 | 账号与权限 | 必填 |
| 问题类型 | 分类类 | 权限申请 | 必填 |
| 优先级 | 分类类 | 中 | 必填，默认中 |
| 处理团队 | 责任类 | 应用支持组 | 按所属服务自动匹配 |
| 处理人 | 责任类 | 李四 | 由团队负责人指定 |
| 期望完成时间 | 时间类 | 2025-06-30 | 选填 |
| 当前状态 | 状态类 | 处理中 | 系统维护 |
| 详细说明 | 自由文本 | 需要访问的文档库名称及用途 | 必填 |
这个例子中，分类字段把工单送入“账号与权限”处理路径，责任字段确定由应用支持组承接，状态与时间字段记录流转过程，详细说明承载无法结构化的背景信息。字段数量控制在十个左右，覆盖分派与统计所需，没有为每一条补充信息单独建字段。
常见误解之一是字段越多越好。字段增加会提高提交人的填写负担，也会让统计口径变得分散。字段的价值取决于是否被实际用于筛选、分派或统计，长期无人使用的字段应当合并或停用。
误解之二是所有信息都塞进描述。描述适合承载经过和补充说明，一旦分派规则、时效统计依赖某条信息，它就应当成为字段。把所属服务、优先级写在描述里，系统无法据此路由和排序。
误解之三是把缺陷字段照搬到服务工单。复现步骤、影响版本、严重等级服务于缺陷定位，服务请求工单通常不需要这些字段；照搬会增加填写负担，也会让统计口径混杂两类业务。
字段调整还会影响历史数据与统计口径。新增字段后，历史工单该字段为空，按该字段统计时会出现“未填写”一类；修改下拉选项的枚举值，旧取值可能无法归入新分类；删除字段会导致历史数据失去对应列。调整前应确认报表是否引用该字段、历史数据是否需要回填、枚举变更是否需要保留旧值映射。这些影响在具体产品中的处理方式不同，配置时需结合实际系统的字段变更规则核验。
常见问题
工单字段设置得越细，工单处理就越规范吗？
字段的细化程度要与实际处理分工匹配。分类字段划分得贴近团队分工，路由会更准确；划分过细，提交人难以判断该选哪一项，误分类反而增加二次判断的工作量。判断一个字段是否值得保留，可以看它是否被实际用于筛选、分派或统计，长期无人使用的字段应当合并或停用。
服务工单里能不能直接使用缺陷报告的那套字段？
可以按需借用个别字段，但整套照搬通常不合适。复现步骤、影响版本、严重等级服务于缺陷定位，服务请求工单一般不需要这些信息。混用会让填写负担上升，也会让统计口径混杂两类业务。缺陷报告字段规范属于缺陷管理的信息设计，服务工单的字段体系应围绕服务目录、责任归属和时效统计来组织。
修改已有工单字段后，历史数据和报表会受什么影响？
常见影响有三类：新增字段后历史工单该字段为空，按该字段统计时会出现“未填写”一类；修改下拉选项的枚举值，旧取值可能无法归入新分类；删除字段会让历史数据失去对应列。调整前建议确认报表是否引用该字段、历史数据是否需要回填、枚举变更是否需要保留旧值映射。具体处理方式因系统而异，配置时需结合实际系统的字段变更规则核验。
必填字段应该设多少个比较合适？
一个实用的原则是：只把不填就无法分派或无法统计的字段设为必填，例如所属服务、问题类型；补充性信息保持选填，并在描述中引导提交人补充。必填项过多，提交人容易随意填写凑数；必填项过少，处理人需要反复追问，工单在队列中滞留的时间会变长。
字段和属性在工单配置里是一回事吗？
两者在描述对象信息时含义接近，都指对象上承载的一类信息，日常交流中常可互换。区别在于使用语境：字段更强调数据结构和取值约束，属性更强调对象具备某项特征。讨论具体配置项时用“字段”更准确，讨论工单具备哪些特征时用“属性”更自然。
