B 端访谈里，先把使用者、采购、审批和 IT 分开

教程定位

这篇教程解决什么问题

B 端访谈里最容易出现的一种误判，是把同一家公司里的不同角色合并成一个“客户声音”。使用者说“现在每天导数据太麻烦”，采购人说“合同和预算周期要再看”，审批人说“先证明这件事值得投入”，IT 管理员说“账号、权限、数据流向和接口边界必须清楚”。这四句话都来自同一家公司，也都可能是真实反馈，但它们不是同一种需求，更不能被合并成“客户想要一个更便宜、更安全、更好用、ROI 更高的产品”。

很多团队做完 B 端访谈后，纪要里会出现这样的句子：“客户反馈权限要灵活，价格要合适，审批要简单，数据要安全，最好能快速上线。”这句话看起来完整，其实危险。它把使用者的日常任务、采购人的流程约束、审批人的投入判断、IT 的技术准入要求放进同一个篮子里。后续产品讨论时，大家就会争论“客户到底最在意什么”，但这个问题本身已经问错了。同一家公司里，不同角色在不同节点上在意的事情本来就不一样。

这篇教程解决的是访谈整理和补访设计问题：用 AI 把 B 端访谈对象按角色、任务、影响力和决策节点拆开，生成一张“角色与决策链表”。它帮助产品经理和售前负责人看清：谁是在描述真实使用场景，谁是在描述采购流程，谁有审批或否决影响，谁只是转述别人意见，哪些结论有证据，哪些角色还没有访谈到。

AI 在这里的价值不是替你判断这个客户该怎么推进，也不是做账户销售策略。它更像一个严谨的整理助手：把访谈名单、组织架构线索、采购流程、使用场景和销售跟进记录放在一起，区分“角色事实”“角色诉求”“证据来源”“影响节点”和“待补访对象”。最终交付物是一张表，能让团队避免用某一个积极使用者代表采购人，用采购人的价格反馈代表使用者体验，或用 IT 的安全问题否定业务需求。

这篇文章的边界也要说清楚：它不教你如何经营客户关系，不建议你绕过联系人找老板，不设计销售推进路线，也不输出赢单策略。它只处理产品调研里的一个具体动作：当同一家公司出现多个声音时，先把声音放回各自角色和决策节点，再决定还要问谁、补什么证据。

使用场景

什么情况下最适合用这一套

你可能是 B 端产品经理，也可能是售前负责人。团队正在调研一个面向企业客户的新能力，比如审批自动化、销售跟进看板、知识库权限、工单流转、数据分析或合同管理。你们约到了一家目标客户，访谈对象包括业务部门的一线使用者、部门负责人、采购同事、IT 管理员，也可能还有一个没有出席但经常被提到的老板或财务审批人。

访谈过程很热闹。使用者讲了很多工作里的麻烦：每天要从多个系统复制数据，字段口径不一致，主管临时要报表时要加班整理。业务负责人关心的是团队能不能真的执行：如果系统要求一线多填字段，他们会不会抵触；如果流程改了，谁来培训；如果看板不准，主管还要不要用。采购人更关注预算、合同周期、供应商资质、付款方式和服务范围。审批人可能没有讲太多功能，只问投入产出、风险责任和上线后谁负责效果。IT 管理员则一直在问数据存储位置、单点登录、权限模型、接口调用、日志审计和实施工作量。

会议结束后，问题来了。产品团队打开纪要，看到的不是一条清晰需求，而是一团互相拉扯的声音。有人说“客户最关心效率”，有人说“客户最大问题是预算”，有人说“IT 卡得很严”，有人说“老板好像还没被说服”。如果这时直接让 AI 总结“客户需求”，它很可能输出一段圆滑但没法决策的摘要：客户希望提升效率、降低成本、保障安全、缩短上线周期，并希望系统易用可控。

这段摘要没有错，但几乎没有用。因为它没有回答四个关键问题：

这篇方法适合以下情况：

它不适合用来替代客户画像，也不适合拿来做销售作战图。如果你的目标是“如何赢下这个客户”，那是销售策略；如果你的目标是“如何从这个客户身上理解 B 端需求为什么分裂”，本文才适用。

• 哪些话来自真实使用者，哪些话来自采购或审批流程？
• 哪些角色讲的是自己亲身任务，哪些只是转述别人意见？
• 哪些要求是产品体验问题，哪些是进入采购或上线前的准入条件？
• 现在还缺谁的声音，继续访谈应该补谁？
• 同一家客户里已经出现使用者、采购人、审批人、IT 管理员等多个角色。
• 访谈记录里有大量“客户说”，但没有标清是谁说、在什么场景下说、说的是自己的任务还是别人的判断。
• 团队正在做 B 端产品调研，希望理解需求结构，而不是制定商机推进策略。
• 销售跟进记录里有组织架构、采购流程、审批节点等线索，但产品团队不知道哪些能作为需求证据。
• 你需要判断下一轮补访应该找一线使用者、业务负责人、采购、IT，还是审批人。

材料准备

开始前先把材料和边界备齐

使用 AI 拆角色前，先准备五类材料。材料不需要完美，但必须标明来源。B 端访谈最大的风险不是信息少，而是来源混乱。一个销售备注里的“客户很重视安全”，和 IT 管理员原话“我们需要确认日志留存和权限审批记录”，不是同一级证据。

第一类是访谈名单。至少列出每个受访对象的姓名或脱敏代号、部门、职位、参加过哪次会议、是否直接使用产品、是否参与采购或审批。不要只写“客户 A、客户 B”。在 B 端场景里，“客户”不是一个人，而是一组角色。

第二类是组织架构线索。你不需要完整组织图，但要知道与本产品相关的局部关系：使用部门归谁管，IT 是总部统一管理还是业务部门自主管理，采购是否独立，审批最终到部门负责人、财务、老板还是信息安全委员会。没有证据的关系不要补全，直接标“未知，待确认”。

第三类是采购流程。包括预算来源、供应商准入、合同审批、付款周期、法务或信息安全审查、试点到正式采购的条件。采购流程不是需求本身，但它会影响产品进入客户组织的门槛。产品经理需要知道它，却不能把它误写成使用需求。

第四类是使用场景。包括一线使用者现在怎么工作、什么时候遇到问题、用哪些系统或表格、谁会检查结果、错了会造成什么后果。使用场景是理解产品价值的核心证据，必须和采购、审批、IT 的要求分开记录。

第五类是销售跟进记录。销售记录里经常有非常关键的线索，比如“客户说老板关心投入产出”“IT 要先看安全材料”“采购要求补供应商资质”“业务负责人希望先小范围试点”。这些记录可以用，但要降级为线索，不能直接写成事实结论。尤其是“客户内部推不动”“老板不支持”“IT 卡住了”这类判断，必须拆回具体证据。

建议把输入材料先整理成下面这样的结构：

| 材料类型 | 应该提供什么 | 使用时的注意点 | | --- | --- | --- | | 访谈名单 | 角色、部门、职位、参加会议、是否直接使用 | 不要把所有人都写成“客户” | | 组织架构线索 | 汇报关系、协作关系、技术管理归属 | 没证据就标未知，不让 AI 猜 | | 采购流程 | 预算、合同、供应商准入、付款、法务安全审查 | 这是流程约束，不等于功能需求 | | 使用场景 | 任务、触发、工具、痛点、后果、当前替代方案 | 优先保留原话和具体经历 | | 销售跟进记录 | 邮件、会议纪要、跟进备注、客户转述 | 区分原话、观察和销售判断 |

还要提前设定输出边界。请明确告诉 AI：这次输出不是销售推进建议，不要推荐下一步如何说服谁，不要设计账户经营动作；只生成角色拆分、证据来源、待补访对象和待验证问题。边界越清楚，AI 越不容易把产品调研写成大客户销售策略。

实操流程

按这套步骤把工作跑起来

第一步，把所有“客户说”还原成具体说话人。

先不要总结需求。把访谈纪要里所有“客户说”“客户觉得”“客户希望”“客户担心”改成“哪个角色说”。例如：

这一步看似朴素，却能立刻减少很多误判。只要你还写“客户想要权限灵活”，团队就会继续争论这到底是使用需求、审批要求还是 IT 要求。改成“IT D 要确认字段级权限；业务负责人 E 要避免一线看错数据；使用者 A 希望少填重复字段”，问题就清楚很多。

第二步，给每个角色标注“任务”，而不是只标职位。

职位告诉你这个人在组织里叫什么，任务告诉你他为什么出现在这次访谈里。使用者的任务可能是录入、查询、处理、审核、汇报；采购人的任务是完成供应商选择和合同流程；审批人的任务是判断投入是否值得、风险是否可控；IT 管理员的任务是保证系统安全、集成可控、权限清晰、上线后能维护。

同一个职位也可能有不同任务。一个业务负责人既可能是使用者的上级，也可能是审批影响者；一个 IT 管理员既可能只是技术评估者，也可能拥有否决权；一个采购专员可能只是流程执行人，不一定能决定买不买。让 AI 把“职位”和“本次决策链角色”分开写，才能避免把组织身份误解为需求身份。

第三步，区分四类角色声音。

使用者声音通常来自具体工作经历，关键词是“我怎么做、哪里费时间、什么时候出错、现在怎么绕”。它的证据最好是最近一次任务回溯、原始工作流、截图、表格、系统记录或访谈原话。它回答的是产品是否解决真实任务。

采购声音通常来自流程和条件，关键词是“预算、合同、供应商、付款、报价、服务范围、采购周期”。它的证据来自采购邮件、采购清单、合同问题、供应商准入要求。它回答的是这个产品能否进入采购流程，不等于功能是否有价值。

审批声音通常来自投入判断和责任边界，关键词是“ROI、风险、谁负责、上线范围、试点结果、是否值得换流程”。它的证据可能是审批人原话，也可能是业务负责人或销售的转述。转述必须标清，不能直接当审批人的真实态度。

IT 管理员声音通常来自技术准入和后续维护，关键词是“账号体系、权限、数据流向、接口、日志、安全、部署、实施工作量、故障责任”。它的证据来自技术问答、信息安全清单、接口文档要求、IT 会议纪要。它回答的是能不能安全接入和稳定运维，不等于业务不需要。

第四步，标出“影响力”和“证据强度”。

不要把每个角色的话都当成同等权重。影响力可以先用“高 / 中 / 低 / 未知”标注，但必须说明依据。比如使用者 A 说得最详细，但只能影响体验反馈，不能决定采购；IT D 不关心日常效率，但如果他有技术否决权，影响力就很高；采购 B 追报价不代表反对，只说明流程进入了采购材料收集阶段；审批人 C 没有出席，所有态度都来自转述，证据强度应该是低或待确认。

证据强度建议分三档：

第五步，把角色放到决策节点上。

角色与决策链表不是组织架构图，也不是销售关系图。它只回答本次调研需要理解的决策节点：谁提出问题，谁使用产品，谁判断价值，谁审核技术，谁处理采购，谁批准投入，谁会在上线后承担责任。

一个简化的 B 端链条可以这样看：

使用场景出现问题 -> 业务负责人确认问题值得解决 -> IT 确认可接入和可维护 -> 采购确认流程和合同条件 -> 审批人确认投入和风险 -> 使用者正式迁移流程。

不同公司顺序会变化，但每个节点都要问：当前是谁在代表这个节点发声？有没有直接证据？如果没有，待补访对象是谁？

第六步，生成“待补访对象”，而不是直接生成结论。

很多 AI 输出会急着总结：“客户需要更灵活的权限和更清晰的 ROI。”在 B 端角色拆分里，更好的输出是：“使用者场景已有强证据，但审批人需求仅来自转述，需要补访审批人或拿到审批标准；IT 提出安全问题但未表达反对，需要补技术准入清单；采购流程已出现但预算归属未知，需要确认预算来自业务部门还是集中采购。”

待补访对象要具体到角色和要问的问题。例如：

第七步，人工复核表格中的边界。

AI 生成后，产品经理要逐格检查：有没有把采购要求写成产品需求，有没有把 IT 问题写成反对意见，有没有把审批人转述写成审批人原话，有没有把某个积极使用者当成整个客户的代表。只要发现这类问题，就要求 AI 改写为“角色 + 证据 + 未知项 + 待补访”。

• “使用者 A 说，每周五要从 CRM 和财务系统导出数据，再手工对齐客户名称。”
• “采购 B 说，供应商需要先进入合格名单，合同审批一般 2 到 4 周。”
• “审批人 C 通过业务负责人转述，关注上线后能否看到明确节省的人力成本。”
• “IT D 在会议中问，是否支持单点登录、字段级权限和操作日志导出。”
• 强证据：角色本人原话、会议录音摘要、邮件原文、系统行为数据、明确流程文件。
• 中证据：销售或售前当场记录、会议纪要摘要、客户成功复述的互动事实。
• 弱证据：销售判断、团队猜测、其他角色转述、没有上下文的“客户觉得”。
• 补访一线使用者：确认每天重复录入发生在哪些步骤，哪些字段必须重复维护，错误后果是什么。
• 补访业务负责人：确认这个问题是否影响团队目标，愿意用什么指标判断试点成功。
• 补访采购人：确认供应商准入和合同审批材料，不问功能喜好。
• 补访审批人：确认投入判断标准、风险责任和试点通过条件。
• 补访 IT 管理员：确认权限、数据流向、接口、日志和上线维护边界。

输入示例

可以直接参考的输入材料

下面是一份可以直接粘给 AI 的脱敏输入。示例为虚构客户，只用于展示写法。

这个输入样例的关键，是把“使用场景”“采购审批线索”“IT 技术问答”“销售判断”拆开。只要输入时已经分层，AI 就更容易输出一张可检查的角色表，而不是写成一段含糊的客户摘要。

【本次任务】
请帮我把一个 B 端客户访谈记录拆成“角色与决策链表”。目标是做产品调研，不是销售推进策略。请不要建议我如何说服客户，也不要输出账户关系经营方案。

【客户背景】
客户代号：海川制造，虚构公司，约 900 人。
正在评估：一套跨部门工单和审批自动化工具。
当前阶段：完成两次业务访谈和一次技术问答，还没有进入正式采购。

【访谈和互动对象】
1. A：生产运营专员，一线使用者，参加第一次访谈。
2. B：生产运营经理，A 的直属上级，参加两次访谈。
3. C：采购专员，通过邮件索要报价区间、供应商资质和合同模板。
4. D：IT 管理员，参加技术问答，负责账号、权限和系统对接评估。
5. E：运营副总，未参加会议，由 B 转述“最后要看试点效果和投入产出”。

【使用场景记录】
- A 说：现在异常工单先在车间微信群报，再由运营助理复制到 Excel，每天下午统一发给相关部门。
- A 说：最麻烦的是同一个异常要改三次状态，微信群、Excel 和内部系统都要同步。
- A 说：如果状态漏改，第二天早会会被追问，严重时会影响交付排期。
- B 说：他希望主管能看到哪些异常超过 24 小时没处理，但担心一线觉得多填系统麻烦。

【采购和审批线索】
- C 邮件要求补充：报价区间、付款方式、供应商资质、服务范围、合同模板。
- B 转述：E 需要看到小范围试点效果，尤其是异常处理时长是否下降。
- 当前不清楚预算来自运营部门还是公司统一数字化预算。

【IT 技术问答】
- D 问：是否支持企业微信或单点登录。
- D 问：数据存在哪里，能否导出操作日志。
- D 问：字段权限能否区分车间、部门主管和运营管理层。
- D 说：如果要接内部系统，需要先确认接口工作量。

【销售跟进备注】
- 销售判断：A 和 B 很积极。
- 销售判断：D 不是反对，只是在收集技术边界。
- 销售判断：E 可能会关心 ROI，但目前没有 E 的直接原话。

【希望输出】
请输出：
1. 角色与决策链表，列出角色、任务、影响力、主要问题、证据来源、证据强度、当前未知项、待补访对象。
2. 把使用者、采购、审批人和 IT 管理员的诉求分开。
3. 标出哪些结论来自本人原话，哪些只是转述或销售判断。
4. 输出下一轮产品调研应该补访谁、问什么。
5. 不要输出销售策略，不要建议绕过联系人，不要编造组织关系。

提示词

可复制使用的提示词

你可以直接复制下面这段提示词，把方括号里的内容替换成自己的材料。

如果材料比较长，可以先让 AI 只做 A 和 B。等表格检查无误后，再继续生成 C 到 F。不要一开始就要求它写完整报告，否则它可能为了顺滑叙述而丢掉证据边界。

你是一名谨慎的 B 端产品调研整理助手。请根据我提供的访谈名单、组织架构线索、采购流程、使用场景和销售跟进记录，生成一张“B 端角色与决策链表”。

本次任务的目标：
- 把同一家公司里的使用者、采购人、审批人、IT 管理员等角色分开；
- 识别每个角色正在完成的任务、关心的问题、影响的决策节点；
- 标出每个判断的证据来源和证据强度；
- 找出还缺哪些角色声音，以及下一轮产品调研应该补访谁；
- 避免用某一个角色代表整个客户需求。

重要边界：
1. 这是产品调研整理，不是账户销售策略。
2. 不要建议如何说服客户、绕过联系人、推进成交或经营组织关系。
3. 不要把采购流程要求写成使用者需求。
4. 不要把 IT 的技术准入问题写成业务反对。
5. 不要把审批人的转述写成审批人本人原话。
6. 如果材料里没有证据，请写“未知，待确认”，不要编造组织架构或态度。

请按以下结构输出：

A. 角色拆分摘要
- 这家公司目前出现了哪些角色声音
- 哪些声音来自本人原话
- 哪些声音来自转述、销售判断或流程材料
- 哪些角色还没有直接访谈

B. B 端角色与决策链表
请用表格输出，字段包括：
| 角色/对象 | 本次身份 | 主要任务 | 影响的决策节点 | 当前诉求或问题 | 证据来源 | 证据强度 | 不能得出的结论 | 当前未知项 | 待补访对象与问题 |

C. 四类角色分开解读
- 使用者：真实使用场景、现有替代方案、痛点后果、待补证据
- 采购人：流程、合同、预算、供应商准入、待补证据
- 审批人：投入产出、风险责任、试点通过标准、待补证据
- IT 管理员：账号、权限、数据、安全、接口、运维、待补证据

D. 待补访清单
请按优先级列出：
| 待补访角色 | 为什么要补访 | 应该问什么 | 不应该问什么 | 预期补齐哪类证据 |

E. 误判风险提醒
列出至少 8 条本材料中容易误判的地方，例如：
- 把使用者积极当成公司已决定采购；
- 把采购索要材料当成压价或反对；
- 把 IT 问安全问题当成否定业务需求；
- 把审批人转述当成审批人原话。

F. 可带回团队讨论的结论
请只输出和产品调研有关的结论，包括：
- 哪些需求来自真实任务；
- 哪些只是流程或准入条件；
- 哪些结论证据不足；
- 下一轮调研应该补什么。

这是我的材料：
[粘贴访谈名单、组织架构线索、采购流程、使用场景、销售跟进记录]

输出样例

AI 应该输出到什么程度

下面是基于前面虚构输入，AI 可能输出的一段样例。真实项目中，请继续根据原始纪要复核。

教程正文

A. 角色拆分摘要

当前客户里至少出现 5 类角色声音：

不能把 A 和 B 的积极反馈写成“客户已认可价值”；不能把 C 索要材料写成“客户主要关心价格”；不能把 D 的安全问题写成“IT 反对上线”；不能把 E 的 ROI 关注写成审批人本人已经确认的采购条件。

1. 一线使用者 A：有本人原话，主要描述异常工单在微信群、Excel 和内部系统之间重复同步的问题。
2. 业务负责人 B：有本人原话，也有对审批人 E 的转述；主要关注主管视角和一线执行阻力。
3. 采购 C：有邮件证据，主要处理报价、合同、供应商资质和服务范围。
4. IT 管理员 D：有技术问答证据，主要关注账号、权限、数据、日志和接口工作量。
5. 审批人 E：未直接访谈，目前只有 B 的转述，证据强度较弱。

教程正文

B. B 端角色与决策链表

| 角色/对象 | 本次身份 | 主要任务 | 影响的决策节点 | 当前诉求或问题 | 证据来源 | 证据强度 | 不能得出的结论 | 当前未知项 | 待补访对象与问题 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | A 生产运营专员 | 一线使用者 | 记录异常、同步状态、支持早会追踪 | 使用场景成立、体验可用性 | 同一异常要在微信群、Excel、内部系统重复改状态；漏改会被早会追问 | A 本人访谈原话 | 强 | 不能推出采购意愿或预算可用 | 重复同步每周耗时、错误频率、哪些字段最关键 | 补访 A：最近一次漏改状态发生了什么，造成什么后果 | | B 生产运营经理 | 业务负责人/影响者 | 管理异常处理效率，评估团队是否能执行 | 价值判断、试点标准、是否继续评估 | 希望看到超过 24 小时未处理异常；担心一线多填系统 | B 本人访谈原话 | 强 | 不能推出最终审批已经通过 | 试点成功指标、主管会如何使用看板 | 补访 B：如果做小范围试点，你会用哪些指标判断值得继续 | | C 采购专员 | 采购流程角色 | 收集报价、资质、合同和付款信息 | 采购材料完整性、合同流程 | 要求补报价区间、付款方式、供应商资质、服务范围和合同模板 | C 邮件 | 强 | 不能推出 C 反对或压价 | 预算来源、供应商准入周期、是否已有采购清单 | 补访或邮件确认 C：进入采购评估需要哪些固定材料 | | D IT 管理员 | 技术准入/维护角色 | 确认账号、权限、数据、日志、接口和实施工作量 | 技术准入、上线风险、后续维护 | 关注单点登录、数据存储、日志导出、字段权限、接口工作量 | D 技术问答 | 强 | 不能推出 D 否定业务需求 | 安全审查标准、接口必须接哪些系统、谁承担实施 | 补访 D：上线前必须满足哪些技术和安全条件 | | E 运营副总 | 审批人/预算影响者，未直接访谈 | 判断投入产出、风险责任和试点是否值得扩大 | 投入审批、试点通过、正式采购 | 据 B 转述，关注试点效果和投入产出 | B 转述 | 弱 | 不能写成 E 本人已经确认 ROI 要求 | E 的真实审批标准、可接受试点范围、预算口径 | 补访 E 或请 B 提供审批标准：什么结果会让你认为值得继续 |

教程正文

C. 四类角色分开解读

使用者：目前证据最具体，A 讲到了重复同步、状态漏改和早会追问，说明存在真实任务和后果。下一步应补充频率、耗时、错误率和当前替代方案，不要问 A 是否愿意采购。

采购人：C 的邮件说明采购材料收集已经出现，但不能证明价格是核心问题。下一步应确认供应商准入和材料清单，不要把采购流程问题写进功能需求。

审批人：E 没有直接出现，当前只有 B 转述。团队不能把“看试点效果和投入产出”写成 E 的原话。下一步要补审批标准，或者至少让 B 明确 E 通常看哪些指标。

IT 管理员：D 提出的是技术准入问题，不是业务反对。下一步应补充安全审查清单、接口范围、日志要求和维护责任。产品团队可以把这些作为准入条件，但不要因此否定使用者场景。

教程正文

D. 待补访清单

| 待补访角色 | 为什么要补访 | 应该问什么 | 不应该问什么 | 预期补齐哪类证据 | | --- | --- | --- | --- | --- | | A 一线使用者 | 使用场景已有原话，但缺频率和量化后果 | 最近一次状态漏改发生在哪一步，后来谁发现，影响了什么 | 你觉得我们系统好不好用 | 任务频率、错误后果、替代方案 | | B 业务负责人 | 需要确认试点价值标准 | 如果小范围试点，你会看哪些指标判断有效 | 你能不能推动老板批准 | 试点标准、业务价值判断 | | D IT 管理员 | 技术准入条件尚未形成清单 | 上线前必须确认哪些账号、权限、日志和接口要求 | 你是不是担心系统不安全 | 技术准入证据 | | E 审批人 | 当前只有转述，审批标准证据弱 | 什么样的试点结果说明值得继续投入 | 你是否已经认可这个项目 | 投入产出标准、风险责任 |

这份输出的重点不是“客户有需求”这种大结论，而是把每个角色的证据放回正确位置。产品团队可以据此继续补访，也可以判断哪些反馈应该进入产品需求池，哪些只是采购或技术准入材料。

人工验收

人要怎么检查和改到可用

AI 生成角色与决策链表后，人工要做五轮检查。不要直接把表格当成结论发给团队。

第一轮，检查角色是否被合并。凡是出现“客户希望”“客户担心”“客户认为”这类句子，都要求改成具体角色。如果确实不知道是谁说的，就写“来源不明，需回查纪要”，不要为了好看把它归到某个角色名下。

第二轮，检查证据来源是否足够具体。每一行都应该能追溯到访谈原话、会议纪要、邮件、系统数据、流程文件或销售备注。没有来源的判断要降级为假设。比如“审批人关注 ROI”如果只来自销售判断，就不能写成强证据。

第三轮，检查四类声音是否被混淆。使用者讲的是任务与体验，采购讲的是流程和材料，审批人讲的是投入判断和风险责任，IT 讲的是技术准入和运维边界。它们可以互相影响，但不能互相替代。

第四轮，检查“待补访对象”是否真的能补证据。不要写“继续访谈客户”。要写“补访 IT 管理员 D，确认字段级权限、日志导出和接口工作量是否为上线前必要条件”。对象越具体，下一轮访谈越有价值。

第五轮，检查是否滑向销售策略。表格里可以写“该角色影响哪个决策节点”，但不要写“下一步用 ROI 材料说服 E”“让 A 帮忙推动老板”“绕过采购找业务负责人”。这些不是本文的交付物。本文只要说明：E 的审批标准缺直接证据，需要补访或补材料确认。

建议最终交付物保持一页到两页。B 端角色很多，表格很容易膨胀。产品调研最需要的是清楚的证据边界，而不是复杂的人际地图。

失败反例

这些失败反例要提前避开

反例 1：把最积极的使用者当成整个客户。

错误写法是：“客户强烈需要自动化工单，因为他们现在每天靠微信群和 Excel 同步，很痛。”这句话忽略了一个事实：强烈表达痛点的是一线使用者 A，不是采购、审批人或 IT。更稳的写法是：“一线使用者 A 对重复同步有强痛点，使用场景证据强；但采购流程、审批标准和 IT 准入尚未确认，不能据此判断客户整体采购意愿。”

这个反例常见于产品团队很兴奋的时候。真实任务一旦被讲得很具体，大家会自然觉得需求成立。但 B 端产品不是只要使用者痛就能上线，还要跨过组织里的流程和风险节点。角色拆分不是削弱使用者证据，而是防止它被过度外推。

反例 2：把采购索要材料当成客户主要关心价格。

错误写法是：“客户现在卡在价格和合同，说明他们主要关注成本。”采购专员索要报价、供应商资质、付款方式和合同模板，可能只是正常流程，不一定说明价格是最大阻碍，也不代表业务需求弱。更稳的写法是：“采购 C 已进入材料收集动作，证据显示需要补齐采购评估材料；预算来源、价格敏感度和采购周期仍未知，不能把采购流程等同于价格反对。”

这个反例会让产品团队错误地把问题转成定价或套餐讨论，反而忽略真实使用场景是否成立、试点标准是否清楚。采购声音要记录，但它不是使用者声音，也不是审批人声音。

反例 3：把 IT 的安全问题当成否定需求。

错误写法是：“IT 问了很多权限和接口问题，客户上线风险大，可能不适合做。”IT 管理员问数据存储、单点登录、日志、字段权限和接口工作量，通常是在执行技术准入任务。除非 IT 明确表达“不能接受”并说明原因，否则不能把技术问题写成反对意见。更稳的写法是：“IT D 已提出上线前需要确认的技术准入项，当前态度应标为中立或未知；需要补齐安全审查清单和接口边界。”

这个反例会让产品讨论过早放弃业务需求，也会把技术准入材料误当成产品价值判断。对 B 端产品来说，IT 问题往往意味着你需要更清楚的权限、数据和实施说明，而不是证明用户没有需求。

反例 4：把审批人的转述当成审批人本人结论。

错误写法是：“老板要求 ROI 明确，否则不会批。”如果这句话来自业务负责人或销售转述，就必须保留来源。审批人的真实标准可能更具体，也可能完全不同。更稳的写法是：“据 B 转述，审批人 E 可能关注试点效果和投入产出；当前没有 E 本人原话，证据强度弱，需要补访 E 或获取审批标准。”

这个反例会造成两种后果：一是团队围绕一个并不确定的审批标准做产品取舍；二是后续复盘时分不清到底是审批人要求，还是内部人员的推测。B 端调研里，转述可以作为线索，但不能冒充原话。

反例 5：把角色拆分做成销售关系经营图。

错误写法是：“A 支持我们，可以让 A 带我们找 E；D 需要用技术白皮书打消顾虑；C 先不要给低价。”这已经进入销售策略，不是产品调研整理。本文的正确交付物应该是：“A 的使用场景证据强；E 的审批标准缺直接证据；D 的技术准入项待确认；C 的采购流程材料待补齐。”至于如何触达、由谁沟通、先发什么材料，应该进入销售或客户成功工作流，不放在这张产品调研表里。

主题边界

它和相邻主题的区别

这个主题和“访谈前把客户背景和假设对齐”相邻，但关注点不同。访谈准备简报是在访谈前把客户背景、使用阶段、已知事实和待验证假设整理清楚，防止团队带着混乱材料进会议室。本文是在已经有多角色访谈或跟进记录后，把同一家公司里的声音按角色和决策节点拆开，防止把多个角色合并成一个客户声音。

它也和“用户访谈提纲别从功能清单开始”相邻。场景型访谈提纲解决的是问题怎么问，重点是把功能清单改成任务、场景、触发和替代方案。本文解决的是访谈后怎么整理多角色证据，重点是判断谁说了什么、代表哪个任务或节点、还缺谁的声音。

它还容易和“多联系人商机，画出决策链和阻塞点”混淆。多联系人商机主题面向大客户销售，目的是服务单个商机推进，输出支持者、反对者、阻塞点和下一步触达对象。本文面向产品与调研，目的是避免需求归因错误，输出角色、任务、证据来源、证据强度和待补访对象。一个偏销售推进，一个偏产品理解。

最后，它不是客户画像。客户画像会总结某类客户的共性，例如“制造业客户通常关注数据安全和跨部门协作”。本文不做这种泛化。它只处理一个具体客户或一组访谈材料中的角色拆分：这个使用者说了什么，这个采购人要什么材料，这个审批人有没有直接证据，这个 IT 管理员提出了哪些准入条件。只有先把单个客户里的角色声音拆清楚，后续才有可能做更可靠的跨客户归纳。