编写工单信息填写说明，核心是让提单人一次把服务请求说清楚。建议按“字段表＋示例＋附件清单＋提交前自查”四块组织：先确定要收集哪些字段、哪些必填，再为每个字段写清含义和可直接照抄的示例，最后用附件要求承接截图、日志等文字字段装不下的信息。下面按编写顺序展开，并给出一份可参照改写的文档片段。
要点总览（TL;DR）
- 先定结构再填内容：按“字段表＋示例＋附件清单＋提交前自查”四块组织，编写顺序与文档呈现顺序一致。
- 字段清单从服务请求类型出发筛选，按“缺了就处理不了”判定必填，条件必填必须写清触发条件，字段数量按类型分别控制。
- 每个字段条目写全“字段名称、含义、取值口径、示例”四要素；示例分字段级正例、反例和整单场景示例三层，正例要能直接照抄进表单。
- 附件要求写明信息类型、格式与大小约束、命名规则和提交时点；说明文档定稿后与工单系统表单配置逐项核对。
- 发布前用试填验证收尾：让常提单人员独立按文档填一份模拟工单，卡住的位置就是需要补充说明的地方。
说明文档先定结构：字段表、示例、附件清单、自查项
填写说明的读者是提单人，他们在提交工单时边看边填。文档结构要服务于这个动作：先告诉他们要填什么，再示范怎么填，再说明哪些内容用附件交，最后给一份提交前的核对清单。四块内容按以下顺序编写，也按这个顺序在文档中呈现。
| 板块 | 作用 | 编写顺序 | 在文档中的位置 |
|---|---|---|---|
| 字段表 | 列出全部字段、必填规则和填写要求 | 第一步：先定字段清单与必填规则 | 正文主体，按字段分组排列 |
| 示例 | 示范每个关键字段怎么填，以及一整单怎么填 | 第二步：字段含义定稿后逐条配示例 | 紧跟字段表，或与字段表合并为一张宽表 |
| 附件清单 | 说明哪些信息必须用附件提交、怎么命名 | 第三步：文字字段定稿后补齐 | 字段表之后独立一节 |
| 提交前自查 | 让提单人在点提交前逐项核对 | 第四步：前三块完成后收尾编写 | 文档末尾，可做成勾选清单 |
字段表与示例要一一对应：字段表里出现的每个关键字段，示例部分都要有对应条目，编号或字段名保持一致，避免提单人在两张表之间来回找。附件清单与自查项是落点：附件清单承接字段表无法承载的信息，自查项则把字段规则和附件要求压缩成提单人提交前能快速过一遍的条目。编写时先完成字段表，再写示例，最后写附件与自查，这样每一块都有前一块作为依据。
字段清单与必填规则怎么定
字段清单从服务请求类型出发筛选，而不是把所有能想到的信息都塞进表单。先列出企业实际会收到的工单类型，例如账号权限申请、系统故障报修、数据查询、功能使用咨询，再逐类回答一个问题：处理这类请求时，处理人必须知道哪些信息才能开始处理。答案构成该类工单的字段清单。
必填规则按以下口径判定：
- 必填：缺少该字段，处理人无法定位问题或无法开始处理。例如故障类工单的影响范围、发生时间、涉及系统。
- 条件必填：只在特定取值下才要求填写，必须写清触发条件。例如“问题类型选择‘数据错误’时，数据来源系统必填”。
- 选填：有助于加快处理但不影响受理的信息，例如期望完成时间、相关历史工单编号。
控制字段数量是这一步的关键约束。字段越多，提单人中途放弃或随意填写的概率越高。可以用三条规则压缩：同一信息只保留一个字段，避免“问题描述”和“详细说明”并存；能从系统带出的信息（提交人、提交时间、所属部门）不设手工字段；只有处理人真正会看、会用来判断的字段才保留。字段总数建议按工单类型分别控制，复杂类型可适当增加，简单咨询类保持精简。
字段清单定稿后，形成一张表，至少包含字段名称、是否必填、适用工单类型、填写要求四列，作为后续编写字段含义和配置表单的共同依据。
字段含义怎么写才不留歧义
每个字段条目按“字段名称、含义、取值口径、示例”四要素写，四者缺一都会留下理解空间。含义说明这个字段收集什么信息；取值口径说明允许填什么、以什么格式填；示例给出一条可直接照抄的写法。
| 要素 | 写什么 | 反例 | 正例 |
|---|---|---|---|
| 字段名称 | 与表单上的标签完全一致 | “问题情况” | “故障现象描述” |
| 含义 | 一句话说明收集目的 | “描述你的问题” | “说明系统出现的异常表现，供处理人判断故障范围” |
| 取值口径 | 格式、长度、可选值、时间口径 | “填写时间” | “填写问题首次发生的日期和时间，精确到分钟，格式为YYYY-MM-DD HH:MM” |
| 示例 | 一条完整、真实的填写内容 | “如：登录不了” | “2025-03-12 09:20 起，使用Chrome浏览器登录报销系统，输入账号密码后页面停留在加载状态，刷新无效” |
易混淆字段要单独写区分说明。常见的有“故障现象”与“期望结果”、“影响范围”与“影响人数”、“发生时间”与“发现时间”。写法是在含义中直接点明区别，例如“影响范围填写受影响的业务模块或系统名称；影响人数填写受影响的用户数量，两者分别填写”。条件必填字段要在条目中写明触发条件，例如“当问题类型为‘权限申请’时必填，填写需要开通的系统名称和权限角色”。
取值口径尽量给出封闭选项或明确格式。能用下拉选项的字段，在说明中列出全部选项及各自含义；需要自由填写的字段，给出格式模板和字数建议。这样提单人不需要猜测处理人的偏好。
填写示例怎么组织：正例、反例与场景示例
示例分三层组织，分别解决不同问题。
字段级正例：每个关键字段配一条可直接照抄的示例，放在字段条目内或紧随字段表之后。正例要包含真实的时间、系统名称、操作步骤等具体信息，避免“如上所述”“详见附件”这类无法独立成立的写法。
字段级反例：用反例点出常见含糊写法，并紧跟一句修改建议。反例的价值在于让提单人识别自己习惯的写法为什么不够用。例如：
- 反例：“系统有问题，麻烦处理一下。”修改建议：写明哪个系统、什么操作、出现什么现象、从什么时候开始。
- 反例：“很急，尽快。”修改建议：说明业务影响，例如“影响月末结账，需在当日完成”。
整单场景示例：按典型服务请求类型各给一份完整填写示范，覆盖字段表中的全部必填项和常见条件必填项。场景示例让提单人看到各字段如何组合成一份完整描述，比逐字段示例更接近实际填写体验。建议选择发生频率最高的两到三类请求各写一份，例如一次故障报修、一次权限申请。
示例编写完成后，检查每条正例能否被直接复制进表单而不需要补充信息，这是判断示例是否合格的最直接标准。
附件要求怎么写：类型、命名与提交时点
附件承接文字字段装不下的信息。先明确哪些信息必须用附件提交，再写格式、命名和提交时点。
| 信息类型 | 典型内容 | 提交要求 |
|---|---|---|
| 界面截图 | 报错页面、异常状态、操作入口 | 截取完整窗口，包含报错文字和浏览器地址栏；多步操作按顺序编号 |
| 日志文件 | 系统日志、接口返回、错误堆栈 | 提交原始文件，截取关键时间段，注明日志对应的时间范围 |
| 复现步骤录屏 | 可稳定复现的操作过程 | 从登录开始连续录制，包含最终异常画面 |
| 业务单据 | 申请单、审批记录、数据导出文件 | 提交与本次请求直接相关的文件，去除无关内容 |
格式与大小约束按企业实际系统能力写明，例如“截图使用PNG或JPG格式，单张不超过5MB；日志打包为ZIP后上传”。约束要写成提单人能直接执行的规则，并说明超出限制时的处理方式，例如压缩后分卷上传或联系服务台。
命名规则让处理人无需打开文件就能判断内容。推荐结构为“工单主题_文件内容_日期”，例如“报销系统登录异常_报错截图_20250312”。同一工单多个附件按顺序加序号。提交时点写清楚：截图和日志在首次提交时一并上传；复现录屏在提单后补充的，需在工单中说明补充时间，便于处理人对应查看。
在工单系统中落地时，字段与附件要求需要与实际表单配置保持一致。ONES Desk 支持自定义工单属性和工单内容配置，可按不同收集场景设置字段；通过门户分享填写链接收集请求时，提单人看到的表单即为说明文档所描述的表单。说明文档定稿后，应同步核对系统表单的字段名称、必填设置与文档一致，避免文档写一套、系统填一套。
角色分工与交付物：谁写、谁审、谁维护
填写说明涉及业务规则和系统配置两方面，需要明确分工，否则容易出现字段改了文档没改的情况。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 文档编写人 | 按四块结构起草说明，统一表述风格，维护字段表与示例的对应关系 | 填写说明初稿与修订稿 |
| 业务字段提供方 | 按工单类型提供字段清单、必填判断依据和取值口径 | 各类型工单的字段需求说明 |
| 服务台或工单处理负责人 | 评审字段是否覆盖实际处理所需信息，示例是否贴近真实工单 | 评审意见与修改确认 |
| 系统配置人员 | 核对文档与工单系统表单配置一致，包括字段名称、必填设置、附件限制 | 配置核对记录 |
| 文档维护人 | 接收变更触发，更新文档并通知提单人 | 版本记录与变更通知 |
评审要点集中在三处：字段是否覆盖处理人实际需要的信息；必填与条件必填的判定是否有依据；示例是否可以直接照抄。评审时建议抽取近期真实工单，对照说明检查是否存在按文档填写仍无法处理的情况。
版本更新触发条件要写进文档维护机制，常见触发包括：新增工单类型、字段增删或必填规则调整、附件格式或大小限制变化、工单系统表单改版。每次触发后由维护人更新对应板块，并在文档中记录版本号和变更内容，便于提单人识别当前有效版本。
一份完整的工单信息填写说明示例
以下片段以“系统故障报修”类工单为例，示范字段表、示例与附件要求的组合方式，可直接参照改写。
字段表片段
| 字段名称 | 必填规则 | 含义 | 取值口径 |
|---|---|---|---|
| 涉及系统 | 必填 | 出现故障的业务系统名称 | 从下拉列表选择；多个系统时选择主要受影响系统，其余在描述中说明 |
| 故障现象描述 | 必填 | 系统出现的异常表现，供处理人判断故障范围 | 写明操作步骤、页面表现和报错文字，100字以上 |
| 首次发生时间 | 必填 | 问题第一次出现的时间 | 格式YYYY-MM-DD HH:MM，精确到分钟 |
| 影响范围 | 条件必填 | 受影响的业务或用户群体 | 问题类型为“系统不可用”时必填，写明受影响部门和大致人数 |
| 期望完成时间 | 选填 | 业务上希望恢复的时间 | 填写日期，并说明时间要求的原因 |
字段示例片段
- 故障现象描述正例：“2025-03-12 09:20 起，使用Chrome浏览器打开报销系统‘我的单据’页面，列表一直显示加载中，控制台提示接口超时；换用Edge浏览器现象相同，其他同事可正常打开。”
- 故障现象描述反例：“报销系统坏了，打不开。”修改建议：补充操作入口、页面表现、报错信息和影响人数。
- 影响范围正例：“财务部约15人无法提交报销单，影响本周费用报销。”
附件要求片段
- 报错页面截图：必传，截取包含报错文字的完整窗口，命名“报销系统加载异常_报错截图_20250312”。
- 浏览器控制台日志：出现接口报错时必传，导出为TXT文件，注明截取时间段。
- 格式与大小：截图使用PNG或JPG，单张不超过5MB；日志打包为ZIP上传。
提交前自查项
- 涉及系统已从下拉列表选择，故障现象写明了操作步骤和报错文字。
- 首次发生时间精确到分钟。
- 问题类型为“系统不可用”时，影响范围已填写。
- 报错截图已按命名规则上传，日志文件已附上。
发布前的完成检查
说明文档写完不等于可用。发布前按以下清单逐项核对，每项都要有明确的通过标准。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 字段覆盖 | 每类工单的字段清单是否覆盖处理人实际需要的信息 | 抽取近期真实工单，按文档字段可完整描述请求 |
| 必填规则一致性 | 字段表中的必填、条件必填与工单系统表单设置是否一致 | 逐字段比对，名称、必填状态、触发条件完全对应 |
| 示例可照抄性 | 每条正例能否直接复制进表单而不需补充 | 由未参与编写的人员照抄填写，无需追问即可提交 |
| 附件要求可执行 | 格式、大小、命名规则是否明确，超出限制时是否有处理方式 | 按说明准备附件一次通过，无需返工 |
| 试填验证 | 邀请2至3名常提单人员按说明完成一次试填 | 试填过程中无需向编写人求助，处理人可依据填写内容开始处理 |
试填验证是最后一道关口。让试填人独立按文档填写一份模拟工单，记录他们卡住的位置和提出的疑问，这些位置就是文档需要补充说明的地方。试填通过后即可发布，并将版本号和生效日期写入文档开头，后续按维护机制更新。
常见问题
工单类型很多，字段清单要每类都单独写一份吗？
不必每类都从零写一份。可以先把工单类型归成几组，例如故障报修、账号权限申请、数据查询、使用咨询，组内共用大部分字段，只对差异字段单独说明。字段表里增加“适用工单类型”一列，同一字段在不同类型下必填规则不同时，分别标注。这样文档篇幅可控，提单人也能快速找到自己那一类。
类型数量多且差异大时，建议拆成主文档加分类附录：主文档写通用字段和整体规则，附录按类型补充专属字段与整单示例。
条件必填字段的触发条件写在字段表里还是字段含义里？
两处都要有，但写法不同。字段表的“必填规则”列用一句话写触发条件，例如“问题类型为‘数据错误’时必填”，让提单人扫表时就能判断自己要不要填；字段含义条目里再展开说明触发后具体填什么、按什么格式填。两处表述要保持一致，避免一处写“数据错误”、另一处写“数据异常”造成对不上。
条件必填字段最容易在系统配置时被漏掉，定稿后要单独列一份条件必填清单，交给系统配置人员逐条核对表单的联动设置。
附件要求里写的大小和格式限制，以什么为准？
以企业工单系统实际支持的配置为准，不凭经验写。编写前先确认系统对单个附件大小、单次上传数量、允许的文件类型有哪些限制，再把限制翻译成提单人能执行的规则，例如“截图使用PNG或JPG，单张不超过5MB；日志打包为ZIP上传”。
同时写明超出限制时的处理方式，例如压缩后分卷上传、截取关键时间段、联系服务台走其他渠道提交。只写限制不写退路，提单人遇到大文件时仍会卡住。
说明文档发布后，什么情况下需要更新？
常见触发有四类：新增工单类型；字段增删或必填规则调整；附件格式、大小限制变化；工单系统表单改版。任一触发发生后，由文档维护人更新对应板块，并在文档开头记录版本号和生效日期。
字段规则调整往往先发生在系统配置侧，建议把“表单配置变更时同步通知文档维护人”写进配置流程，避免文档写一套、系统填一套。更新后如涉及必填项变化，应通知常提单人员，必要时在门户填写页附上最新说明入口。
试填验证怎么做才算通过？
邀请2至3名经常提单、但没有参与文档编写的人员，在不向编写人提问的前提下，按说明独立填写一份模拟工单。记录他们停顿、犹豫和填错的位置，以及处理人看到这份工单后能否直接开始处理。
通过标准是：试填过程无需求助，填写内容包含处理所需的全部信息，附件按命名规则一次上传成功。卡住的位置回到对应板块补充说明，补充后由同一批试填人再走一遍关键字段即可，不必整份重测。
