compiled / 待人工 reviewyoudaonote search -> read
回读的 .clipcustomer-demand-crm-sop-reading-hub.html：同范围的人审阅读页。| 文章 | 入口问题 | 核心产出 | 不能直接当作什么 |
|---|---|---|---|
| 产品需求池整理 | 收到很多反馈，下一版先做什么 | 原始声音、需求簇、分类、证据、优先级、状态、PRD 候选 | 用户说了就必须做；只凭频次排期 |
| 企业微信 CRM 跟进 SOP | 线索进来后如何持续推进并留下证据 | 分配规则、响应 SLA、跟进任务、记录、回收、漏斗指标 | 某个 SCRM 产品功能说明；12%→35% 已被证实 |
| 客户需求深度挖掘 SOP | 如何避免客户一开口就急着讲功能 | 开放提问、现状、摩擦、影响、期望、补充问题、价值对比 | 诱导客户、夸大损失或预设需求 |
三篇文章不是三条孤立技巧，而是同一条链路的三个阶段：
CRM 线索与跟进证据
-> 需求访谈与痛点深挖
-> 客户声音结构化
-> 同目标需求合并
-> 价值/证据/成本/战略排序
-> PRD、验证实验或暂缓/拒绝
-> 决策回写 CRM 与客户本项目已有 prd-requirements-analysis
skill，已经覆盖真需求过滤、Y
模型、RICE/价值成本和需求池优先级。因此本次没有再创建一个名字相近、职责重复的新
skill；新文章作为 C
级补充方法，重点补齐“原始证据如何进入需求池”和“销售跟进如何形成产品输入”。
source-index.csv 里的 Note ID 执行
youdaonote read <note_id>。75BA7F52F8E84CEC830041A3C3825A6D产品需求池整理 Skill：把客户声音变成可执行的迭代优先级.clipf5f1923240161fa2810005df63565022082136207bbdf9b7bb5b9fa50bab174f反馈渠道越多，产品方向不一定越清楚。群聊、工单、销售拜访、老板想法和售后问题常混在一起，容易出现四种浪费：同类项重复评审、模糊项直接排期、重要问题被声音大小覆盖、做完没有成功标准。
文章主张把 Agent/Skill 放在“反馈入口”和“版本决策”之间，做四件事：保留原始证据、按目标合并、区分问题类型、给出优先级与后续动作。
每条输入至少保留：来源、时间、提出角色、客户/用户场景、原话、相关文件或聊天证据。产品经理可以翻译，但不能丢失原始表述，否则评审时无法回到事实。
例如导出慢、生成卡顿、大文件失败，表面描述不同，可能共同指向“任务执行的性能与稳定性”。合并后的需求簇应保留每条子证据，而不是只剩一句“优化体验”。
| 类型 | 判断问题 | 常见动作 |
|---|---|---|
| 功能需求 | 当前能力缺失，是否阻断明确任务 | 进入需求澄清或 PRD |
| 体验问题 | 能完成但路径、效率、可理解性差 | 用任务成功率、耗时、错误率验证 |
| 质量问题 | 已承诺能力不稳定或不正确 | 优先走缺陷/质量闭环，不与新功能混排 |
| 误解型需求 | 能力已存在，但用户找不到或理解错误 | 优先改引导、培训、信息架构或运营解释 |
这一步的价值是避免把所有客户声音都转成研发任务。
建议为每个分数保存依据和证据强度。没有依据的高分，应降为“待验证”，不能直接排期。
需求池的终点不是排名表，而是明确下一动作：进入当前版本、进入 discovery、与既有需求合并、拆分、做低成本实验、暂缓、拒绝或转为运营/培训问题。真正进入 PRD 的条目需要补目标、用户场景、范围、边界、验收标准和成功指标。
| 字段组 | 字段 |
|---|---|
| 来源证据 | 输入 ID、来源渠道、客户/角色、日期、原话、证据路径 |
| 场景问题 | 用户任务、触发场景、当前做法、阻塞、频率、代价 |
| 合并关系 | 需求簇 ID、父需求、重复项、相关缺陷/项目 |
| 分类 | 功能/体验/质量/误解；标准/配置/定制/拒绝 |
| 评估 | 影响范围、用户价值、业务价值、证据强度、成本、风险、战略匹配 |
| 决策 | 优先级、状态、决策理由、Owner、目标版本、下一验证动作 |
| 闭环 | PRD/实验/缺陷链接、验收证据、上线结果、客户回访 |
本项目 prd-requirements-analysis
已经提供真需求过滤、5W2H、Y 模型、RICE/价值成本、需求状态和 PRD
门禁。本文的新价值主要在更前端的“多渠道客户声音去重与证据保留”，不值得复制成第二个同职责
skill。
需求簇 ID：
共同用户目标：
共同阻塞：
原始证据列表：
影响范围与频次：
不处理的代价：
候选解决路径：产品 / 配置 / 流程 / 培训 / 缺陷修复
证据强度：A / B / C / D
价值、成本、风险、战略匹配：
建议动作：当前版本 / discovery / 合并 / 拆分 / 暂缓 / 拒绝
Owner、截止时间、通过标准：7264672FB90D4DD9B3E73E34BA41FC56企业微信CRM实战：一套跟进SOP，客户转化率从12%拉到35%.clip8387f3453150bc47e403b384ab74f2e63072cc9b5002763eae307f685e461156标题中的“12% 拉到 35%”没有在回读正文中形成可审计的样本、周期、分母、对照组和计算口径，不能写成本项目已验证效果。正文还包含若干响应速度与转化倍数判断，也没有提供可复核来源。本项目只吸收流程结构，所有阈值都需要用真实 CRM 数据校准。
分配规则可以按渠道、区域、客户类型、产品线或团队轮转组合；规则要有优先级，并保留“未命中规则”的待分配池。关键不是某个工具按钮，而是每条线索必须拥有明确 Owner、分配时间和下一动作。
建议验收指标：分配覆盖率、平均分配耗时、待分配积压数、不同销售的人均线索负载。
文章建议分配后 30 分钟内联系，并在超时后提醒销售、再升级主管。这个阈值适合作为试点假设，不是通用标准；应按渠道热度、工作时段、ToB/ToC、客户级别和团队资源分别配置。
首次触达的重点是提供继续沟通的理由：确认客户正在解决的任务、提供相关资料或询问当前做法，而不是只做自我介绍或立即推销。
文章给出 1-3-7-15 天
的通用节奏，并建议按新线索、意向客户、已报价客户调整。项目化使用时，建议把它当作实验基线：
| 阶段 | 目标 | 合格动作 |
|---|---|---|
| 初次连接 | 确认来源、角色和任务 | 客户有回应或明确不适配 |
| 需求确认 | 补现状、痛点、预算/决策链和时间窗口 | 形成下一步和责任人 |
| 方案推进 | 用案例、方案、演示或报价解决具体卡点 | 客户进入下一阶段或明确原因 |
| 决策促成 | 处理风险、内部审批、时间和资源约束 | 明确签约/暂停/流失状态 |
没有新增信息，只重复追问“考虑得怎么样”，不算有效跟进。
每次跟进至少记录三项：客户本次核心反馈、下一步动作、预计完成时间。对 B2B 项目还应补角色/决策链、预算口径、项目阶段、主要阻塞和证据附件。
“发送消息”不等于完成；完成标准应该与客户回复、会议完成、方案确认、资料提交或阶段变化挂钩。
文章按新线索、意向、报价三个阶段设置不同回收周期，并允许对长周期客户申请有审批的锁定保护。核心原则是：阶段越早、时效越强，超时越短；大客户可以保护，但必须写明推进证据、下次动作和复核时间。
回收不是惩罚销售，而是防止线索在个人名下长期失去可见性。正式规则应保留申诉、锁定审批、重新分配和客户体验保护。
文章建议关注跟进率、有效沟通率、超时回复和阶段漏斗。项目化时还需要：
看板用于定位流程和辅导问题，不应用单一指标制造“假跟进”。
| 对象 | 必填字段 |
|---|---|
| 线索 | 来源、创建时间、客户/联系人、所属区域/行业、Owner、分配时间、首次响应时间 |
| 商机 | 需求场景、产品包、预计金额、决策角色、预算状态、签约窗口、阶段、主要阻塞 |
| 跟进 | 本次客户事实、沟通方式、有效结果、下一动作、Owner、截止时间、附件/证据 |
| 回收 | 回收触发、最后有效跟进、回收原因、锁定审批、重新分配记录 |
| 结果 | 成交/暂停/流失、原因、合同/验收/回款链接、可回流产品需求 |
30 分钟、1-3-7-15 天、3/15/30 天回收；阈值要基于真实数据试验。E806E637A91E422D89FD5DAFEDB7C3A4客户需求深度挖掘标准SOP.clip6e89f53927e29414b6ec638678ceb27847119c6859f7ad9431e5dfe72aaaa700先理解客户业务，再讨论产品功能。以开放式问题让客户描述现状、摩擦和影响；一旦得到一个问题，不急着给方案，而是继续追问当前做法、发生频率、责任角色、替代方法和实际代价。
让客户先说最关注的经营或管理难题，避免用“是不是库存不准”等预设问题限制答案。目标是得到问题域，不是一次拿到完整需求。
询问客户现在如何完成这项工作：谁做、用什么工具、经过哪些步骤、信息在哪里流转、什么时候容易中断。没有现状图，就无法判断新系统是否真能改善。
沿当前流程询问繁琐、重复、等待、出错、对账困难、信息断点和协作冲突。要求客户给最近一次例子，避免只停留在“效率低”“不方便”等抽象词。
原文使用“共情放大”的说法。项目化时应改为“共情确认 + 影响量化”：确认客户感受，同时追问影响到哪些人、多久一次、花多少时间/成本、是否造成损失或决策延迟。不能替客户推断损失，更不能为了销售制造恐惧。
一个问题问清后，再询问订单、工序、库存、财务、审批、交付等相邻环节，避免只优化局部却把问题转移到下游。
每个问题都重复“现状 -> 摩擦 -> 影响 -> 期望 -> 证据”的链条，直到能够区分独立问题、同一问题的不同表现和无需产品化的流程问题。
只有在问题和期望结果被确认后，才比较当前方式与候选方案。不要只讲功能清单，应说明减少了哪个步骤、降低了哪种错误、让谁更早获得什么信息，以及如何验收。
| 层次 | 目标 | 示例问题 |
|---|---|---|
| 目标 | 知道客户想达成什么结果 | 这项工作做得理想时，您希望看到什么变化？ |
| 现状 | 还原真实流程 | 最近一次是怎么完成的？谁先做、谁审核、信息在哪里？ |
| 摩擦 | 找具体阻塞 | 哪一步最耗时、最容易返工或最依赖某个人？ |
| 频率 | 判断覆盖面 | 多久发生一次？影响多少订单、门店、员工或客户？ |
| 代价 | 判断不做的损失 | 目前额外花了多少时间/费用？出现错误后如何补救？ |
| 替代 | 识别真实竞争方案 | 现在不用新系统时怎么解决？为什么仍愿意继续用？ |
| 期望 | 定义成功状态 | 如果只能改善一件事，最希望先改善什么？ |
| 决策 | 判断推进条件 | 谁会参与评估？预算、时间、合规和接口有哪些约束？ |
| 证据 | 防止只凭印象 | 能否提供一次流程记录、报表、截图或异常案例用于核对？ |
客户/角色：
业务目标：
触发场景：
当前流程：
具体摩擦与最近案例：
频率/影响范围/量化代价：
当前替代方案：
期望结果与成功标准：
决策链、预算、时间、合规/接口约束：
原始证据：
待确认问题：
候选动作：继续验证 / 形成需求簇 / 流程改进 / 培训解释 / 产品方案把销售/企微跟进、客户访谈和产品需求池连成一个可审计闭环。它回答的不是“客户提了什么功能”，而是：客户在什么场景遇到什么问题、证据有多强、为什么值得解决、由产品/流程/配置/培训中的哪种手段处理，以及下一步由谁在何时验证。
| 对象 | 负责记录什么 | 典型 Owner |
|---|---|---|
| 线索/商机 | 客户、来源、阶段、下一动作、决策链和推进证据 | 销售/售前 |
| 客户声音 | 原话、角色、场景、当前做法、摩擦、影响和期望 | 销售/产品/客户成功 |
| 需求簇 | 多条声音背后的共同目标与阻塞、证据强度、影响范围 | 产品经理 |
| 迭代项 | 产品方案、范围、成本、优先级、版本、验收和上线结果 | 产品/研发/测试 |
这四类对象不能混成一张“万能表”。它们应通过 ID 和证据链接关联：一个商机可以产生多条客户声音，多条声音可以合并成一个需求簇，一个需求簇可以拆成多个迭代项或转为非研发动作。
记录来源、客户/联系人、渠道、区域/行业、Owner、分配时间和首次响应 SLA。未命中分配规则的线索进入待分配队列，不允许静默丢失。
先确认客户正在解决的工作和当前阶段，再决定提供资料、预约访谈、演示还是结束跟进。第一条消息的合格结果是形成回应或明确不适配，不是“消息已发送”。
按“目标 -> 现状 -> 摩擦 -> 影响 -> 替代 -> 期望 -> 决策约束 -> 证据”提问。保存原话和证据附件，结构化结论与原始声音分开。
产品按共同用户目标/共同阻塞合并，不按关键词或客户名称合并。每个簇保留来源客户数、原始证据数、不同角色和冲突意见。
| 判断 | 路由 |
|---|---|
| 已承诺能力失效 | 缺陷/质量闭环 |
| 能力存在但找不到/不会用 | 交互、信息架构、培训或运营解释 |
| 标准能力缺失且价值证据成立 | 产品需求/PRD 候选 |
| 单客户特殊流程或合同承诺 | 定制/项目方案，单独核价和交付边界 |
| 场景与价值不清 | discovery/原型/数据验证 |
| 价值弱、战略不符或成本过高 | 暂缓/拒绝，并记录理由 |
建议把优先级拆为五项，而不是直接给 P0/P1：
优先级判断 = 影响范围 × 价值 × 证据强度 × 战略匹配 ÷ 成本与风险
每个维度都要保存依据。分数用于对话，不代替产品、研发、交付和业务负责人的共同决策。
高优需求进入 PRD 前要补范围、非目标、规则、异常、权限/数据、验收和成功指标。证据不足的需求生成验证任务；不需要研发的需求生成流程/培训/配置动作。所有动作都要有 Owner、截止时间和通过标准。
产品决策回写 CRM/客户声音记录：已纳入哪个版本、需要补什么证据、为何暂缓/拒绝、是否有替代办法。上线后回访客户并记录结果，防止需求池只进不出。
raw_voice
-> needs_clarification
-> clustered
-> discovery | defect | operation | custom_project | product_candidate
-> accepted | deferred | rejected | merged
-> planned
-> delivered
-> validated | rolled_back | reopened状态变化必须记录操作者、时间、原因和证据。rejected 与
deferred 不能直接删除；delivered
也不等于价值已经验证。
standards-stack/agent-skills/skills/prd-requirements-analysis/SKILL.mdstandards-stack/llm-wiki/product-methods/requirement-four-layer-method.mdstandards-stack/llm-wiki/product-methods/consumer-pain-point-discovery.mdmodules/product/requirements/customer-journey-sales-flow/standards-stack/llm-wiki/sales/b2b-sales-forecast-ai.md