邮件、群聊和会议里的需求往往同时存在：邮件里客户提了一条，群里有人补了一句，会上又口头确认了一版，最后没人说得清哪条才是正式需求。收敛的关键是三件事：确定唯一登记点，为每类渠道规定转登责任人和时限，过渡期保留旧渠道但只当作线索来源。ONES 的需求工作项可以作为登记载体，并用来源字段保留原始出处，下文按这个思路展开具体做法。
要点总览（TL;DR）
- 统一入口先定三件事：正式需求记录落在哪个载体、每条记录至少填哪些字段、每个渠道由谁负责转登，入口不清后面规则无处落地。
- 邮件用专用收件箱或标签收口，群聊靠识别信号加“已登记”回复确认，会议把纪要中的需求条目逐条结构化转登，三类渠道都保留原始出处。
- 过渡期分宣导、并行、收敛三段，旧渠道保留沟通功能但只产生线索，每周巡检未转登线索并补登，退出条件提前写清。
- 用入口覆盖率、转登及时率、重复登记率、旧渠道绕过情况和字段完整性五项做月度检查，阈值先宽后紧，问题落到具体动作。
先定统一入口：登记什么、由谁登记、登记到哪
统一入口要先回答三个问题：需求记在哪个载体上、每条记录至少填什么、谁负责把记录建起来。入口本身定不清楚，后面的转登规则就没有落点。
载体选择
常见载体有三种，选择依据是团队现有的协作方式和需求后续要走什么流程。
| 载体 | 适用情况 | 注意点 |
|---|---|---|
| 需求表单 | 提出人分散、需要对外收集，或希望统一字段格式 | 表单只负责收集，提交后仍需落到可跟踪的工作项上 |
| 需求工作项 | 团队已在用项目管理工具，需求要进入评审、排期和交付流程 | 需要配置来源、提出人等字段，并约定谁能创建 |
| 需求收件箱 | 线索量大、需要先集中再由接口人分拣 | 收件箱是暂存区，必须有分拣时限，否则会变成第二个堆积点 |
三种载体可以组合使用，例如表单对外收集、工作项对内跟踪、收件箱承接转登线索，但正式需求记录只能落在其中一处。ONES 的需求工作项支持自定义字段和状态流转，适合作为正式记录的落点，来源信息通过字段保留，便于后续追溯。
最小必填字段
字段不必多，但以下五项缺失任何一项，后续都无法判断需求该不该做、由谁跟进：
- 来源渠道：邮件、即时消息、会议或其他，用于统计各渠道线索量和转登情况。
- 提出人：真实提出需求的个人或客户联系人，便于回访确认。
- 原始描述：提出人原话或接近原话的记录，避免转登人二次概括丢失信息。
- 期望时间：提出方希望什么时候看到结果，没有明确时间可填“未说明”。
- 业务影响：这条需求影响哪些用户、流程或收入，用于初筛判断轻重。
此外建议保留原始出处字段，记录邮件主题、群名称或会议日期，作为追溯依据。
登记责任角色
登记责任要落到具体角色，避免“大家都觉得别人会登”。通常分三层：渠道负责人负责把本渠道的线索转登为记录；需求接口人负责检查字段完整性、做初步去重；产品负责人确认需求有效性后决定是否进入后续评审。小团队可以一人兼多个角色，但每个渠道必须明确到人。
唯一性规则
同一需求只允许存在一条主记录。判断口径可以是“同一提出人+同一业务场景+同一期望结果”视为同一条需求。后续补充的信息追加到主记录上，不另建新记录。发现重复时，由需求接口人合并并注明关联记录，保留被合并记录的出处，方便回溯。
按渠道定转登规则：邮件、群聊、会议各自怎么进
三类渠道的形态不同，转登动作也要分开设计。共同原则是：旧渠道继续用，但只产生线索；线索由指定角色在固定时限内转成正式记录。
| 渠道 | 识别方式 | 转登人 | 时限 | 保留字段 |
|---|---|---|---|---|
| 邮件 | 指定收件箱或统一标签，如“需求”“客户反馈” | 收件箱轮值人或客户对接人 | 收到后1个工作日内 | 邮件主题、发件人、收件日期 |
| 即时消息 | 群内出现明确的功能诉求、问题反馈或改进建议 | 群内指定的需求接口人或值班产品人员 | 识别后当个工作日内 | 群名称、消息日期、提出人昵称 |
| 会议 | 会议纪要中标注为需求、待办或改进项的条目 | 会议组织者或纪要整理人 | 纪要发出后1个工作日内 | 会议名称、会议日期、参会方 |
邮件：用收件箱和标签收口
先设一个专用收件箱或统一标签，所有被判断为需求的邮件都归到这里。轮值人每天固定时间清理一次，逐封判断是否构成需求：构成需求的转登为记录，不构成的回复说明或转给对应处理渠道。转登时把邮件主题和发件人填入来源字段，原始描述直接摘录邮件正文关键段落，避免只写一句概括。
即时消息：识别诉求，不把聊天记录当需求
群聊的问题是信息碎片化，一句话需求往往夹在讨论中间。可行的做法是约定识别信号，例如提出人明确说“这个能不能做”“希望增加某功能”，或接口人看到诉求后回复“已登记”并附记录编号。聊天记录本身不作为需求依据，转登人需要把上下文整理成完整描述，并与提出人确认一句，避免理解偏差。群内可以固定一条消息说明登记入口和转登人，减少重复询问。
会议：把纪要条目结构化
会议纪要是最容易被忽略的来源，因为需求常以口头共识的形式出现。纪要整理时，把涉及需求的条目单独列出，每条写清提出方、诉求内容、期望时间和背景。会后由纪要整理人按条目逐条转登，一条需求对应一条记录，不把整段纪要贴进一条记录里。会上没有说清的信息，在转登时标注“待确认”，由需求接口人跟进补齐。
三类渠道转登时都要保留原始出处。出处字段的作用不只是留痕，后续需求优先级有争议时，可以回到原始邮件或会议记录核对上下文。使用 ONES 时，可以在需求工作项上配置来源渠道和出处说明字段，让每条记录自带追溯信息。
过渡期怎么安排：旧渠道不关，但只做线索来源
直接宣布“以后所有需求都走统一入口”通常会失败：提出人习惯没改，渠道负责人也没准备好承接。过渡期的作用是让新入口先跑起来，旧渠道逐步退到线索位置。
| 阶段 | 时长参考 | 旧渠道定位 | 兜底动作 | 退出条件 |
|---|---|---|---|---|
| 宣导期 | 1–2周 | 照常使用，同时公告统一入口 | 接口人手动把新线索补登，形成示范记录 | 各渠道负责人明确，入口和字段配置完成 |
| 并行期 | 2–4周 | 仅作为线索来源，不再直接推进需求 | 每周巡检一次未转登线索，由接口人补登并提醒转登人 | 连续两周转登及时率达到约定标准 |
| 收敛期 | 2周左右 | 保留渠道，但需求一律要求先登记再讨论 | 发现绕过入口直接推进的，退回补登后再处理 | 新需求基本从统一入口进入，抽查无遗漏 |
时长只是参考，团队规模大、渠道多时可以适当拉长。并行期最关键的安排是巡检：指定一个人每周检查各渠道是否还有未转登的线索，发现遗漏就补登，并私下提醒对应转登人。巡检记录本身也是过渡期结束时的验收证据。
退出条件要提前写清楚，例如“连续两周各渠道转登及时率不低于90%，抽查20条新需求全部能在入口中找到对应记录”。条件达成后，旧渠道仍然保留沟通功能，但需求讨论的结论必须回到统一入口，避免出现两套并行记录。
角色与交付物：谁在哪个环节交付什么
收敛流程涉及四类角色，每个角色在每个环节都有明确的产出，责任才不会悬空。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 提出人 | 通过任一渠道说明诉求，尽量提供场景、期望结果和时间 | 可识别的需求线索，含背景信息 |
| 渠道负责人 | 在时限内识别本渠道线索并转登，填写来源和原始描述 | 字段完整的待初筛记录 |
| 需求接口人 | 检查字段完整性，做去重判断，合并重复记录，补齐缺失信息 | 去重后的有效需求记录，附关联说明 |
| 产品负责人 | 确认需求有效性，判断是否进入评审和排期 | 需求有效性结论和后续处理状态 |
提出人的责任常被忽略。转登质量很大程度取决于线索本身是否说清楚，因此在各渠道公告中可以给出一个简单的提交提示：说清使用场景、希望达到的效果、期望时间。渠道负责人转登时如果发现信息不足，应回问提出人，而不是自行补全。
需求接口人是流程的枢纽，既要保证记录字段完整，也要控制重复。去重时可以按提出人、业务场景和期望结果三项比对，拿不准的合并前先与提出人确认。产品负责人只对有效性做判断，不承担登记和去重工作，职责边界清楚，流程才跑得顺。
一个完整示例：从群聊消息到正式需求记录
以下为演示情景，用于说明转登全过程。
背景：某客户成功群里，客户对接人发消息：“我们财务每月对账要手工导出两次数据，能不能加一个自动对账报表，最好月底前能用。”群内需求接口人看到后回复“已收到，我登记一下”。
第一步：识别与转登。群内值班的产品人员判断这是一条明确的功能诉求，当天在需求工作项中创建记录。填写内容为：来源渠道“即时消息”，提出人“客户对接人张某”，原始描述摘录原话，期望时间“本月底”，业务影响“财务每月重复手工操作，影响对账效率”，出处填写群名称和消息日期。
第二步：初筛与去重。需求接口人检查字段，发现缺少涉及的数据范围，回问客户后补充“对账涉及两个业务系统的订单和收款数据”。随后按提出人和场景检索，发现两周前邮件中有一条相似需求，判断为同一诉求，将邮件记录合并到本条主记录，注明关联出处。
第三步：确认与通知。产品负责人评估后确认需求有效，标记为“待评审”，并在群内回复提出人记录编号和当前状态。此后该需求的讨论和进展都在这条记录上更新，群聊只作为沟通渠道。
这个示例体现了几个要点：转登人当天完成登记，原始描述保留原话，出处可追溯，去重有比对依据，提出人收到明确反馈。ONES 的需求工作项可以承载这类记录，来源字段和关联关系帮助接口人完成追溯和合并。
完成检查：怎么判断收敛到位
收敛是否到位，不能只看“入口建好了”，要看新需求是否真的从入口进入、线索是否按时转登、旧渠道是否还在绕过入口。建议每月做一次检查，逐项留证据。
| 检查项 | 通过标准 | 证据 | 责任人 |
|---|---|---|---|
| 入口覆盖率 | 抽查的新需求中，能在统一入口找到对应记录的比例达到约定值，如95%以上 | 抽查清单与记录对照表 | 需求接口人 |
| 转登及时率 | 各渠道线索在约定时限内转登的比例达到约定值，如90%以上 | 渠道线索时间与记录创建时间对比 | 渠道负责人 |
| 重复登记率 | 重复记录占比低于约定阈值，合并记录有出处说明 | 去重记录与合并日志 | 需求接口人 |
| 旧渠道绕过情况 | 抽查未发现需求在旧渠道直接推进到排期或开发 | 巡检记录、评审记录比对 | 产品负责人 |
| 字段完整性 | 必填字段缺失的记录占比低于约定阈值 | 记录字段统计 | 需求接口人 |
指标阈值应结合团队实际情况设定，首次检查可以放宽，连续两三个月稳定后再收紧。检查发现的问题要落到具体动作：覆盖率不足，检查是否还有渠道没有指定转登人；及时率低，看是时限不合理还是转登人负担过重；旧渠道仍有绕过，说明入口的登记成本太高或反馈太慢，需要简化字段或加快初筛。
检查结果建议在团队内公开一次，让各渠道负责人看到自己渠道的转登情况。收敛是一个持续维护的机制，入口建好只是开始，定期检查和调整规则才能让需求真正沉淀到一个地方。
常见问题
团队人少、渠道也不多，还需要专门设需求接口人吗？
需要保留这个职责，但可以由一人兼任多个角色。关键在于每个渠道都有明确的人对转登负责，并且有人检查字段完整性和做去重。如果完全没人承担接口人职责，邮件和群聊里的线索容易停在“已收到”就不再推进。小团队可以把渠道负责人和需求接口人合并为一人，产品负责人仍单独确认需求有效性，避免登记和决策混在一起。
提出人不愿意走统一入口，仍然直接在群里找开发人员推进，怎么处理？
先看是入口成本问题还是习惯问题。如果登记字段太多、反馈太慢，提出人会绕开入口，这时应精简必填字段、缩短初筛反馈时间。如果是习惯问题，在收敛期执行“先登记再讨论”的规则：发现绕过入口直接推进的需求，退回补登后再处理，并在团队内说明原因。同时让提出人看到登记后的状态反馈，入口能带来可见进展，绕行才会减少。
会议纪要里的需求经常是口头共识，信息不全，转登时怎么处理？
纪要整理时把需求条目单独列出，写清提出方、诉求内容、期望时间和背景；会上没说清的部分在转登时标注“待确认”，由需求接口人跟进补齐，不要由转登人自行推测补全。一条需求对应一条记录，不把整段纪要贴进一条记录里。补齐前记录可以停留在待确认状态，但不应因此进入评审排期。
过渡期结束后，旧渠道还能不能继续讨论需求？
可以继续用于沟通，但需求讨论的结论必须回到统一入口形成记录。旧渠道保留的是交流功能，正式需求记录只存在于统一入口一处，避免出现两套并行记录。收敛期发现需求在旧渠道直接推进到排期或开发的，退回补登后再处理，这条规则需要产品负责人配合执行。
转登及时率一直上不去，应该先调时限还是先加人？
先判断原因再决定。如果是时限本身不合理，比如要求当天转登但轮值人隔天才处理邮件，应调整时限到可执行的范围；如果是转登人负担过重，比如一个人同时负责多个群和收件箱，应拆分渠道责任或增加轮值。调整后观察一到两周，仍不达标再考虑简化转登动作，例如减少必填字段、提供记录模板。
