销售需求访谈纪要
用途
把销售需求访谈的转写稿、笔记和已知背景整理成可复核的访后纪要，固定区分客户事实、销售方事实、解释假设和待确认项，并输出当前流程、痛点与影响、期望结果、决策条件、证据缺口、明确承诺和建议下一步。
本技能只整理用户提供的材料，不自动读取或写回 CRM，不发送跟进消息，不预测成交概率，也不替客户确定预算、决策权或购买意向。
适用场景
- 适合：B2B 需求发现访谈复盘、售前访谈证据整理、RevOps 商机信息补缺、创始人销售访后交接。
- 不适合：访谈前准备、通用会议决议或全量行动项、客户季度经营回顾、商机自动评分、报价谈判或操纵性销售话术。
与相近技能的区别
client-visit-prep：用于拜访前的目标、材料、风险问题和成功标准；本技能用于访谈后，所有关键结论回到原始发言或材料。meeting-decision-digest、meeting-action-extractor-20260722：整理通用决议或行动；本技能聚焦商业需求、现状、影响和决策条件，不把普通发言升级为决议。qbr-onepager：对照季度目标与经营进展；本技能面向需求发现阶段，不写续约或经营回顾叙事。
怎么使用（普通用户）
在 AI 助手里直接说，例如：
- 「把这次客户需求访谈整理成现状、痛点、影响、决策条件、证据缺口和下一步，别替客户脑补预算。」
- 「按说话人与时间戳保留依据，区分客户原话、销售判断和待确认项。」
- 「复盘这份 discovery call，列出明确承诺、建议追问和相互冲突的信息；不要写 CRM。」
建议提供：
- 访谈日期、客户或账户代号、访谈目的、参与者及已确认角色。
- 转写稿、逐条笔记或聊天记录；有说话人、时间戳或段落号时保留。
- 用户已确认的账户背景、产品范围和本次不讨论事项。
- 可选：上一轮明确结论、内部假设、已有下一步和允许披露范围。
只保留完成纪要所需的信息。手机号、邮箱、账号、合同细节等无关敏感值应删除或改为角色/代号；若输入出现密钥或凭证，输出不得复述。
证据层级
每项关键结论必须标为以下一种：
- 客户已明确：能定位到客户发言、书面材料或用户确认。
- 销售方已明确：销售、售前或内部材料提出的事实、约束或承诺，不冒充客户观点。
- 解释/假设：对影响、方案匹配或推进路径的解释，必须附验证问题。
- 待确认：缺失、冲突、说话人不明、表述含糊或当前参与者无权确认的信息。
来源优先写成“角色 + 时间戳/段落号”，例如 [客户运营负责人 00:08:20]。没有定位信息时写“用户笔记，未标时间”，不得伪造时间戳。
短引语必须忠实于原文；概括要标“转述”。禁止拼接不同句子制造新引语，也不得把沉默、礼貌回应或“可以看看”升级为购买意向。
商业事实红线
- 预算：只有明确金额、范围、来源或“未立预算”等发言才可记录；不得从公司规模、职位或急迫性估算。
- 决策权：只有明确职责、审批关系或流程证据才可记录；职位高不等于最终决策人。
- 时间：区分希望时间、内部目标、硬截止日和销售建议；日期缺失时不补。
- 影响：区分定量结果、定性影响和销售假设；不能把痛点自动换算成 ROI、损失或节省。
- 意向：记录原始表达和上下文，不输出虚构的成交概率、商机评分或“强/弱意向”。
- 承诺：价格、折扣、交期、集成、合规和产品路线图只按已授权事实记录；未经确认的一律待确认。
即使用户提供自有评分框架，也只按其字段和门槛整理并注明来源，不把框架评分伪装成客户事实。
处理流程
1. 固定会议口径
记录账户代号、日期、目的、参与角色、材料范围和来源定位能力。不同账户、会议或日期不得无标记混合。转写明显缺段、角色不明或来源冲突时先写材料缺口。
2. 重建当前流程
按角色、步骤、工具、频次、输入输出、例外和现有替代方案还原“现在怎么做”。只写材料中出现的流程；顺序不清时保留待确认。
3. 建立痛点证据链
每个痛点依次检查：
现状流程 → 触发条件 → 问题表现 → 当前应对 → 可观察影响 → 证据 → 缺口
没有频次、规模或影响证据时只写定性陈述。多个表述仅在对象、条件和结果一致时合并；不同角色或场景保持分开。
4. 提取期望结果
区分客户明确表达的结果、可量化成功标准和销售方假设。客户只描述功能时，不自动改写为业务收益；成功阈值未知时列待确认。
5. 整理决策条件
分别记录：
- 评估标准。
- 决策与审批流程。
- 已确认角色及其职责。
- 希望时间、硬截止日和依赖周期。
- 预算事实。
- 采购、安全、法务、数据、集成等依赖。
“未提到”不等于“不存在”。预算、最终决策人或采购路径未出现时直接写待确认。
6. 保留异议、限制与冲突
并列记录不同版本、各自来源和影响，不擅自选边。明确区分产品限制、客户政策、销售红线和仍待技术验证的能力。
7. 单列方案匹配假设
销售方关于“产品可能适配”的判断只放在假设区，附依据、风险和下一次要验证的问题。客户没有明确认可时，禁止写“客户认可方案”。
8. 形成证据缺口与追问
追问必须对应具体缺口，并说明关闭缺口后能支持什么判断。没有用户给出的权重时，不虚构综合优先级；可先列会阻塞范围、评测或决策流程的缺口。
9. 分开承诺与建议下一步
- 明确承诺：原材料中清楚出现承诺方、动作和时间，并保留来源。
- 待确认承诺：动作已提及，但承诺方或时间不完整。
- 建议下一步：由本技能提出，标明目的、建议参与角色和要关闭的缺口，不伪装成双方已同意。
缺料与降级
- 只有零散笔记：输出“初步纪要”，保留笔记来源和待确认，不编造完整对话。
- 无说话人或时间戳：不做逐条归属；写“材料未标角色/时间”，给出最小补件建议。
- 多份材料冲突：并列冲突版本和来源，指定需要哪个角色确认。
- 没有明确痛点或决策条件：报告“本次材料未形成足够证据”，给出针对性追问，不为填满模板而虚构。
- 用户要求预测成交率或替客户定预算/权力：说明证据不足，只返回可验证事实、假设和补证问题。
输出要求
严格使用 references/discovery-digest-template.md，并遵守：
- 先写会议口径和证据限制，再给需求摘要。
- 所有关键数值、角色、引语、日期和承诺都附来源。
- 客户事实、销售方事实、解释/假设和待确认不得混在同一陈述中。
- 明确承诺与建议下一步分区；未知负责人或期限不补写。
- 输出是内部复盘草稿；若要对外发送，需用户另行审核敏感信息和商务承诺。
完整示例
输入
账户代号：连锁餐饮 A
日期：2026-07-18
目的：了解门店排班汇总问题
参与者：客户运营负责人、客户 IT、我方销售
转写摘录：
[00:02:10 客户运营负责人] 我们有 46 家店。每周四各店长交 Excel，周五运营再合成一张表。
[00:04:05 客户运营负责人] 普通周大概 6 家晚交；促销周经常八九家。我们就在企微群里一个个催。
[00:06:20 客户运营负责人] 我每个周五差不多花 4 小时合表。临时换班后两个版本对不上最麻烦，但没算过损失多少钱。
[00:09:40 客户运营负责人] 希望周五中午前能看到缺班汇总，店长只能看自己店，区域经理能看辖区。
[00:12:15 客户 IT] 登录要接公司 SSO，排班数据不能离开我们的国内租户。试点前要过安全评审。
[00:15:30 客户运营负责人] 可以先让两个区域经理试三周。如果合表从 4 小时降到 1 小时以内，我觉得值得继续看。
[00:17:10 客户运营负责人] 我希望下个月开始。
[00:18:00 客户 IT] 安全评审通常要 6 周，下个月能不能开始我现在不能答应。
[00:20:25 客户运营负责人] 业务上我来牵头，但正式采购谁批我还要回去确认。预算这次没讨论。
[00:23:40 我方销售] 我下周二前发字段清单和试点范围草案。
[00:24:05 客户 IT] 收到字段清单后，我把安全评审材料目录发给你们。
我方内部笔记：也许以后能卖预测排班模块，但客户本次没有提预测需求。
输出
# 销售需求访谈纪要：连锁餐饮 A
## 1. 会议口径
- 日期/目的：2026-07-18；了解门店排班汇总问题。
- 参与角色：客户运营负责人、客户 IT、我方销售。
- 材料：带说话人与时间戳的转写摘录 + 我方内部笔记。
- 限制：只有摘录，不能证明未摘录部分没有其他条件；采购审批人与预算均未知。
## 2. 一句话需求摘要
客户当前由 46 家门店每周提交 Excel、运营人工合表；已确认的主要问题是迟交催办、合表耗时和换班版本不一致。客户希望在权限隔离下于周五中午前看到缺班汇总，并提议先由两个区域经理试三周；试点仍受 SSO、国内租户和安全评审约束。
## 3. 当前流程
| 步骤 | 当前做法 | 证据层级 | 来源 |
| --- | --- | --- | --- |
| 门店提交 | 46 家店每周四由店长提交 Excel | 客户已明确 | [客户运营负责人 00:02:10] |
| 迟交催办 | 普通周约 6 家晚交，促销周经常八九家；企微逐个催 | 客户已明确 | [客户运营负责人 00:04:05] |
| 汇总 | 周五由运营合成一张表，约耗时 4 小时 | 客户已明确 | [客户运营负责人 00:02:10、00:06:20] |
| 临时换班 | 多版本可能不一致，当前处理方式未说明 | 客户已明确 + 待确认 | [客户运营负责人 00:06:20] |
## 4. 痛点与影响证据
| 痛点 | 触发/频次 | 当前应对 | 已确认影响 | 证据缺口 |
| --- | --- | --- | --- | --- |
| 门店迟交 | 普通周约 6 家；促销周经常八九家 | 企微逐个催 | 增加催办工作；耗时未单独统计 | 迟交时长、催办耗时、是否影响出勤 |
| 人工合表 | 每周五 | 人工合成一张表 | 每周约 4 小时 | 样本周期、4 小时是否含催办 |
| 换班版本不一致 | 临时换班时 | 未说明 | 客户称“最麻烦”；未量化财务影响 | 发生次数、错误类型、修正耗时 |
不得把以上信息换算为年度损失或 ROI；客户明确表示未统计损失金额。[客户运营负责人 00:06:20]
## 5. 期望结果与成功标准
- 客户已明确：周五中午前看到缺班汇总。[00:09:40]
- 客户已明确：店长仅看本店，区域经理可看辖区。[00:09:40]
- 客户已明确：两个区域经理试三周。[00:15:30]
- 客户已明确的继续观察门槛：合表从约 4 小时降到 1 小时以内。[00:15:30]
- 待确认：缺班汇总的字段、准确性门槛、迟交提醒规则和评测记录方式。
## 6. 决策条件
| 条件 | 当前证据 | 状态 |
| --- | --- | --- |
| 业务牵头 | 客户运营负责人表示由其牵头 [00:20:25] | 客户已明确 |
| 正式采购审批 | 客户运营负责人需回去确认 [00:20:25] | 待确认；不能推定其为采购决策人 |
| 预算 | 本次未讨论 [00:20:25] | 待确认；不估算金额 |
| 技术/数据 | 接公司 SSO；数据不离开国内租户 [客户 IT 00:12:15] | 客户已明确 |
| 安全流程 | 试点前需安全评审，通常约 6 周 [客户 IT 00:12:15、00:18:00] | 客户已明确 |
| 时间 | 运营希望下个月开始；IT 暂不能承诺 [00:17:10、00:18:00] | 时间预期冲突，待双方确认 |
## 7. 异议、限制与冲突
- 时间冲突：业务希望下月开始，但安全评审通常需 6 周；不得将“希望”写成已确认开工日。
- 数据限制：排班数据不得离开客户国内租户；具体部署与数据流仍待技术验证。
- 未知：正式采购人、预算、字段范围和 SSO 接入责任边界。
## 8. 方案匹配假设
| 假设 | 依据 | 验证问题 |
| --- | --- | --- |
| 汇总与迟交可视化可能适配本次需求 | 客户明确描述人工合表、迟交和缺班汇总目标 | 最小试点是否只需提交、催办、汇总和辖区权限？ |
| 预测排班模块可能有后续机会 | 仅来自我方内部笔记 | 客户是否存在预测需求？本次未提，不纳入试点范围。 |
以上均为销售方假设，不代表客户认可产品能力。
## 9. 证据缺口与建议追问
1. 正式采购由哪些角色审批，安全评审与采购的先后关系是什么？
2. “4 小时”如何记录，试点期间由谁按同口径测量？
3. 缺班汇总的最小字段、准确性要求和迟交提醒规则是什么？
4. 国内租户、SSO 和辖区权限分别由谁提供技术证据？
5. 运营希望的下月开始时间，如何与 6 周安全评审协调？
未提供优先级权重；以上先列会阻塞范围、评测和时间判断的缺口。
## 10. 明确承诺
| 承诺方 | 动作 | 时间 | 来源 |
| --- | --- | --- | --- |
| 我方销售 | 发送字段清单和试点范围草案 | 下周二前 | [我方销售 00:23:40] |
| 客户 IT | 收到字段清单后发送安全评审材料目录 | 收到后，具体日期待确认 | [客户 IT 00:24:05] |
## 11. 建议下一步
- 建议由我方销售在试点范围草案中只纳入提交、催办、汇总、权限和评测，不加入预测排班；目的为避免把内部假设扩成客户需求。
- 建议字段清单发出后，由客户 IT 与运营负责人共同确认安全评审节奏和可行试点窗口；参与人和会议时间尚未约定。
以上是建议，不是双方已确认承诺，不写入 CRM，也不自动发送。
示例中的账户、数值、角色、日期、引语和承诺全部来自示例输入；“建议下一步”和方案匹配均明确标为建议或假设。
质量自检
- 每项关键数值、角色、日期、引语和承诺是否有来源？
- 客户事实、销售方事实、解释/假设和待确认是否明确分层？
- 是否从职位、语气、沉默、规模或急迫性错误推断预算、权力、意向、ROI 或成交率？
- 痛点是否包含现状、触发、表现、应对、影响、证据和缺口？
- 是否保留冲突版本，而非擅自选择一方？
- 明确承诺与建议下一步是否分开？
- 是否移除了无关个人信息、凭证和敏感商业细节？
常见问题（FAQ）
- 转写缺了一段还能整理吗？ 可以，但要写清材料不完整及受影响结论，只形成初步纪要。
- 没有说话人或时间戳怎么办？ 使用原笔记编号或“未标角色/时间”，不能自行归属。
- 能给商机打分或预测成交率吗？ 只有用户提供合法的自有框架和证据时才能按框架整理；本技能不自行评分或预测。
- 能直接写 CRM 吗？ 不能。本技能只输出内部草稿，由用户审核后再决定是否进入 CRM。
- 能顺便写跟进邮件吗？ 本技能不自动生成或发送对客邮件；先确认纪要事实和承诺，再使用专门的回复流程。
- 客户说“可以看看”算意向吗？ 不算。保留原话和上下文，列需要验证的具体下一步。
已知限制
- 只基于用户提供的材料，不能验证客户未表达的内部政治、预算或采购事实。
- 不能替代录音转写、CRM 数据校验、合同审查或销售管理判断。
- 多账户或多轮会议可分批处理，但必须保留账户、日期和来源边界。
- 全中文、无脚本、无海外 API 或外部系统依赖。
变更说明
- 0.1.1: 修正邻近技能引用死链（
meeting-action-extractor已改名为meeting-action-extractor-20260722）；输出结构与判据未变。 - 0.1.0: 首发。把销售需求访谈记录整理成可追溯的现状、痛点、影响、决策条件、证据缺口与下一步。
