工单提单字段的条件必填，要解决的问题是“什么时候必须填”。设计时先按工单类型和影响范围确定基础必填字段，再用字段值、角色、阶段三类条件控制其余字段，并为每条规则配好提示文案和兜底选项。本文给出规则写法、角色分工、落地示例和上线后的验证方法。
要点总览（TL;DR）
- 先按工单类型确定基础必填字段，判断标准是缺了无法分派或无法复现，其余字段再用条件控制。
- 条件必填分三类触发：字段值触发、角色触发、阶段触发，每条规则按“条件—目标字段—提示文案—兜底选项”四要素表达。
- 提示文案要说明为什么需要该信息，并为提单人难以确认的字段提供“暂不清楚”“待补充”等兜底选项及后续补齐动作。
- 规则维护明确服务台负责人、表单配置人员、处理团队代表的职责，变更走评审并保留版本记录。
- 上线后用漏填率与误拦率验证效果，并观察必填过多导致提单中断的信号，据此定期复核修订。
先定字段清单：哪些字段无条件必填
条件必填建立在基础必填之上。如果所有字段都挂条件，提单人面对的就是一张随时变化的表单，规则也难以维护。第一步应先把“缺了就办不下去”的字段固定下来，不依赖任何条件。
基础必填字段的判断标准有两条：缺了无法分派，缺了无法复现。无法分派指服务台拿到工单后不知道交给谁、按什么优先级处理，例如工单类型、影响范围、提交人及联系方式。无法复现指处理人拿到工单后无法还原问题现场，例如故障现象、发生时间、涉及的系统或产品模块。满足其中一条即可列入基础必填；两条都不满足的字段，先放可选，确有需要再用条件触发。
基础必填要按工单类型分别确定，不能全类型共用一张清单。故障报修类通常需要影响范围和故障现象；账号权限类需要所属组织、申请权限项；咨询类可能只需要问题描述和联系方式。同一字段在不同类型下也可能一个必填、一个可选，例如“涉及系统”对故障类必填，对一般咨询可选。
这项工作建议由服务台负责人牵头，处理团队代表参与，表单配置人员记录结果。输入是现有工单类型清单和近三个月的工单样本，动作是逐类型标注“缺了会怎样”，输出是一份按工单类型划分的基础必填字段清单，完成标志是每个字段都能对应到“无法分派”或“无法复现”中的至少一条理由。
条件必填的三类触发方式与规则写法
基础必填之外，其余字段用条件控制。常见的触发方式有三类，可以单独使用，也可以组合使用。
字段值触发：依据提单人已填内容追加必填。例如问题类型选择“系统故障”后，“故障发生时间”和“影响用户范围”变为必填；选择“功能咨询”则不触发。这类条件最容易配置，也最容易被提单人理解，适合把字段与问题类型绑定。
角色触发：依据提交人身份决定字段要求。例如提交人为外部用户或非本组织人员时，要求填写联系电话和所属单位，便于处理人回访确认；内部员工提交时可省略。角色触发要注意身份判断口径要唯一，避免同一人因入口不同被判定为不同角色。
阶段触发：依据工单所处流程节点补齐信息。例如工单从“待受理”流转到“处理中”之前，要求处理人补齐环境信息、复现步骤或附件。阶段触发约束的是处理侧动作，适合把排查所需信息放在真正需要它的节点，而不是全部压给提单人。
每条规则建议按四要素表达，便于评审和配置：条件、目标字段、提示文案、兜底选项。下表给出可直接照写的规则表结构。
| 条件 | 目标字段 | 提示文案 | 兜底选项 |
|---|---|---|---|
| 问题类型 = 系统故障 | 故障发生时间 | 请填写首次发现故障的时间，用于判断影响时段 | 暂不清楚（提交后由处理人回填） |
| 提交人 = 外部用户 | 联系电话、所属单位 | 便于处理人回访确认问题，请留下可联系的方式 | 无，需如实填写 |
| 流程阶段 = 处理中（流转前） | 复现步骤、环境信息 | 请补充复现步骤，帮助定位问题原因 | 待补充（记录待办，24小时内补齐） |
规则表定稿后再进入表单配置。以ONES Desk为例，其支持自定义工单属性与工单内容配置，适配不同收集场景，也支持自定义处理流程，可承载按工单类型区分字段、按流程节点约束填写这类管理动作。条件必填的具体配置方式与字段校验能力，以实际产品版本为准。
校验提示怎么写才不逼用户乱填
必填校验只解决“拦不拦得住”，提示文案解决“填得对不对”。如果提示只写“此项必填”，提单人最省力的做法就是随便填一个字符通过校验，后续处理反而更慢。
提示文案应说明为什么需要这条信息，以及它会被用来做什么。例如“请填写故障发生时间，用于判断影响时段和响应优先级”，比“请填写发生时间”更能让提单人理解填写价值。文案长度控制在一句话内，放在字段下方或校验失败时就地提示，避免集中弹窗打断填写。
对提单人确实可能不知道的字段，要提供兜底选项，并约定后续处理方式。“暂不清楚”“待补充”这类选项不能只是让校验通过，必须挂接后续动作：选择“暂不清楚”的工单打上待补充标记，由处理人在首次响应时回填；选择“待补充”的进入待办清单，设定补齐时限。兜底选项适用于提单人难以当场确认的信息，对分派必需且提单人应当知道的字段，仍应要求如实填写。
表单呈现上，必填字段用统一标记并在表单顶部说明标记含义，条件触发的字段在触发后即时出现并高亮，避免用户填完才发现多出字段。选填字段与必填字段在视觉上保持区分，但不要用过多颜色和图标制造干扰。
角色分工与交付物：谁维护规则、谁审核效果
条件必填规则会随工单类型和流程变化而调整，需要有明确的维护角色，否则规则会越加越多、无人清理。
| 角色 | 职责 | 主要交付物 |
|---|---|---|
| 服务台负责人 | 提出字段需求，判断字段对分派和响应的必要性，组织规则评审 | 基础必填字段清单、规则变更申请 |
| 表单配置人员 | 将规则表转为表单配置，维护字段与条件的对应关系，执行发布 | 条件必填规则表、配置变更记录 |
| 处理团队代表 | 从排查和复现角度提出字段要求，验证提示文案是否可理解 | 字段需求说明、上线后反馈 |
规则变更走评审与发布两步。变更申请需写明触发场景、新增或调整的字段、影响的工单类型，由服务台负责人和处理团队代表共同确认必要性，表单配置人员评估对现有表单的影响后发布。涉及基础必填字段增减的变更，应同步通知提单入口的使用方。
规则版本与变更记录至少包含：变更日期、变更人、涉及字段、变更前后条件、生效范围、回滚方式。记录随表单配置一起留存，便于出现漏填或误拦时追溯是哪次变更引入的。ONES Desk 的自定义字段与流程配置可作为规则承载的基础，变更记录可随工单配置文档一并管理。
示例：一条条件必填规则从设计到上线
以下为演示情景，用于说明一条规则的完整落地过程。
场景：某内部服务台发现“系统故障”类工单中，约三成缺少故障发生时间，处理人需要逐个回访确认，响应时间被拉长。服务台负责人提出将“故障发生时间”设为条件必填。
规则设计：条件为“问题类型 = 系统故障”，目标字段为“故障发生时间”，提示文案为“请填写首次发现故障的时间，用于判断影响时段和响应优先级”，兜底选项为“暂不清楚”，选择后工单标记待补充，由处理人在首次响应时回填。规则经处理团队代表确认后，由表单配置人员写入规则表并配置到提单表单。
上线后抽样检查的观察点包括：系统故障类工单中该字段的填写率是否上升；“暂不清楚”的选择比例是否异常偏高，偏高说明提示或字段位置需要调整；处理人回填待补充信息的平均时长；是否有提单人反馈字段难以理解。抽样建议覆盖上线后前两周的工单，按工单类型分层抽取。
完成检查：用漏填率与误拦率验证设计
规则上线后要用数据判断是否达到减少信息不全的目标，重点看两个指标。
漏填率：在应填该字段的工单中，字段为空或仅填兜底选项的比例。取数口径为“触发条件的工单数”作分母，“字段为空或选暂不清楚”的工单数作分子，按工单类型和字段分别统计。漏填率持续偏高，说明触发条件过宽、提示不清或兜底选项被滥用。
误拦率：本不应触发必填却被要求填写的工单比例，以及因校验失败导致提交中断的比例。前者通过抽查触发条件的判定是否准确来估算，后者可从表单提交失败记录中统计。误拦率上升通常意味着条件写得过粗，例如按角色触发时身份判断口径不唯一。
还要观察必填字段过多导致提单中断的信号：表单填写时长明显变长、提交中途放弃比例上升、提单人集中反馈字段太多。出现这些信号时，优先把非分派必需的字段从基础必填降为条件必填，或移到处理阶段补齐。
规则定期复核的触发条件建议包括：工单类型新增或合并、处理流程节点调整、漏填率连续两个月高于设定阈值、误拦率出现明显上升、处理团队反馈字段与实际排查不匹配。复核输出为规则表的修订版本和变更记录，形成“设计—上线—观测—修订”的闭环。
常见问题
基础必填字段和条件必填字段的边界怎么划？
用“缺了会怎样”来判断。缺了无法分派（如工单类型、影响范围、提交人及联系方式）或无法复现（如故障现象、发生时间、涉及系统）的字段，列入基础必填，不挂条件。两条都不满足的字段先放可选，确有需要再用条件触发。基础必填按工单类型分别确定，同一字段在不同类型下可以一个必填、一个可选。
条件必填规则写好后，怎么判断触发条件是否过宽？
看两个信号：一是应填字段的漏填率是否持续偏高，偏高说明触发条件过宽或提示不清；二是误拦率，即本不应触发却被要求填写的工单比例是否上升。误拦率上升通常意味着条件写得过粗，例如按角色触发时身份判断口径不唯一。发现后优先收窄触发条件，或把非分派必需的字段移到处理阶段补齐。
兜底选项会不会变成新的信息缺失来源？
会，如果兜底选项只让校验通过而没有后续动作。设计时要给每个兜底选项挂接处理方式：选择“暂不清楚”的工单打上待补充标记，由处理人在首次响应时回填；选择“待补充”的进入待办清单并设定补齐时限。同时观察兜底选项的选择比例，异常偏高说明提示文案或字段位置需要调整。对分派必需且提单人应当知道的字段，仍要求如实填写。
阶段触发和字段值触发能同时用在一个字段上吗？
可以，但要避免同一字段被多条规则重复约束导致提示混乱。建议明确主触发方式：提单人当场能提供的信息用字段值触发或角色触发，在提单环节收集；需要处理人排查后才能确认的信息用阶段触发，在流转到处理中前补齐。同一字段若两处都要求，应在规则表中注明以哪条为准，并在表单上只呈现一次提示。
规则上线后多久复核一次比较合适？
建议按事件触发加定期复核结合。事件触发包括工单类型新增或合并、处理流程节点调整、处理团队反馈字段与实际排查不匹配；定期复核可观察漏填率连续两个月高于设定阈值、误拦率明显上升等情况。复核输出为规则表的修订版本和变更记录，涉及基础必填字段增减时同步通知提单入口的使用方。
