工单信息填写说明要解决的是让提单人一次把服务请求写清楚，减少受理后的反复补问。编写时按“先定字段清单、再写字段含义、后配填写示例与附件规则”的顺序推进，最后用一份检查表验证说明是否真的可用。本文给出可直接落地的字段清单表、字段含义条目写法、正反示例、附件要求与完成检查清单，并在字段落地环节说明ONES Desk的承载方式。
要点总览（TL;DR）
- 编写顺序按“字段清单—字段含义—填写示例—附件规则—完成检查”推进，先确定有哪些字段、哪些必填，再逐字段写清填写口径。
- 必填项的判断标准统一为“缺了它工单无法受理或无法分派”，其余按对处理效率的影响列为选填或条件必填。
- 每个字段按四要素写：字段含义、取值口径或格式、填写要求、常见错误；枚举字段写清选项边界，自由文本字段给出信息点与长度区间。
- 关键字段配合格与不合格示例对照，并标注不合格原因；附件写明典型情形、命名规则与敏感信息处理提示。
- 定稿前用检查清单验证：抽取退回工单核对字段覆盖、请未参与编写的同事试选枚举项、用真实工单试填并记录补问点。
一份可用的填写说明先定字段清单
填写说明的编写起点是字段清单，而字段清单的来源是工单在受理、分派、处理、回访各环节实际需要的信息。建议由受理人牵头，把一张工单从提交到关闭的流程走一遍，逐环节记录“处理人需要知道什么才能继续往下走”，再把这些信息点转成字段。这样得到的清单贴合业务，不会照搬其他团队的模板。
必填项的判断标准可以统一为一条：缺了它，工单无法受理或无法分派。例如服务对象、问题现象、发生时间、联系方式通常属于此类；期望完成时间、参考截图等字段缺失时工单仍可流转，可列为选填。介于两者之间的字段可设为条件必填，例如选择“系统故障”类型时才要求填写系统名称与版本。
划分结果建议用一张表呈现，让提单人和受理人一眼看清每个字段由谁填、从哪里取值。表格列至少包含字段名、是否必填、填写对象、取值来源与用途，其中“用途”一列说明该字段支撑哪个环节，便于后续评审时判断字段是否该保留。
| 字段名 | 是否必填 | 填写对象 | 取值来源 | 用途 |
|---|---|---|---|---|
| 服务对象/系统名称 | 必填 | 提单人 | 从系统清单中选择 | 分派到对应支持组 |
| 问题现象 | 必填 | 提单人 | 文字描述 | 受理判断与初步定位 |
| 发生时间 | 必填 | 提单人 | 日期时间选择 | 关联变更记录、排查时间线 |
| 紧急程度 | 必填 | 提单人 | 枚举选项 | 确定响应优先级 |
| 联系方式 | 必填 | 提单人 | 自动带出或手填 | 处理过程中的沟通 |
| 期望完成时间 | 选填 | 提单人 | 日期选择 | 排期参考 |
| 附件 | 条件必填 | 提单人 | 截图、日志、录屏 | 复现与定位 |
字段清单定稿后，再进入逐字段的含义编写。清单阶段只回答“有哪些字段、哪些必填”，字段怎么写清楚留到下一步处理，避免两件事混在一起反复修改。
字段含义怎么写：每个字段的四要素
字段含义条目建议统一为四要素：字段含义、取值口径或格式、填写要求、常见错误。四要素齐全，提单人才能照着填；只写字段名不写要求，说明就起不到指导作用。每个字段按同一结构排列，也方便后续维护时逐条核对。
枚举型字段写清选项边界
工单类型、影响范围、紧急程度这类枚举字段，难点在选项之间的边界。写法上要为每个选项给出判断依据，而不是只列选项名称。例如紧急程度可写成：紧急指业务中断且无替代方案；高指主要功能不可用但存在临时绕行方式；中指部分功能异常不影响主流程；低指咨询、建议或体验问题。影响范围则明确按受影响人数或部门数量划分区间，避免“很多人”“少量”这类模糊表述。
自由文本字段给出颗粒度
问题描述、复现步骤等自由文本字段，要写明应包含的信息点和大致长度。例如问题描述要求包含“做了什么操作、看到什么结果、期望什么结果”三个信息点，建议控制在100至300字；复现步骤要求按顺序编号，每步一个动作，能让他人照着重现。给出信息点和长度区间，比只写“请详细描述”更能约束颗粒度。
标注字段之间的依赖关系
字段之间存在依赖时要在条目中写明。例如选择“系统故障”类型后，系统名称与版本变为必填；选择“账号问题”后，需填写账号与所属部门。依赖关系写成“当A取某值时，B必填”，并说明原因，让提单人理解为什么多填一项，减少抵触和漏填。
| 要素 | 写法要求 | 示例（问题描述字段） |
|---|---|---|
| 字段含义 | 一句话说明该字段收集什么信息 | 描述故障或请求的具体表现 |
| 取值口径/格式 | 说明格式、长度或选项边界 | 100–300字，包含操作、结果、期望三点 |
| 填写要求 | 说明必须做到的动作 | 按时间顺序写，不使用“坏了”“不行”等笼统词 |
| 常见错误 | 列出高频不合格写法 | 只写“系统打不开”，未说明哪个页面、什么报错 |
填写示例：用正反例说明颗粒度
规则条文说明“应该怎样”，示例说明“写到什么程度算合格”。示例优先选取标题、问题描述、复现步骤、影响范围这几个决定受理效率的字段，每个字段配一组合格与不合格的对照，并标注不合格的原因。
| 字段 | 合格示例 | 不合格示例 | 不合格原因 |
|---|---|---|---|
| 标题 | 报销系统提交单据后提示“审批流未配置”，无法提交 | 系统有问题 | 未说明系统、操作与报错，受理人无法判断归属 |
| 问题描述 | 在报销系统填写差旅报销单，点击提交后弹出“审批流未配置”，连续三次均如此，其他同事可正常提交 | 报销提交不了 | 缺少操作路径、报错原文和影响范围 |
| 复现步骤 | 1.登录报销系统；2.新建差旅报销单并填写金额；3.点击提交；4.出现报错弹窗 | 就是提交的时候出错 | 步骤不可照做，无法复现 |
| 影响范围 | 本人所在财务部5人均无法提交，其他部门未反馈 | 很多人都用不了 | 未给出人数与部门，无法评估优先级 |
示例要与字段含义条目一一对应，字段条目里提到的信息点，在合格示例中都能找到对应内容。标注不合格原因时写具体缺失了什么，避免只写“描述不清”。示例中的系统名、报错文案可按团队实际情况替换，保持结构不变即可。
附件与补充信息的填写要求
附件用于承载文字难以说清的信息。典型情形包括：报错截图（需包含完整报错文案与页面地址）、系统日志（注明时间范围）、操作录屏（完整展示从进入到出错的过程）、配置信息（导出相关配置项）。说明中应逐类列出这些情形，让提单人知道什么时候该附、附什么。
附件命名要有最小要求，建议采用“工单主题_内容类型_日期”的结构，例如“报销提交报错_截图_20240612”，便于受理人检索与归档。内容上要求截图清晰可读、日志包含出错时间点前后的记录、录屏不超过必要长度。涉及账号、身份证号、客户信息等敏感内容时，提示先做遮挡或脱敏再上传。
无法提供附件时，要给出替代说明方式。例如现场无法截图，可写明“报错文案为……，出现时间为……，操作路径为……”，用文字补齐关键信息；日志无法导出时，说明系统限制并注明可协助远程查看的时间段。这样受理人仍能获得定位所需线索，不会因缺附件而退回。
角色分工与说明的发布维护
填写说明涉及三类角色：编写人负责起草字段清单与含义条目，通常由受理团队负责人或服务台主管担任；审核人负责确认字段是否覆盖受理与分派所需信息，可由处理团队代表担任；执行人是提单人与受理人，按说明填写与核对。职责写清楚，说明才不会写完就搁置。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 编写人 | 起草字段清单、含义条目、示例与附件要求 | 填写说明初稿 |
| 审核人 | 核对字段覆盖度与取值口径，确认可执行 | 审核意见与定稿 |
| 提单人 | 按说明填写工单，附齐必要材料 | 完整工单 |
| 受理人 | 按说明核对必填项，退回不合规工单并说明原因 | 受理记录与退回意见 |
说明的存放位置要与提单入口关联，让提单人在填表时能直接看到。常见做法是把说明放在提单页面的帮助入口，或在表单顶部放置关键字段的简短提示，完整版说明单独成文。字段发生增删或选项调整时，同步更新说明的触发条件可设为：表单字段变更、工单退回率上升、新增服务类型上线。每次更新记录版本与变更点，便于追溯。
新成员上手时，可安排其先阅读说明，再用一张历史工单试填，由受理人对照说明指出偏差。这比口头传授更快形成一致的填写习惯。若团队使用ONES Desk承载工单，其自定义工单属性与工单内容配置可用于把字段清单落到表单上，统一门户集中接收工单，表单配置完成后可分享填写链接供提单人使用；具体可配置的字段类型与校验方式以实际版本为准，落地前需核验。
完成检查：说明是否真的可用
说明定稿前，用一份检查清单逐项核对，确认提单人仅凭说明就能独立写清一张工单。检查以“能否执行”为标准，不以文字是否完整为标准。
- 字段清单是否覆盖受理与分派所需信息：随机抽取近期的退回工单，检查退回原因是否都能对应到清单中的字段。
- 每个必填字段是否都有含义、取值口径与示例：逐条比对，缺任何一项即视为未完成。
- 枚举字段的选项边界是否可判断：请一位未参与编写的同事仅凭说明为三个场景选择紧急程度，结果一致即通过。
- 附件要求是否可执行：检查命名规则、内容要求、脱敏提示是否具体到能照做。
- 用一张真实工单做试填验证：由提单人按说明填写，受理人记录需要补问的信息点，补问超过两处则回到对应字段修订。
- 观察退回率与补问情况：说明上线后统计一段时间内的退回原因分布，集中出现的字段优先修订含义条目或补充示例。
检查通过后即可发布。后续把退回原因分布作为说明迭代的输入，字段规则与示例随业务变化同步调整，填写说明才能持续支撑工单受理效率。
常见问题
必填项设得太多，提单人嫌麻烦怎么办？
先回到判断标准：缺了它工单是否真的无法受理或无法分派。按这条标准逐项复核，把只影响处理便利、不影响流转的字段降为选填或条件必填。条件必填是折中办法，例如只有选择“系统故障”类型时才要求填系统名称与版本，提单人在多数场景下不会被额外字段拦住。
另一个做法是把长文本字段拆成几个短问题，例如把“问题描述”拆成“做了什么操作”“看到什么结果”“期望什么结果”三栏，填写负担分散后，提单人更愿意填完整。
字段含义条目和填写示例，哪个先写？
先写字段含义条目，再写示例。含义条目确定字段收集什么信息、取值口径和填写要求，示例是在这个口径下给出的合格与不合格对照。顺序反过来容易出现示例与规则对不上，维护时也不知道该改哪一处。
写完示例后回头核对一遍：字段条目里提到的信息点，在合格示例中是否都能找到对应内容。找不到就补示例，条目本身有歧义就改条目。
说明上线后，怎么判断哪些字段需要修订？
把工单退回原因和受理时的补问记录作为主要输入。统计一段时间内的退回原因分布，集中出现在某几个字段上，说明该字段的含义条目或示例没有约束住颗粒度，优先修订这几处。
字段本身发生增删、枚举选项调整或新增服务类型上线时，也要同步更新说明。每次更新记录版本与变更点，便于追溯哪一版说明对应哪一版表单。
附件要求写成“请提供相关截图”够不够？
不够。“相关截图”没有给出可执行的标准，提单人不知道截什么、截到什么程度。附件要求应逐类写明典型情形，例如报错截图需包含完整报错文案与页面地址，日志需注明时间范围，录屏需完整展示从进入到出错的过程。
同时给出命名规则和敏感信息处理提示，并说明无法提供附件时的替代写法，例如用文字补齐报错文案、出现时间和操作路径。这样受理人仍能拿到定位线索。
用ONES Desk承载工单表单时，字段清单怎么落地？
ONES Desk支持自定义工单属性与工单内容配置，可用于把字段清单落到表单上；统一门户集中接收工单，表单配置完成后可分享填写链接供提单人使用。落地时按说明中的字段清单逐项配置，枚举字段的选项与说明中的边界保持一致。
具体可配置的字段类型与校验方式以实际版本为准，落地前需核验。若需把工单与研发工作项关联跟踪，ONES Desk支持工单一键关联到ONES Project的需求或缺陷工作项，该能力需同时使用ONES Project。
