销售和客服每天带回大量客户诉求，如果靠聊天记录和口头转述，研发很难判断哪些该做、哪些已经有人提过。把这类需求导入统一需求池，核心是建立一条固定通道：统一入口和必填字段，由需求池负责人做业务去重与合并，分诊后入库并标注状态，最后把结论回给提交人。下文给出可直接落地的字段表、操作步骤、角色分工和上线自查清单，并说明 ONES 在需求登记与状态流转中的承载方式。
要点总览（TL;DR）
- 统一入口是通道的起点：销售、客服通过表单或工单提交，需求池负责人把会议、电话等内部转述代录进同一需求池，避免两套台账。
- 最小必填字段控制在七项以内，包括提交人及角色、客户或商机、原始诉求描述、业务场景、期望时间、影响范围和来源标记，字段说明写进表单提示语。
- 从提交到入库分五步：登记、初筛、业务去重与合并、分诊归类、入库并设置状态，每步有完成标志，未达标不进入研发视野。
- 去重按同一客户或同一业务场景归并，保留一条主记录并累加客户数量与反馈频次；研发只承接已入库需求，排期和价值评分在需求池之外完成。
- 通道是否跑通看四项：入口唯一、字段完整、重复合并率稳定或下降、反馈闭环，连续多个周期通过后再衔接迭代管理。
统一入口与必填字段怎么定
统一入口解决“需求从哪里进”的问题，必填字段解决“进来之后能不能判断”的问题。两者要一起定，否则入口统一了，记录仍然缺客户、缺场景，需求池负责人无法去重和分诊。
常见入口有两种形态。第一种是面向销售、客服开放的表单或工单提交，提交人不需要进入需求池工具，按表单填写即可生成一条待处理记录；第二种是需求池负责人在需求池内直接登记，适用于会议、电话、内部转述等场景。两种形态应写入同一个需求池，避免形成两套台账。团队规模较小时可以只保留表单入口，由负责人统一代录；提交量大的团队适合表单与直接登记并行，但要在字段中保留来源标记。
最小必填字段建议控制在七项以内，保证提交人能在几分钟内填完，同时让后续分诊有据可依。
| 字段 | 必填/选填 | 填写说明 | 常见漏填 |
|---|---|---|---|
| 提交人及角色 | 必填 | 填写姓名与所属角色，如“销售—华东区”“客服—售后组” | 只写姓名，无法判断由谁确认客户原意 |
| 客户或商机 | 必填 | 写明客户名称；销售提交时关联商机或合同阶段 | 写“某客户”“多个客户”，无法做业务去重 |
| 原始诉求描述 | 必填 | 用客户原话或接近原话的方式描述，保留具体操作和期望结果 | 直接写成解决方案，丢失原始诉求 |
| 业务场景 | 必填 | 说明在什么业务流程、什么环节遇到问题 | 只写“不好用”“需要优化” |
| 期望时间 | 必填 | 填写客户期望的时间点或时间范围，注明是合同承诺还是客户期望 | 把销售口头承诺当成确定交付时间 |
| 影响范围 | 必填 | 涉及客户数量、用户角色、是否影响签约或续费 | 只写“影响很大”，缺少可比较的口径 |
| 来源标记 | 必填 | 选择销售、客服或内部提出，用于统计来源和分配确认责任 | 统一填“业务”，后续无法区分通道 |
| 附件或截图 | 选填 | 工单截图、客户邮件、操作录屏等佐证材料 | — |
字段说明要写进表单提示语，而不是只放在制度文档里。例如“客户或商机”一栏提示“请填写客户全称；同一客户多次提交请沿用同一名称”，能明显减少同一客户被拆成多条记录的情况。来源标记建议做成下拉选项，避免提交人自由填写造成口径分散。
从收集到入库的操作步骤
一条需求从提交到进入需求池，按五个步骤推进。每一步都有明确输入、动作、输出和完成标志，未达到完成标志的记录停留在上一步，不进入研发视野。
步骤一：提交人登记原始需求
输入是客户诉求和业务背景，动作是按字段表填写表单或在需求池内登记，输出是一条原始需求记录。完成标志是必填字段齐全、来源标记已选。字段缺失的记录退回提交人补充，退回时注明缺哪几项，避免反复往返。
步骤二：需求池负责人初筛
输入是原始需求记录，动作是判断这条诉求是否属于需求池范围。属于产品能力缺失、流程优化、体验改进的进入下一步；属于缺陷报障的转入缺陷处理通道；属于咨询、操作指导的由客服直接答复并关闭。完成标志是记录被标记为“范围内”或“转出”，转出的记录要写明去向。
步骤三：业务去重与合并
输入是初筛通过的需求，动作是按同一客户或同一业务场景检索已有条目。发现重复时，保留一条主记录，把其他提交作为关联记录挂在主记录下，并在主记录中累加客户数量和反馈频次。完成标志是主记录确定、关联关系建立、重复条目状态改为“已合并”。这里的去重是业务判断，依据是客户、场景和诉求实质是否一致，与搜索关键词匹配无关。
步骤四：分诊归类
输入是主记录，动作是标注需求类型、所属模块和初步优先级区间。需求类型可分为新功能、功能优化、体验问题、集成需求等；所属模块按产品结构填写；初步优先级区间只做粗分，例如高、中、低，具体价值评分留给优先级评估环节。完成标志是三项标注齐全，且分诊人与提交人对归类无异议。
步骤五：入库并设置状态
输入是完成分诊的主记录，动作是把记录状态设为“已入库”，补充需求池负责人和计划评估时间，输出是一条研发可查看的需求条目。完成标志是状态为“已入库”且能在需求池默认视图中被检索到。此后研发才介入可行性评估，评估结论回写到同一条记录，不另开新条目。
销售、客服、研发的角色与交付物
通道能否稳定运行，取决于三类角色是否清楚自己在哪个节点交什么。角色分工按动作和交付物定义，比按部门职责描述更容易执行。
| 角色 | 主要动作 | 交付物 | 交接节点 |
|---|---|---|---|
| 销售 | 提交客户与商机背景，说明业务影响；客户对诉求有疑问时负责确认原意 | 字段完整的原始需求记录、客户影响说明 | 提交后交给需求池负责人初筛 |
| 客服 | 提交工单来源的需求，汇总工单量和重复反馈次数；处理完成后回访客户 | 频次证据、客户回访结论 | 提交后交给需求池负责人；回访结论回写到需求记录 |
| 需求池负责人 | 初筛、业务去重与合并、分诊归类、维护状态 | 主记录、合并关系、分诊标注、状态更新 | 入库后交给研发评估；评估结论回写后更新状态 |
| 研发 | 对已入库需求做可行性评估，给出技术约束和大致工作量区间 | 可行性结论、技术风险说明 | 评估完成后回写需求记录，交由后续排期环节 |
研发不直接接收未入库的口头需求，这一点需要在团队内明确。销售或客服在走廊、群里提出的诉求，仍要走表单或由负责人代录，目的是让每一条诉求都有记录可追溯，而不是增加一道审批。
响应时限由团队按业务节奏约定，并写进需求池状态。例如初筛在提交后两个工作日内完成，分诊在初筛通过后三个工作日内完成，超时记录在需求池视图中可见。时限约定要留出合并和补充信息的时间，避免为了赶时限把未确认的记录强行入库。
在工具承载上，ONES 提供统一的需求池、工单与任务看板，业务、产品与研发可以在同一套记录上同步状态；ONES Project 支持建立需求池、自定义需求状态与属性，并可按组织架构和项目角色分配权限。销售和客服通过工单或表单提交，需求池负责人在同一需求池中完成合并与分诊，研发在入库后查看记录并回写评估结论，这条流程可以在一个系统内完成。
示例：一条客服需求走完整条通道
以下为演示情景，用于说明字段填写和判断过程，不代表真实客户案例。
背景：客服团队在一个月内收到五家客户反映，导出报表时字段顺序与页面显示不一致，需要手工调整后才能使用。五条反馈分别来自不同客服，其中两条是同一客户的不同联系人提交。
原始记录填写：提交人写“客服—售后组李某”，客户填写五家客户全称，原始诉求描述保留客户原话“导出的表格列顺序和页面上不一样，每次都要手动调”，业务场景写“月度经营分析报表导出”，期望时间写“客户希望下个季度前改善”，影响范围写“五家客户，均为月度报表使用方”，来源标记选“客服”，附件附上两张导出截图。
去重合并：需求池负责人按“报表导出”检索，发现已有两条同类记录，其中一条来自销售提交的商机需求。负责人保留最早的一条作为主记录，把其余四条作为关联记录挂入，主记录中客户数量更新为六家，反馈频次记为六次，重复条目状态改为“已合并”。
分诊入库：负责人把需求类型标为“功能优化”，所属模块标为“报表中心”，初步优先级区间标为“中”，状态设为“已入库”，并注明计划评估时间。研发评估后回写结论：可调整导出模板的列顺序配置，工作量在可接受范围内。
反馈闭环：客服把处理结论回访给五家客户，说明改进已进入需求池并给出预计评估节点；销售把结论同步给对应商机。回访记录回写到主记录，主记录状态更新为“已排期”前的待排期状态。整个过程中，六次提交只产生一条主记录，研发看到的是一条带完整背景和频次证据的需求。
需求池维护与完成检查
通道建起来之后，需要定期维护并做上线自查，判断它是否真正跑通，而不只是表单上线了。
日常维护动作
定期清理合并残留的重复项，把状态仍为“待评估”但长期无进展的条目集中复核，能关闭的写明关闭原因，需要保留的更新计划评估时间。状态口径要统一：待评估指已提交但未完成初筛或分诊；已入库指完成分诊、研发可查看；已排期指进入迭代计划；已关闭指已交付、已合并或确认不做。四个状态的判定标准写进需求池说明，避免同一状态在不同人手里含义不同。
上线自查清单
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 入口是否唯一 | 销售、客服提交的需求都进入同一需求池，无平行台账 | 存在口头传递绕过需求池的固定做法 |
| 必填字段是否齐全 | 抽查近期记录，必填字段完整率达到约定水平 | 客户或业务场景缺失，导致无法分诊 |
| 重复率是否下降 | 连续多个周期内，合并处理的重复条目占比稳定或下降 | 同一客户同一诉求反复以新条目出现 |
| 反馈是否闭环 | 已关闭和已排期需求均有回访或同步记录 | 提交人长期不知道处理结论 |
| 状态是否准确 | 抽查记录状态与实际进展一致 | 已排期条目实际未进入任何计划 |
连续多个周期以上检查项稳定通过，可以认为通道已经跑通。此时再把注意力转向需求池与迭代管理的衔接：入库需求进入迭代计划属于排期环节，价值评分和优先级细化属于优先级评估环节，两者在需求池之外完成，需求池只负责把需求收齐、合并清楚、分诊到位并保持状态准确。
常见问题
销售在客户现场口头答应了一个需求，回来只发了条消息，这种情况怎么处理？
口头承诺本身不能直接进入研发排期，但客户诉求需要被记录。建议由销售按字段表补录，或由需求池负责人代录，客户、业务场景、期望时间和影响范围照实填写，并在期望时间一栏注明“销售口头承诺”还是“客户期望”。
补录之后走正常初筛和分诊流程。如果销售已经向客户承诺了时间，需求池负责人应优先安排初筛，并把评估结论同步给销售，由销售向客户说明实际节点。团队可以把“口头承诺需在约定工作日内补录”写进协作约定，减少记录滞后。
客服和销售对同一条需求的优先级判断不一致，以谁的意见为准？
需求池阶段只做初步优先级区间，不做最终排序。销售通常从商机和签约角度判断，客服从工单频次和客户影响面判断，两者提供的是不同证据，可以同时保留在需求记录中。
需求池负责人负责把客户数量、反馈频次、是否影响签约或续费等信息汇总到主记录，给出粗分区间。最终排序交给优先级评估环节，按团队约定的评估口径处理。分歧本身不是问题，缺少证据才是问题，因此提交时把影响范围和频次写清楚比争论结论更有用。
需求池里的条目越来越多，怎么判断哪些该关闭？
关闭不等于否定需求，而是给记录一个明确结论。常见可关闭情形包括：已合并到其他主记录、已交付上线、经评估确认不做、长期无客户反馈且业务场景已消失。
建议定期集中复核状态为“待评估”且长期无进展的条目，逐条写明关闭原因并保留关联记录。关闭动作要通知提交人，销售和客服据此回复客户。状态口径统一后，需求池的条目数量才能反映真实待办，而不是历史堆积。
团队规模很小，还需要单独设需求池负责人吗？
小团队可以不设专职岗位，但初筛、去重合并、分诊这几件事需要有明确的人负责，否则记录会停留在提交状态。常见做法是由产品经理兼任，或由一位客服主管与产品经理分工：前者负责收集和回访，后者负责分诊和入库。
关键是责任落到具体角色而不是“大家都可以”。当提交量还不大时，表单入口加一人代录即可运行；提交量增长后再考虑拆分初筛与分诊职责。
需求池和迭代计划是什么关系，入库后是不是就该排期了？
入库表示这条需求已经收齐信息、完成合并和分诊，研发可以查看和评估，但不等于马上排期。进入迭代计划属于排期环节，需要结合版本节奏、资源和技术评估结论决定。
需求池负责把需求收齐、合并清楚、分诊到位并保持状态准确；价值评分和优先级细化在优先级评估环节完成；Sprint Backlog 的排期在迭代管理中处理。三者边界清楚，需求池才不会变成排期表，也不会因为迟迟不排期而失去维护。
