需求提报信息不全，往往源于提报人不知道受理人需要什么，而非态度问题。把关键信息变成表单字段，用必填校验拦住缺口，用枚举和示例统一填写口径，再在受理前做一次完整性检查，就能显著减少来回沟通。本文聚焦提报环节的字段与检查设计，并说明这套机制如何在ONES的需求池与工单流转中承载。
要点总览（TL;DR）
- 从受理判断反推字段清单，把候选字段分为必填、选填、后补三类，首次提报的必填项控制在五到七个。
- 必填校验在提交时触发，提示文案写清缺什么、为什么需要、怎么填；需求类型、影响范围等字段用枚举统一口径，分支场景用条件必填。
- 受理前由受理人按固定检查项初筛，信息不全时改为“待补充”并记录退回原因分类，提报人补全后重新提交。
- 上线前组织五到十位真实提报人试填，上线后按周观察信息不全退回率、一次通过率和入口外提报情况，按月度或季度节奏调整字段。
先定最小信息集：哪些字段必须拦住
字段设计的第一步是确定范围，而非直接打开表单编辑器添加控件。有效做法是从受理判断反推：受理人拿到一条需求后，需要看到哪些信息才能决定是否受理、由谁承接、大致什么节奏？这些信息构成最小信息集，其余内容允许在受理后逐步补充。
把候选字段按三类划分，可以避免字段堆砌：
| 类别 | 判断标准 | 典型字段 | 处理方式 |
|---|---|---|---|
| 必填 | 缺少该项就无法判断是否受理或无法分派 | 提报人、业务场景、期望结果、影响范围、期望时间 | 提交时校验，不填不能提交 |
| 选填 | 有助于理解，但不影响受理决策 | 参考截图、相关系统、历史工单号 | 提供填写提示，不作强制 |
| 后补 | 受理后才具备填写条件或才有必要细化 | 验收标准、技术方案约束、排期确认 | 进入需求池后由需求负责人补充 |
最小信息集通常包含五项：提报人及其所属团队，用于确认来源和后续沟通；业务场景，说明在什么流程、什么角色身上发生；期望结果，描述希望达成什么状态；影响范围，涉及哪些用户、部门或系统；期望时间，给出希望解决的时间窗口或紧迫程度。这五项覆盖了受理人做初步判断的主要依据。
字段数量与提报完成率之间存在直接取舍。必填项每增加一个，提报人中途放弃或随意填写的概率都会上升。经验上，首次提报的必填字段控制在五到七个为宜，超过十个就需要审视是否把后补信息误设为必填。字段清单应由需求受理负责人牵头确认，产品经理、研发负责人和一线提报人代表参与评审，确认后形成版本记录，避免各入口口径不一。
本节交付物是一份分三类的字段清单草案：逐项列出字段名称、所属类别、填写角色和判断依据，作为后续配置校验和提示语的输入。
用必填校验和字段引导把口径写清楚
字段范围确定后，配置的目标是让提报人一次填对。必填校验解决“有没有填”，枚举、提示语和示例解决“填得对不对”，两者需要配合使用。
必填校验应在提交动作触发时执行，而非在页面加载时就标红。提示文案要写清三件事：缺了什么、为什么需要、应该怎么填。例如“请填写业务场景：说明该需求发生在哪个业务流程和角色上，受理人据此判断影响面”，比“此项为必填”更能减少无效提交。校验失败时保留已填内容，只定位到缺失字段，避免提报人重新填写整张表单。
能用枚举或单选表达的字段，尽量不用自由文本。需求类型、影响范围、紧急程度、涉及系统这类字段，选项本身就是在统一口径。自由文本适合描述场景和期望结果，但应配合结构化提示。以下字段适合改为枚举：
- 需求类型：新增功能、流程优化、缺陷修复、数据调整等固定分类；
- 影响范围：单角色、单部门、跨部门、全公司等层级选项；
- 紧急程度：结合期望时间给出明确档位，并说明各档位的响应预期；
- 涉及系统或模块：从已有系统清单中选择，避免名称写法不一。
提示语和填写示例要贴近业务语言。提示语说明填写目的，示例给出一个完整句子。例如期望结果字段的提示可写“描述希望达到的状态，而非实现方式”，示例写“财务在报销单提交后能自动看到预算余额，不需要再单独查询”。示例应来自真实业务场景并做脱敏处理，避免使用“某某功能优化”这类无信息量的占位内容。
条件必填与联动字段用于处理分支场景。当提报人选择“缺陷修复”类型时，展开复现步骤和影响版本字段并设为必填；选择“流程优化”时，展开当前流程描述字段。这样每位提报人只面对与自己相关的字段，既保证信息完整，又不抬高整体门槛。联动字段的规则要写在字段说明中，让提报人理解为什么某些选项会带出新的填写项。
校验过严会把提报人推向绕过入口。常见信号包括：提报人通过即时消息直接找产品经理、在非正式文档中记录需求、或反复填写“无”“暂无”应付必填项。出现这些情况时，应检查是否存在与受理决策无关的必填项，或提示语是否只说明了要求而没有说明用途。保留一个“暂不确定”选项并在受理环节跟进，通常比强制填写更有效。
受理前检查：谁在什么时点判断信息是否齐全
字段校验只能保证格式完整，不能保证内容可用。受理前需要一次人工完整性检查，明确谁在什么时点、按什么检查项判断，并规定信息不全时的回退动作。
角色分工可以按三个层次设置：
| 角色 | 检查时点 | 检查内容 | 输出 |
|---|---|---|---|
| 提报人 | 提交前 | 对照表单提示自检：场景是否具体、期望结果是否可判断、影响范围是否准确 | 完成提交 |
| 受理人 | 收到需求后一个工作日内 | 初筛五项最小信息是否可支撑受理判断，字段内容是否与选项口径一致 | 受理、退回补全或转交 |
| 需求负责人 | 受理后进入需求池前 | 确认业务价值、影响范围与期望时间是否匹配，补充后补字段 | 进入需求池或与提报人澄清 |
检查项应与字段清单一一对应，形成可勾选的检查表，避免受理人凭印象判断。检查时点要固定：受理人初筛宜设定时限，例如一个工作日内完成，防止需求在入口处积压；需求负责人确认可在需求评审或固定节奏的受理会上完成。
信息不全时的回退流程要写清动作和状态。受理人退回时，在系统中将需求状态改为“待补充”，并填写退回原因分类，例如“业务场景不具体”“影响范围缺失”“期望结果无法判断”。退回通知应直接指向需要补充的字段，提报人补充后重新提交，状态回到“待受理”。退回次数和补全时长应记录，作为后续调整字段和提示语的依据。
退回原因分类需要统一口径并保持稳定，否则统计结果无法比较。建议按字段维度设置分类，每个分类对应一到两条典型情形，每月汇总一次分布。若某一分类长期占比最高，说明对应字段的提示语或选项设计需要调整，而非提报人配合度问题。
示例：一条需求从提报到受理的字段流转
以下为演示情景，用于说明字段引导与检查如何衔接。某零售企业的门店运营人员提出需求：希望门店在盘点时能直接看到上一次盘点的差异记录。
提报阶段，提报人打开需求提报表单，填写提报人及所属门店，业务场景选择“月度盘点”，期望结果填写“盘点页面能查看上次盘点差异，减少重复核对”，影响范围选择“全部门店”，期望时间选择“本季度内”。需求类型选择“流程优化”后，系统联动展开“当前流程描述”字段并设为必填，提报人补充现有盘点核对方式。提交时，系统校验发现“影响范围”未选择，提示“请选择影响范围：用于判断改动涉及的门店数量与上线安排”，提报人补选后提交成功。
受理阶段，受理人在一个工作日内初筛，对照检查表发现期望结果描述清晰，但业务场景只写了“月度盘点”，未说明由哪个角色执行、在盘点流程的哪个环节查看。受理人将需求状态改为“待补充”，退回原因选择“业务场景不具体”，并在说明中写明需要补充的角色和环节。提报人收到通知后补充“门店店长在盘点录入完成后核对差异”，重新提交。
补全后，需求负责人确认影响范围与期望时间匹配，补充验收标准等后补字段，需求状态变为“已受理”并进入需求池，后续按需求池的整理与排序流程处理。整个过程中，字段校验拦住了格式缺口，人工检查拦住了内容缺口，退回原因记录则为后续优化“业务场景”字段的提示语提供了依据。
在ONES中，这类流程可以借助工单收集反馈并转化为需求，通过统一的需求池与自定义工作流承载状态流转，使提报、退回、补全和受理在同一处留痕。字段级校验与条件必填的具体配置方式，需结合团队实际使用的表单能力确认。
上线后的完成检查与持续调整
字段引导是否有效，需要在上线前和上线后用可观察的结果验证，而非凭填写体验判断。
上线前组织小范围试填，邀请五到十位真实提报人按近期实际需求填写，观察三件事：完成一条提报所需时间、中途卡住的字段、以及试填内容能否支撑受理判断。试填中发现的高频卡点，优先调整提示语和选项，其次考虑将字段改为选填或后补。
上线后重点观察以下指标，建议按周汇总：
- 信息不全退回率：退回需求数占提交需求数的比例，按退回原因分类查看；
- 一次通过率：首次提交即通过受理检查的比例；
- 平均补全时长：从退回到重新提交的时间；
- 入口外提报情况：通过即时消息或线下渠道直接提出的需求数量，用于判断表单门槛是否过高。
字段增删应有节奏和审批。建议以月度或季度为周期集中调整，每次调整基于退回原因分布和试填反馈，由需求受理负责人审批并记录变更说明。频繁零散修改会让提报人难以形成稳定预期，也会影响指标的可比性。
常见失效情形及纠正动作包括：退回率集中在某一字段，检查该字段提示语是否只写了要求未写用途；一次通过率持续偏低但退回原因分散，考虑减少必填项或增加“暂不确定”选项；入口外提报增多，复核必填字段是否超出受理决策所需；退回原因分类长期不变且分布均匀，说明分类口径过粗，需要细化到字段维度。按这些信号逐项核对，字段引导才能随业务变化保持有效。
常见问题
必填字段设得越多，提报信息就越全吗？
不一定。必填项增加会抬高提报门槛，提报人可能中途放弃、随意填写“无”“暂无”，或绕过表单直接找产品经理。判断标准是这项信息是否影响受理决策：缺少它就无法判断是否受理或无法分派，才设为必填；有助于理解但不影响受理的放选填；受理后才具备填写条件的放后补。首次提报的必填字段建议控制在五到七个，超过十个时应重新审视字段清单。
提报人反复用“无”“暂无”应付必填项，应该怎么处理？
先检查该字段是否真的属于受理决策所需，以及提示语是否只写了要求、没写用途。对确实存在“提报时不确定”情况的字段，可以增加“暂不确定”选项，由受理人在初筛环节跟进确认，比强制填写更有效。同时观察入口外提报的数量，如果即时消息或线下提出的需求明显增多，说明表单门槛偏高，需要减少必填项或调整提示语。
条件必填和联动字段适合哪些场景，配置时要注意什么？
条件必填适合需求类型存在明显分支的情况，例如选择“缺陷修复”时展开复现步骤和影响版本并设为必填，选择“流程优化”时展开当前流程描述。配置时要把联动规则写进字段说明，让提报人理解为什么某些选项会带出新的填写项；同时控制分支数量，避免提报人在填写过程中反复展开、收起，增加中途放弃的概率。
受理前检查由谁做，退回后怎么保证需求不丢失？
通常分三层：提报人提交前对照提示自检；受理人在收到需求后一个工作日内初筛五项最小信息；需求负责人在进入需求池前确认业务价值与期望时间是否匹配。退回时在系统中把状态改为“待补充”，填写退回原因分类并指向需要补充的字段，提报人补全后重新提交，状态回到“待受理”。退回次数和补全时长要记录，既保证需求可追溯，也为调整字段提供依据。
字段引导上线后，怎么判断措施是否有效？
上线前邀请五到十位真实提报人按近期实际需求试填，观察完成时间、卡住的字段以及试填内容能否支撑受理判断。上线后按周汇总信息不全退回率、一次通过率、平均补全时长和入口外提报数量。退回率集中在某一字段，优先改该字段的提示语或选项；退回原因分散且一次通过率持续偏低，考虑减少必填项；入口外提报增多，复核必填字段是否超出受理决策所需。
