设计需求提报入口，核心要解决两件事：让提报人用尽量少的字段把需求说清楚，让受理方按统一规则把需求送到正确的队列。本文围绕字段清单与分流规则展开，覆盖入口形态选择、必填与选填划分、三层判断链、角色责任和上线检查，范围限于需求进入机制；服务请求受理与已入池需求的整理不在本文展开。
要点总览（TL;DR）
- 最小必填集控制在七项以内：提报人及部门、需求标题、业务场景与问题描述、期望结果、影响范围、期望时间、需求类型初判，其余信息用选填字段和系统自动带出补充。
- 分流按三层判断链执行：先区分需求与服务请求、故障、咨询，再按需求类型与影响范围确定受理归口，最后按价值、紧急度与就绪度确定处理批次。
- 影响范围、需求类型初判、来源渠道等分流相关字段应使用受控枚举选项，每个选项配简短说明，新增选项经入口管理员审核后统一发布。
- 每条分流规则写明触发条件、判定人、目标队列和响应时限，并保留申诉与改判通道；入口管理员1个工作日内首次响应，受理人5个工作日内给出批次结论。
- 上线前用历史提报抽样回放验证规则覆盖度和冲突处理，试运行两到四周，按退回补充比例和第一层转出比例调整字段与规则。
统一入口先定形态：表单、批量导入与对接通道
入口形态决定提报人填写体验和后续数据质量，建议先确定载体，再设计字段。常见形态有三种，各自适用条件不同，但必须共用同一套字段定义和分流规则，否则同一类需求从不同通道进来会出现口径不一致。
| 入口形态 | 适用条件 | 主要优势 | 需要注意 |
|---|---|---|---|
| 在线表单 | 日常零散提报，提报人分散在多个部门 | 字段可校验、必填可控、提交即进入系统 | 表单过长会降低填写完成率，需控制必填数量 |
| 批量导入（表格模板） | 季度规划、调研汇总、历史需求迁移等成批收集场景 | 一次录入多条，便于线下集中整理 | 模板需锁定列名与选项值，导入前做格式校验 |
| 系统对接或邮件转单 | 已有客服、销售或监控系统产生反馈，需要汇入统一入口 | 减少人工二次录入，保留来源信息 | 需约定映射关系，缺失字段由入口管理员补齐 |
在线表单适合作为主入口，承担大部分日常提报；批量导入用于阶段性集中收集；系统对接和邮件转单作为补充通道，把外部来源的反馈纳入同一套字段体系。三种形态共用同一份字段清单和同一套分流规则，区别只在填写方式和校验强度。批量导入模板应把必填列设为不可为空，选项列使用与表单一致的下拉值；对接通道则需要在映射表中标明每个外部字段对应入口的哪个字段，无法映射的由入口管理员在受理前补录。
提报字段怎么定：必填、选填与自动带出
字段设计围绕五个问题展开：谁提、提什么、影响谁、多急、期望何时。最小必填集建议控制在七项以内，保证提报人能在几分钟内完成；其余信息通过选填字段和系统自动带出补充，避免因表单过长导致提报意愿下降。
| 字段 | 类型 | 作用 | 填写要求 |
|---|---|---|---|
| 提报人及所属部门 | 必填（登录后自动带出，可修改） | 确定反馈来源与后续沟通对象 | 部门使用组织架构选择，不用自由文本 |
| 需求标题 | 必填 | 一句话概括诉求，便于列表检索 | 建议不超过30字，写清对象和动作 |
| 业务场景与问题描述 | 必填 | 说明在什么场景下遇到什么问题 | 按“场景—现状—影响”三段式填写 |
| 期望结果 | 必填 | 描述希望达到的状态，作为验收参照 | 写可观察的结果，不写实现方案 |
| 影响范围 | 必填（受控选项） | 判断受理归口和处理批次 | 选项如单部门、多部门、全公司、外部客户 |
| 期望时间 | 必填 | 区分紧急程度，支撑排期判断 | 填写期望完成时间或时间窗口 |
| 需求类型初判 | 必填（受控选项） | 第一层分流的输入 | 选项如新功能、功能优化、数据报表、流程调整、其他 |
| 附件 | 选填 | 补充截图、文档、数据样例 | 限制格式与大小，敏感信息脱敏 |
| 参考链接 | 选填 | 关联已有文档或同类系统做法 | 填写可访问地址 |
| 关联客户或项目 | 选填 | 支撑影响范围判断和后续追溯 | 从已有客户或项目列表中选择 |
| 提报时间、提报人账号、来源渠道 | 自动带出 | 记录入口来源，支撑统计与追溯 | 系统生成，提报人不可编辑 |
受控词表是字段能否支撑分流的关键。影响范围、需求类型初判、来源渠道这类字段如果允许自由填写，受理人每次都要重新理解提报人的措辞，分流规则也无法自动触发。做法是把选项收敛为有限枚举值，每个选项配一句简短说明，并在表单上直接展示；新增选项需经入口管理员审核后统一发布，避免各部门自行扩展。需求标题和问题描述保留自由文本，但通过填写提示引导结构化表达。
字段与分流的关系体现在两处：需求类型初判和影响范围直接作为第一、二层分流的判定输入；期望时间和影响范围共同支撑第三层的批次判断。字段设计完成后，应逐项核对每个必填字段是否被至少一条分流规则使用，没有被使用的字段考虑降为选填，减少提报负担。
分流规则怎么设：三条判断链与判定顺序
分流按固定顺序执行三层判断，前一层未通过则不进入下一层。这样能保证同一类提报每次得到一致的处理路径，也便于向提报人解释结论。
第一层区分事项性质。需求指希望系统或流程发生改变；服务请求是标准化的日常支持，如账号开通、权限申请；故障是现有功能异常；咨询是使用疑问。后三类引导至服务台处理，不进入需求池。判定依据是需求类型初判字段加问题描述，由入口管理员在首次响应时确认。
第二层确定受理归口。通过第一层的事项，按需求类型和影响范围分配到对应队列：影响单部门的业务需求进入业务需求池，由对应业务线产品经理受理；影响多部门或全公司的，进入产品需求池并提交评审组；涉及数据口径与报表的，转数据负责人。影响范围字段在这一层起决定作用。
第三层确定处理批次。受理人综合业务价值、紧急度和就绪度给出结论：价值高且信息完整的进入近期规划，价值待验证的进入观察列表，信息不足的退回补充。紧急度参考期望时间与影响范围，就绪度看描述、期望结果和附件是否足以支撑评估。
| 层级 | 触发条件 | 判定人 | 目标队列 | 响应时限 |
|---|---|---|---|---|
| 第一层 | 类型初判为服务请求、故障、咨询 | 入口管理员 | 服务台 | 当个工作日内转出并告知提报人 |
| 第一层 | 类型初判为需求类 | 入口管理员 | 进入第二层 | 1个工作日内完成确认 |
| 第二层 | 影响范围为单部门 | 入口管理员 | 业务需求池，对应业务线产品经理 | 2个工作日内完成分配 |
| 第二层 | 影响范围为多部门或全公司 | 入口管理员 | 产品需求池，提交评审组 | 3个工作日内安排评审 |
| 第三层 | 信息完整、价值明确 | 需求受理人 | 近期规划候选 | 评审后5个工作日内给出结论 |
| 第三层 | 信息不足 | 需求受理人 | 退回补充 | 退回时一次性列明缺失项 |
规则冲突时按“先性质、后归口、再批次”的顺序取先命中的规则，同一层内出现多条命中，以影响范围更大的一条为准。提报人对分流结论有异议时，可在收到结论后提交申诉，由入口管理员复核；复核维持原判的需说明理由，改判的更新目标队列并通知新受理人。所有改判记录保留在原事项下，作为后续优化规则的依据。
角色与受理责任：谁判定、谁响应、谁反馈
入口能否运转，取决于每个环节是否有人认领。建议明确四类角色，并把响应时限写进规则而不是口头约定。
| 角色 | 主要职责 | 关键交付物 | 时限 |
|---|---|---|---|
| 提报人 | 按字段要求描述需求，配合补充信息 | 完整的提报表单 | 收到补充通知后3个工作日内回复 |
| 入口管理员 | 首次响应、第一层判定、分配归口、处理申诉 | 分流结论与目标队列 | 1个工作日内首次响应 |
| 需求受理人 | 评估价值与就绪度，给出批次结论，推进后续规划 | 评估结论与处理批次 | 分配后5个工作日内给出结论 |
| 评审组 | 对跨部门需求做集体判断，裁定争议 | 评审纪要与否决理由 | 按固定评审节奏，不超过两周一次 |
退回补充和不受理都要给出明确告知。退回时一次性列明缺失字段和需要澄清的问题，避免多轮往返；不受理时说明依据的规则条款，并告知申诉渠道。提报人侧应能看到状态节点：已提交、已受理、分流至某队列、评审中、已纳入规划或已关闭，每个节点显示时间和责任人。状态可见本身就能减少大量催问。
当提报量较大、入口管理员成为瓶颈时，可以把第一层判定下放给各业务线的对接人，入口管理员只处理规则冲突和申诉。这种分工适合提报来源分散、业务线边界清晰的组织；来源集中或需求类型单一的团队，保留集中判定更简单。
在工具层面，这套字段与分流需要承载在可配置的工作项上。ONES 提供业务需求池、产品需求池与工单系统的组合，可用于承接业务反馈与产品开发的联动；工单可收集和整理各方反馈，处理后可转化为需求并整理进产品 Backlog，工作流支持按实际场景自定义，便于把上述判定顺序和状态节点落到流转配置中。提报人、受理人与评审组的状态同步，可依托统一的需求池与工单视图完成追溯。
示例：一条需求从提交到进入需求池
以下为演示情景，用于说明字段填写与分流判定的配合方式。
某零售企业门店运营专员提交一条需求。必填字段填写如下：提报人为门店运营专员，所属部门为门店运营部；需求标题为“门店盘点差异需支持按商品分类汇总”；业务场景与问题描述为“每月盘点后需人工在表格中按分类汇总差异，单店耗时约两小时，月底集中盘点时经常延迟出表”；期望结果为“系统盘点结果页可按商品分类自动汇总差异数量与金额”；影响范围为多部门，因为财务对账也依赖该汇总；期望时间为下个季度末前；需求类型初判为数据报表。选填部分附上了现有汇总表样例。
入口管理员在1个工作日内完成首次响应。第一层判定：事项是希望系统增加汇总能力，属于需求，不转服务台。第二层判定：影响范围涉及门店运营与财务两个部门，归入产品需求池，提交评审组。第三层由受理人评估：价值明确，财务对账有直接收益；信息完整，样例附件可支撑评估；就绪度较高，列入近期规划候选。评审组在例行评审中确认纳入规划，状态更新为“已纳入规划”，提报人可在入口看到每个节点的时间和责任人。
同一提报人在另一条提报中填写“申请开通新入职员工的门店系统账号”，类型初判为服务请求。入口管理员在第一层即判定不属于需求，转至服务台并按服务请求流程处理，同时在原事项下告知提报人转出去向。这条边界保证了需求池不被日常支持事项占用。
上线前的完成检查
入口和规则设计完成后，用一份清单逐项核对，确认可以试运行。
- 字段完整性：最小必填集是否覆盖谁提、提什么、影响谁、多急、期望何时五个问题；每个必填字段是否至少被一条分流规则使用。
- 受控词表：影响范围、需求类型初判、来源渠道等分流相关字段是否全部为枚举选项，每个选项是否有说明，新增选项是否有审核流程。
- 规则覆盖度：用历史提报抽样回放，检查每条规则是否都有命中样本，是否存在无规则可走的提报类型。
- 冲突测试：构造同时命中多条规则的事项，验证优先级取值是否符合“先性质、后归口、再批次”的约定，改判通道是否可用。
- 角色与时限：四类角色是否落实到具体人员，响应时限是否写入规则并在系统中可见，人员缺位时是否有替补。
- 试运行机制：设定两到四周试运行期，每周回收一次数据，包括各入口形态的提报量、第一层转出比例、退回补充比例、平均首次响应时长，据此调整字段必填项和规则阈值。
试运行期结束时，若退回补充比例偏高，优先检查问题描述和期望结果的填写提示是否清晰；若第一层转出比例异常，检查需求类型初判的选项说明是否被正确理解。规则调整应记录版本和生效时间，避免同一时期出现两套口径。
常见问题
提报人填错需求类型初判，导致被转去服务台，怎么处理？
入口管理员在首次响应时应结合问题描述复核类型初判，发现填错可直接改判并进入第二层分流，同时告知提报人改判结果。若事项已转出至服务台，由入口管理员与服务台对接人确认后取回，在原事项下记录改判原因。为减少这类情况，需求类型初判的每个选项应在表单上配一句说明，例如“服务请求”标注为账号开通、权限申请等标准化支持，让提报人在填写时就能区分。
业务线自己建了提报表格，和统一入口字段不一致，如何收敛？
先保留业务线现有表格作为批量导入模板，把列名和选项值映射到统一字段清单，由入口管理员在导入前做格式校验，缺失字段在受理前补齐。运行一段时间后，把使用频率高的业务线表格替换为统一在线表单，只保留确有成批收集需要的场景继续用导入模板。收敛的关键是统一受控词表：影响范围、需求类型初判等选项由入口管理员统一发布，业务线不再自行扩展。
提报量不大，是否也需要设置入口管理员和评审组？
提报量较小时可以合并角色，由一位产品经理同时承担入口管理员和需求受理人的职责，第一层判定和归口分配一并完成。评审组可以改为按需召集，跨部门需求出现时再组织相关方评审，不必维持固定评审节奏。需要保留的是响应时限和状态可见：即使只有一个人处理，也应在约定时间内给出首次响应，并让提报人看到事项当前处于哪个节点。
期望时间填得很急，是否就应该优先处理？
期望时间是紧急度的参考之一，不单独决定处理顺序。第三层判断综合业务价值、紧急度和就绪度：影响范围大且期望时间临近的，优先进入近期规划；期望时间急但信息不足的，先退回补充，补齐后再评估。为避免提报人普遍填写“尽快”，期望时间字段建议填写具体日期或时间窗口，并在表单提示中说明该时间用于排期参考，最终批次以受理人评估结论为准。
试运行期发现大量提报被退回补充，应该改字段还是改规则？
先看退回原因集中在哪些字段。若集中在问题描述和期望结果，说明填写提示不够清晰，应优化表单上的示例和引导语，必要时把这两项拆成更具体的小问题；若集中在影响范围或需求类型初判，说明选项说明有歧义，应调整选项措辞。规则本身通常不需要大改，退回补充比例偏高更多反映的是字段引导问题。调整后记录版本和生效时间，观察下一周期的退回比例变化。
