工单字段规范要解决的是信息在流转中丢失、口径不一致的问题：同一类问题被分到不同类别，描述缺少复现步骤，关闭原因写得笼统，导致统计和复盘都无从下手。本文按“规范包含什么—怎么起草—谁来填—填成什么样—怎么验收”的顺序，给出一份可直接起草、评审和发布的文档框架，范围限于服务台与工单系统中的服务数据规范。
要点总览（TL;DR）
- 工单字段规范由两部分组成：按“基本信息—分类与优先级—问题描述—处置过程—关闭与回访”五段组织的字段清单，以及逐字段写明类型、必填级别、取值来源、填写角色、填写时点和校验规则的定义表。
- 必填级别分必填、条件必填、选填三档，划分依据要写进规范：缺少后流程无法继续或无法统计的设为必填，只在特定场景需要的信息设为条件必填并写明触发条件。
- 起草按五步推进：盘点信息断点、列出候选字段、确定必填级别与取值字典、编写定义表并标注角色时点、用真实工单试填后定稿发布。
- 落地要落到五类角色：提交人、受理/分派角色、处置人、规范维护人、评审角色，其中分类复核和字典变更管理最容易失效，需单独约定。
- 发布前逐项核对字段覆盖、必填依据、字典封闭性、角色时点、试填结果和版本变更管理，全部通过再发布，发布后按季度复核字典使用情况。
一份可执行的工单字段规范包含哪些内容
可执行的规范由两部分组成：一份按工单生命周期分段的字段清单，以及一张逐字段写清填写要求的定义表。清单解决“工单要收集哪些信息”，定义表解决“每个字段怎么填、谁来填、填错怎么办”。两者配套，规范才能被不同角色照着执行。
字段清单建议按五个阶段组织，每个阶段承担不同的信息任务：
- 基本信息：工单编号、提交时间、提交人、所属组织、来源渠道、联系方式。用于定位“谁在什么时候通过什么途径提了什么”。
- 分类与优先级：工单类型、二级分类、影响范围、紧急程度、优先级。用于分派和排期，取值应来自固定字典。
- 问题描述：现象描述、发生时间、复现步骤、期望结果、实际结果、附件（截图、日志、报错文本）。用于让处置人无需反复追问即可判断问题。
- 处置过程：受理人、分派人、处置人、处置动作记录、关联需求或缺陷、预计完成时间、当前状态。用于跟踪进度和交接。
- 关闭与回访：关闭原因、解决方案、关闭时间、关闭人、回访结果、满意度。用于归因统计和服务质量评估。
定义表是规范的核心交付物，建议按七列组织，评审时逐行核对：
| 字段名 | 类型 | 必填级别 | 取值来源 | 填写角色 | 填写时点 | 校验规则 |
|---|---|---|---|---|---|---|
| 工单类型 | 单选 | 必填 | 分类字典（封闭枚举） | 提交人 | 提交时 | 必须从字典中选择，不可自由输入 |
| 复现步骤 | 多行文本 | 条件必填 | 提交人填写 | 提交人 | 提交时 | 工单类型为“故障/缺陷”时必填，不少于三步 |
| 关联需求或缺陷 | 关联项 | 条件必填 | 从研发工作项中选择 | 处置人 | 判定需研发介入时 | 状态为“转研发”时必填 |
| 关闭原因 | 单选 | 必填 | 关闭原因字典 | 处置人 | 关闭工单时 | 选择“其他”时须在解决方案中补充说明 |
必填级别分三档，划分依据要写进规范，避免变成习惯性要求：必填用于缺少后流程无法继续或无法统计的字段，如工单类型、问题描述、关闭原因；条件必填用于只在特定场景下才需要的信息，如故障类工单的复现步骤、转研发工单的关联工作项，触发条件必须写明；选填用于提升信息质量但缺失不影响流转的字段，如补充附件、期望完成时间。
命名与取值口径要统一。字段名用业务语言而非系统内部代号，例如用“影响范围”而不是“impact_level”；同一含义只保留一个字段，避免“客户名称”和“报障单位”并存。分类、优先级、来源渠道、关闭原因这类字段一律使用封闭字典，字典项附一句定义，例如优先级“高”定义为“核心业务不可用且无替代方案”，让不同填写人做出相同判断。
从零起草规范的五个步骤
起草规范是一个从现状出发、逐步收敛的过程。五个步骤各有明确的输入、动作和输出，完成标志清晰，便于控制进度。
第一步：盘点流转环节与信息断点
输入是近三个月的历史工单样本和现行处置流程说明。动作是抽取样本工单，逐条标注信息在哪个环节缺失、哪个环节需要回头追问提交人、哪些字段填了但从未被使用。输出是一份信息断点清单，例如“分派时经常不知道影响范围”“关闭时无法区分是解决还是用户放弃”。完成标志是每个流转环节都至少有一条被记录的信息问题。
第二步：按环节列出候选字段
针对每个信息断点提出候选字段，同时保留现有字段中确实被使用的部分。动作包括合并同义字段、删除无人使用的字段、为断点补充新字段。输出是一份候选字段清单，按生命周期五段归类，每个字段注明它解决哪个断点。完成标志是清单中每个字段都能对应到一个具体的信息需求，没有“先留着以后可能有用”的字段。
第三步：确定必填级别与取值字典
对候选字段逐个判定必填、条件必填或选填，判定理由写在字段旁边。同时为分类、优先级、来源渠道、关闭原因等字段建立字典，字典项控制在可人工判断的数量内，并为每项写一句判定标准。输出是带级别的字段清单和取值字典初稿。完成标志是每个必填字段都有“缺少会导致什么后果”的说明，每个字典项都能被两位不同角色独立判断为同一结果。
第四步：编写字段定义表并标注角色与时点
把前三步的结果整理成七列定义表，重点补全填写角色和填写时点两列。时点要具体到流程动作，例如“受理时”“判定转研发时”“关闭前”，避免写“随时”。输出是可评审的字段定义表完整稿。完成标志是表中每一行都有明确的责任角色，不存在“相关人填写”这类模糊表述。
第五步：真实工单试填、修订并发布
选取覆盖主要类型的十到二十条真实工单，让实际填写角色按新规范重新填写，记录卡壳点：哪些字段不知道怎么填、哪些条件必填的触发判断有歧义、哪些字典项找不到合适选项。根据反馈修订定义表，输出定稿版本，附版本号、生效日期和变更流程。完成标志是试填工单中因字段问题产生的追问次数明显下降，且评审角色确认无遗留争议项。
谁填写、谁维护：角色与交付物分工
规范写完无人执行，通常是因为填写责任没有落到具体角色。落地涉及五类角色，每类角色在规范中有明确的动作和产出。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 提交人 | 按规范填写描述类字段，从字典中选择分类，提供复现信息与附件 | 信息完整的工单提交记录 |
| 受理/分派角色 | 核对分类与优先级是否准确，补全影响范围、所属系统等定位信息，必要时退回补充 | 分类准确的待处置工单、退回补充记录 |
| 处置人 | 填写处置过程、解决方案、关联需求或缺陷，选择关闭原因 | 处置记录与关闭信息 |
| 规范维护人 | 维护字段字典与定义表，管理版本号、生效日期与变更记录，处理字典项新增申请 | 字段定义表各版本、变更日志 |
| 评审角色 | 在试填与定稿阶段确认字段可填、可判断、可统计，对争议字段给出结论 | 试填反馈记录、评审结论 |
分工中有两个容易失效的环节需要特别约定。一是分类纠错：提交人选的分类经常不准，规范应明确受理角色在分派前完成分类复核，并把纠错动作计入受理职责，而不是事后抱怨。二是字典变更：业务变化会产生新类型，规范维护人应设定固定的变更窗口和审批人，新增字典项须同时更新定义和统计口径，避免字典在无人管理的情况下被自由文本侵蚀。
规范落到工具中时，字段定义和填写时点需要有承载位置。ONES Desk 支持自定义工单属性与工单内容配置，可按不同收集场景设置表单，并通过统一门户集中接收工单；工单还可关联到 ONES Project 的需求或缺陷工作项继续跟踪。规范中的必填级别、字典项和角色分工可以先在文档中定稿，再对照工具的实际配置能力逐项落地，具体字段类型、校验规则与权限范围以实际产品配置为准。
填写示例：一条工单的字段如何填完整
以下为演示情景，用于说明规范在单条工单上的填写结果。某员工反馈报销系统在提交单据时页面报错。
| 字段 | 填写内容 | 说明 |
|---|---|---|
| 来源渠道 | 服务门户 | 字典项，提交时选择 |
| 工单类型 / 二级分类 | 系统故障 / 财务系统 | 字典项，受理时复核确认 |
| 影响范围 | 财务部全员，报销截止日前无法提交 | 受理时补全 |
| 优先级 | 高 | 依据字典定义“核心业务不可用且无替代方案”判定 |
| 现象描述 | 点击“提交”后页面提示“系统异常”，单据未生成 | 提交人填写，含报错原文 |
| 复现步骤 | 1. 登录报销系统；2. 新建报销单并填写三条明细；3. 点击提交 | 条件必填触发：类型为系统故障 |
| 附件 | 报错截图、浏览器版本信息 | 选填，本例提供 |
| 关联需求或缺陷 | 缺陷 #4821 | 条件必填触发：判定需研发修复 |
| 处置过程 | 定位为附件上传组件版本问题，已回滚并验证 | 处置人填写 |
| 关闭原因 | 已修复 | 字典项，关闭时选择 |
| 回访结果 | 提交人确认可正常提交 | 关闭后回访填写 |
示例中条件必填字段的触发判断是规范可操作性的关键。“复现步骤”因工单类型为系统故障而触发；“关联需求或缺陷”在受理角色判定需研发介入、状态转为“转研发”时触发；若该工单最终由服务台直接解决、未转研发，则关联字段保持为空，关闭原因选择“已解决”而非“已修复”，两者的区别应在字典中写明。
常见填写错误有三类，纠正方式应写进规范而非依赖口头提醒。分类选错：提交人把权限问题选成系统故障，纠正方式是受理角色在分派前复核分类，并在退回时说明正确类别及判断依据。描述缺复现信息：只写“系统用不了”，纠正方式是设置条件必填校验，并在表单中给出复现步骤的填写提示。关闭原因笼统：统一填“已处理”，纠正方式是关闭原因使用封闭字典，选择“其他”时强制在解决方案中补充说明，同时定期抽查关闭记录。
发布前的完成检查
规范是否达到可发布状态，可以逐项核对。以下清单每项都给出通过标准，全部通过再发布。
| 检查项 | 通过标准 |
|---|---|
| 字段覆盖全流程 | 基本信息、分类与优先级、问题描述、处置过程、关闭与回访五个阶段均有字段，且无同义重复字段 |
| 必填级别有依据 | 每个必填和条件必填字段都写明缺失后果与触发条件，条件必填的触发判断可被独立复现 |
| 取值字典封闭可枚举 | 分类、优先级、来源渠道、关闭原因等字段全部使用固定选项，每项附判定定义，无自由文本入口 |
| 责任角色与时点明确 | 每个字段都有具体填写角色和流程时点，不存在“相关人”“随时”等模糊表述 |
| 经过真实工单试填 | 试填覆盖主要工单类型，卡壳点已修订，追问次数较试填前下降 |
| 版本与变更管理就绪 | 文档标注版本号、生效日期、维护人和变更审批流程，字典新增有固定入口 |
检查中若发现字段覆盖不全，回到第二步补充候选字段；若发现条件必填判断有歧义，回到第三步修订触发条件并重新试填。发布后建议按季度复核一次字典使用情况，统计各字典项的实际选择分布和“其他”项占比，占比异常升高的类别通常意味着字典需要扩充或定义需要澄清，这类复核结果应作为下一版本变更的输入。
常见问题
工单字段是不是越多越好？怎么判断一个字段该不该保留？
字段数量应以信息需求为准，而不是以收集全面为目标。判断一个字段是否保留，可以看它是否对应一个具体的信息断点：分派时是否真的需要它、统计时是否会用到它、缺少它是否会导致流程卡住或需要回头追问。如果某个字段在历史工单中填了但从未被使用，或者只是“以后可能有用”，建议删除或降为选填。
字段过多会带来两个直接后果：提交人填写负担加重，容易敷衍填写；必填项堆叠后，填写人倾向于随便选一个选项通过校验，反而降低数据质量。规范定稿前用真实工单试填，观察哪些字段反复被跳过或填错，是判断字段必要性的有效方式。
条件必填的触发条件怎么写才不会产生歧义？
触发条件要绑定到可观察的流程动作或字段取值，避免使用“必要时”“视情况”这类判断。例如“工单类型为系统故障时，复现步骤必填”“状态转为转研发时，关联需求或缺陷必填”，这类条件由字段值或状态变化直接决定，不同角色能做出相同判断。
写完触发条件后，建议让两位不同角色分别对同一批工单判断是否触发，如果结论不一致，说明条件需要进一步收紧。试填阶段重点检验条件必填字段，因为这类字段的歧义往往在正式运行后才暴露，届时纠正成本更高。
分类字典运行一段时间后，“其他”选项占比越来越高怎么办？
“其他”占比升高通常意味着两类问题：一是业务出现了字典未覆盖的新类型，二是现有字典项的定义不够清晰，填写人无法判断该选哪一项。处理方式不同：前者需要扩充字典项，后者需要修订定义并补充判定示例。
建议按季度统计各字典项的选择分布和“其他”项占比，把异常升高的类别作为下一版本变更的输入。字典变更应走固定入口，由规范维护人审批，新增字典项时同步更新统计口径，避免新旧口径混用导致报表失真。
规范发布后，提交人仍然不按格式填写，靠什么约束？
约束手段分三层，按成本从低到高排列。第一层是表单校验：把关键字段设为必填或条件必填，用封闭字典替代自由文本，让不合规的填写在提交环节就无法通过。第二层是受理复核：明确受理/分派角色在分派前核对分类与优先级，信息不足时退回补充，并把这一动作计入受理职责。第三层是定期抽查：对关闭原因、描述质量等难以完全靠校验约束的字段，定期抽样检查并反馈到相关角色。
三层手段中，表单校验最稳定，因为它不依赖人的自觉；受理复核和抽查需要明确责任人和频率，否则容易流于形式。规范中应把这三层约束写成具体动作，而不是笼统要求“认真填写”。
规范落到工单系统里，字段配置和文档定稿应该谁先谁后？
建议先在文档中定稿字段定义表，再对照工具的实际配置能力逐项落地。文档阶段不受系统限制，可以先把字段清单、必填级别、字典项和角色分工讨论清楚；进入配置阶段后，再根据工具支持的字段类型、校验规则和权限范围做取舍，无法完全实现的校验用受理复核等流程动作补位。
以 ONES Desk 为例，其支持自定义工单属性与工单内容配置，可按不同收集场景设置表单，工单还可关联到 ONES Project 的需求或缺陷工作项继续跟踪。具体字段类型、校验规则与权限范围以实际产品配置为准，配置前建议先确认这些细节，再决定哪些校验放在系统里、哪些放在流程里。
