确定提单信息要求，可以从工单要支撑的动作倒推：先梳理提交、受理、分派、处理、验证到关闭的流转节点，列出每个节点上不同角色推进工作所需的信息，再据此决定必填、选填和条件必填字段。本文给出一套可执行的字段设计步骤，包括四类信息的取舍规则、维护责任分工、一个服务工单示例，以及上线前用历史工单验证的方法。
要点总览（TL;DR）
- 提单信息要求从工单流转节点反推：先列出提交、受理、分派、处理、验证、关闭各节点由谁操作、推进需要什么信息，再汇总成字段候选清单。
- 字段按定位问题、判断优先级、分派责任、记录处理结果四类取舍；缺失会导致无法分派或无法处理的字段设为必填，其余按需选填或条件必填。
- 字段取值优先用枚举和关联对象，减少自由文本，并为关键字段设置校验规则；处理结果类字段放到对应节点再要求填写。
- 字段清单需明确服务台、处理团队负责人、数据统计方的职责，约定新增、修改、停用的申请与审批路径，并处理对历史工单和报表的影响。
- 上线前用历史工单按新字段回填，检查是否出现无法分派或信息缺失，清理长期无人填写的冗余字段后再发布。
先定工单流转节点，再推导字段
提单信息要求的起点是工单生命周期，而非字段模板。字段存在的理由是让某个角色在某个节点做出判断或完成动作；找不到使用方的字段，通常会在上线几个月后变成无人填写的空项。因此第一步是把工单从提交到关闭的节点逐一列出，标注每个节点的操作角色和推进条件。
梳理时按以下顺序进行，产出物是一张节点与信息需求对照表：
- 列出节点：提交、受理、分派、处理、验证、关闭。如果组织还有升级、挂起、转派等分支，一并标出。
- 标注操作角色：每个节点由谁操作，例如提单人、服务台受理人、处理团队负责人、处理人、验证人。
- 写明推进条件：该角色要做出什么判断才能把工单交给下一个节点，判断依赖哪些信息。
- 汇总候选字段：把各节点的信息需求去重合并，形成字段候选清单，暂不判断必填与否。
下表是一张对照表的填写结构，可直接用于工作坊讨论：
| 节点 | 操作角色 | 推进所需信息 | 对应候选字段 |
|---|---|---|---|
| 提交 | 提单人 | 说明发生了什么、影响谁、紧急程度 | 问题描述、影响范围、期望时间 |
| 受理 | 服务台受理人 | 判断是否属于服务范围、信息是否足够 | 工单类型、所属系统、附件 |
| 分派 | 服务台或团队负责人 | 确定由哪个团队、哪个人处理 | 责任团队、处理人、优先级 |
| 处理 | 处理人 | 复现问题、记录处理过程与结果 | 处理记录、解决方案、耗时 |
| 验证 | 提单人或验证人 | 确认问题已解决 | 验证结论、验证时间 |
| 关闭 | 服务台 | 归档原因、便于统计与复盘 | 关闭分类、根因分类 |
这张表的完成标志是：每个候选字段都能指回至少一个节点和一名使用角色。指不回去的字段先放入观察区，不进入正式清单。
把字段分成四类并定必填与选填
候选清单往往偏长，取舍需要一个统一口径。把字段按用途分成四类，再逐类判断必填程度，可以避免“重要就必填”的随意决定。
四类信息的划分
- 定位问题：帮助受理人和处理人确认问题是什么、发生在哪里，例如工单类型、所属系统、问题描述、报错截图。
- 判断优先级：支撑紧急程度评估，例如影响范围、受影响人数、业务截止时间。
- 分派责任：决定工单流向，例如责任团队、处理人、所属产品线。
- 记录处理结果：用于处理过程留痕和后续统计，例如解决方案、根因分类、处理耗时、验证结论。
必填、选填与条件必填的判断
必填的判断标准只有一条：该字段缺失时，工单无法被分派或无法被处理。按此标准，定位问题和分派责任类字段多数应设为必填；判断优先级类字段中，影响范围通常必填，期望完成时间可按服务级别协议决定；记录处理结果类字段多在处理或关闭节点填写，属于流程后段必填，而非提单时必填。
条件必填用于“某些工单类型下才需要”的信息。例如账号类工单需要填写账号标识，硬件类工单需要填写设备编号；当工单类型选择为某一枚举值时，对应字段才变为必填。选填字段则用于提升统计质量或方便沟通，例如补充说明、相关工单链接。
取值方式与校验规则
取值方式直接影响数据能否被统计。能用枚举的字段不用自由文本，能关联到人员、团队、系统等对象的字段用关联方式，只有描述性内容才用长文本。校验规则与字段配套设置，例如必填校验、枚举值限制、附件格式与大小限制、时间字段的合理范围。下表给出字段清单的填写结构：
| 字段名 | 类别 | 填写要求 | 取值方式 | 校验规则 |
|---|---|---|---|---|
| 工单类型 | 定位问题 | 必填 | 枚举 | 限定在已维护的类型列表内 |
| 问题描述 | 定位问题 | 必填 | 长文本 | 最少字数限制 |
| 影响范围 | 判断优先级 | 必填 | 枚举 | 单选 |
| 期望完成时间 | 判断优先级 | 条件必填 | 日期时间 | 不早于提交时间 |
| 责任团队 | 分派责任 | 必填 | 关联团队 | 限定在服务团队列表内 |
| 账号标识 | 定位问题 | 条件必填（账号类工单） | 短文本 | 格式校验 |
| 解决方案 | 记录处理结果 | 关闭时必填 | 长文本 | 关闭动作触发校验 |
角色分工与字段维护责任
字段清单如果没有明确的责任人，会在每次业务变化时被临时加字段，两三年后表单变得冗长而无人清理。字段设计需要三类角色参与，各自承担不同职责。
| 角色 | 在字段设计中的职责 | 交付物 |
|---|---|---|
| 服务台/受理人 | 提出提单侧信息需求，判断哪些字段缺失会导致受理和分派受阻 | 提单字段需求与必填建议 |
| 处理团队负责人 | 确认处理侧所需信息，评估字段对处理效率的实际影响 | 处理与关闭节点字段需求 |
| 数据统计方 | 提出统计与复盘所需维度，检查字段取值方式是否可统计 | 统计口径与字段取值要求 |
字段的新增、修改和停用应有统一申请路径：由需求方提交申请，说明使用节点、使用角色、缺失后果和取值方式；服务台负责人与数据统计方共同评审；涉及流程变化的字段由处理团队负责人确认；评审通过后由系统配置管理员实施并记录变更。停用字段比新增更需要谨慎，应先确认没有报表和自动化规则引用该字段。
字段变更会影响历史工单和报表。新增必填字段时，历史工单不会自动补齐，统计口径需要注明生效时间；修改枚举值时，旧值应保留映射关系，避免历史报表出现空值；停用字段前应导出历史数据或保留字段只读。变更记录中写明生效日期、影响范围和回填处理方式，是后续排查数据差异的依据。
当字段清单需要在工单系统中落地时，配置动作包括在工作项类型上定义字段、设置必填与校验、把字段放入提单表单，并按流转节点控制字段的可见与可编辑状态。ONES Desk 支持自定义工单属性与工单内容配置，适配不同收集场景，也支持自定义处理流程与字段配置；在配置前，仍需按前述方法确认每个字段的使用节点和责任人，工具只承载已经想清楚的规则。
示例：一张服务工单的提单字段设计
以下示例为演示场景，用一张“办公系统账号异常”工单说明从节点到字段的推导结果，不代表真实客户案例。该工单的流转节点为：员工提交、服务台受理、分派至IT支持组、处理人排查、员工验证、服务台关闭。
| 字段名 | 类别 | 填写要求 | 取值方式 | 使用节点 |
|---|---|---|---|---|
| 工单类型 | 定位问题 | 必填 | 枚举（账号、权限、设备、网络等） | 提交、受理、分派 |
| 问题描述 | 定位问题 | 必填 | 长文本 | 提交、受理、处理 |
| 账号标识 | 定位问题 | 条件必填（类型为账号或权限时） | 短文本 | 提交、处理 |
| 报错截图 | 定位问题 | 选填 | 附件 | 提交、处理 |
| 影响范围 | 判断优先级 | 必填 | 枚举（仅本人、本部门、多部门） | 提交、受理、分派 |
| 是否影响业务截止 | 判断优先级 | 条件必填（影响范围为多部门时） | 布尔 | 受理、分派 |
| 责任团队 | 分派责任 | 必填 | 关联团队 | 分派 |
| 处理人 | 分派责任 | 分派时必填 | 关联人员 | 分派、处理 |
| 处理记录 | 记录处理结果 | 处理中必填 | 长文本 | 处理 |
| 解决方案 | 记录处理结果 | 关闭时必填 | 长文本 | 处理、关闭 |
| 根因分类 | 记录处理结果 | 关闭时必填 | 枚举 | 关闭、统计 |
| 验证结论 | 记录处理结果 | 验证时必填 | 枚举（已解决、未解决） | 验证、关闭 |
这张表体现了几个取舍：报错截图对排查有帮助，但员工不一定能提供，设为选填；账号标识只在账号和权限类工单中出现，用条件必填控制；处理记录、解决方案、根因分类在提单时并不需要，放到对应节点再要求填写，避免提单人面对与己无关的字段。每个字段都能指回具体节点和角色，是这张表可用的标志。
用历史工单检验并形成完成检查
字段设计完成后，用历史工单做一次回填检验，比在上线后收集抱怨更有效。抽取近三到六个月、覆盖各工单类型和主要处理团队的工单样本，按新字段清单逐条回填，记录两类问题：一是按新规则无法分派或缺少关键信息的工单，说明必填字段不足或取值方式不合理；二是长期无人填写或填写率极低的字段，说明该字段缺少真实使用方，应考虑改为选填或停用。
回填时同步检查统计可用性：用新字段重新汇总工单量、处理时长和根因分布，与现有报表对比，确认枚举值覆盖了主要情况，没有大量落入“其他”选项。若“其他”占比过高，通常说明枚举设计不完整，需要补充取值而非增加文本字段。
上线前按下表逐项核对，全部通过再发布字段清单：
| 检查项 | 通过标准 | 记录 |
|---|---|---|
| 必填字段可推进流程 | 用样本工单验证，仅凭必填字段即可完成受理与分派 | 样本数量、无法分派工单数 |
| 字段有明确使用方 | 每个字段能指回至少一个节点和角色 | 字段与角色对照结果 |
| 条件必填规则可执行 | 触发条件清晰，配置后能正确生效 | 触发条件测试结果 |
| 取值方式支持统计 | 关键维度为枚举或关联对象，“其他”占比在可接受范围 | 回填统计对比 |
| 冗余字段已处理 | 低填写率字段已改为选填或停用 | 处理清单 |
| 变更规则已确定 | 新增、修改、停用的申请与审批路径已发布 | 规则文档与责任人 |
验证记录与检查清单应随字段清单一同归档，并在每次字段变更时更新。这样，提单信息要求就从一个静态表单变成一套可维护的规则：节点决定字段来源，四类信息决定取舍，责任人决定变更，历史数据检验决定是否真的可用。
常见问题
工单类型很多时，是否需要为每种类型单独设计一套提单字段？
不必为每种类型单独设计完整表单。更实用的做法是维护一套公共字段，覆盖定位问题、判断优先级和分派责任的基本信息，再针对差异明显的类型设置条件必填字段。例如账号类工单增加账号标识，硬件类工单增加设备编号。这样提单人面对的表单长度可控，配置和维护成本也更低。判断是否需要拆分的标准是：该类型是否有独有的、缺失后无法处理的字段；如果只是描述内容不同，用问题描述和附件承载即可。
提单人不知道选哪个工单类型或责任团队时，字段设计上怎么处理？
这通常说明分类枚举对提单人不够直观，或者把本应由服务台判断的字段前置到了提单环节。可以采取两种处理：一是把工单类型改为面向提单人语言的分类，并在选项旁给出简短说明；二是把责任团队设为服务台受理时填写，提单环节只保留“所属系统”或“影响业务”这类提单人能判断的信息。分派责任类字段的使用节点放在受理和分派，比要求提单人自行选对团队更可靠。
条件必填的触发规则配置后没有生效，常见原因有哪些？
常见原因包括：触发字段本身是选填且允许为空，导致条件判断落空；触发条件依赖的枚举值在后续被修改或停用，规则未同步更新；字段可见性与必填设置分属不同配置层，只改了其中一处；以及流程节点切换后字段状态未按节点重新计算。排查时先用一条样本工单走完整流程，逐节点确认字段的可见、可编辑和必填状态，再检查枚举值变更记录。条件必填规则建议在字段清单中与触发条件一并记录，变更时同步核对。
字段上线后业务方频繁要求加字段，如何控制表单膨胀？
把新增申请纳入统一路径：需求方说明使用节点、使用角色、缺失后果和取值方式，由服务台负责人与数据统计方评审，涉及流程变化的由处理团队负责人确认。评审时重点问两个问题：这个字段在哪个节点被谁使用，缺失时会导致什么动作无法完成。回答不了这两问的，先放入观察区，用一段时间的人工记录验证需求是否真实存在。同时定期回看字段填写率，把长期低填写率的字段改为选填或停用，让表单规模保持在可维护范围。
历史工单回填检验需要抽多少样本，覆盖哪些范围？
样本量没有统一标准，关键是覆盖到位：时间上取近三到六个月，类型上覆盖主要工单类型，团队上覆盖主要处理团队，并包含少量升级、转派、挂起等分支工单。回填时重点记录两类结果：按新规则无法分派或缺少关键信息的工单数量，以及各字段的填写率。前者用于判断必填字段是否不足，后者用于识别冗余字段。若某类工单样本过少导致结论不稳，可延长取样时间或单独补充该类样本，再决定字段取舍。
