B端需求调研模板：客户访谈与需求证据矩阵

B 端需求调研的难点，不是“应该问哪些问题”，而是购买者、决策者、管理员、终端用户和实施人员往往不是同一群人。同一句“需要批量导出”，可能分别意味着管理者要复盘、操作员在绕过低效流程、安全团队担心数据泄露。直接把客户原话写进需求池，会把问题、方案和销售承诺混在一起。

一轮可执行的 B2B 调研应完成三个交付物：

1. 角色与工作流图：谁发起、执行、审批、配置、支持和付费；
2. 访谈记录：围绕近期真实任务，分别保存观察、原话和研究者解释；
3. 需求证据矩阵：合并跨角色证据，决定做标准功能、配置能力、集成、定制，还是暂不做。

本文提供两份无需注册的 CSV 模板和完整使用方法。模板帮助团队组织证据，不替代隐私、安全或法律评审。

一、免费下载模板

• 下载 B2B 客户访谈提纲与记录表
• 下载 B2B 需求证据矩阵
• 查看中文字段说明和使用指南

CSV 中的示例均为明确标注的合成教学数据，不是 Offer库 的客户研究结果。复制空白行开始使用，不要把示例当作真实证据。

二、先写“这轮调研要支持什么决定”

不要以“了解用户需求”为唯一目标。先写出团队需要做的决定，例如：

我们要决定合同审批能力应做成所有客户可用的标准工作流，还是只通过现有配置满足某一类客户。

然后把意见改写成可研究的问题：

GOV.UK 的用户研究指南建议从研究问题、用户群体和可行动的决策出发规划研究，并让结论进入团队的优先级和交付流程。可参考用户研究规划。

一页研究简报

访谈前与销售、实施、客户成功、设计和研发共同确认：

• 决策：本轮结果会影响哪个版本、流程或资源分配；
• 已知事实：来自产品数据、支持记录、合同或既有研究；
• 待验证假设：目前是谁的判断，什么证据会推翻它；
• 目标角色：需要覆盖哪些参与者，而不只是最容易联系的人；
• 范围：本轮研究包含和不包含什么；
• 产出：角色图、工作流、证据矩阵和下一轮验证；
• 负责人和日期：谁招募、主持、记录、分析和做决定。

如果一条研究问题无论得到什么答案都不会改变决策，就先降低优先级。

三、按工作流画角色，而不是只看职位

先用一条真实业务流程识别角色。例如“销售折扣申请”可能包含：

职位名称不是稳定的研究分组。同为“运营主管”，一家公司可能拥有配置权，另一家公司只能提工单。模板中的 role_type 应记录其在工作流中的作用，company_segment 只保留对决策有用且允许收集的组织特征。

四、把研究问题改成中立访谈提纲

研究问题属于团队，访谈问题说给参与者听。优先询问最近发生的真实事件：

1. 请回忆最近一次完成这个任务，从什么触发开始？
2. 当时谁参与了，每个人负责什么？
3. 请按顺序展示或描述你实际做了什么。
4. 哪一步需要等待、返工、复制数据或请别人帮忙？
5. 当它失败时，下一步会发生什么，影响谁？
6. 你现在用什么方式绕过去？为什么还能接受或不能接受？
7. 上一次出现例外是什么情况？最后怎样处理？
8. 哪些信息、权限或系统连接是完成任务的前提？

继续追问“什么时候、谁、怎么做、能否展示最近一次”，少问抽象偏好。

避免引导式问法

深度访谈适合了解用户的工作、环境和问题。GOV.UK 建议围绕研究问题组织主题，用开放、中立的问题获取真实故事，并在正式访谈前试跑提纲；详见深度访谈指南。

五、知情同意和最少数据收集

模板不是联系人管理表。尽量用 session_id 关联记录，不在访谈 CSV 中填写姓名、手机号、邮箱、客户机密或未经允许的逐字录音。

开始前应让参与者理解：

• 谁在研究、目的是什么；
• 会收集什么数据，如何使用和与谁共享；
• 是否有人旁听，是否录音或录屏；
• 参与是自愿的，可以停止或撤回；
• 数据保存多久，如何联系负责团队；
• 哪些内容会被匿名引用。

分别记录参与同意和录制同意；同意参加访谈不自动等于同意录音。GOV.UK 的知情同意指南与参与者隐私指南强调：只收集回答研究问题所需的数据，限制访问，并在不再需要或参与者撤回同意时按组织规则处理。

实际研究必须遵守所在地法律、合同和组织的数据政策；涉及敏感信息、未成年人、员工研究或跨境数据时，请让隐私或法律负责人审查方案。

六、记录事实、原话和解释

一个好记录应能让未参加访谈的人分辨：

• 观察事实：参与者在三个系统间复制订单号；
• 匿名原话或笔记：参与者说明每周五要手工核对；
• 研究者解释：系统间缺少统一标识可能造成返工；
• 待验证问题：其他角色是否采用同一流程；
• 后续动作：检查日志、观察另一家公司或测试原型。

不要把解释伪装成事实，也不要为了让结论更有说服力而拼接原话。evidence_quote_or_note 字段应使用匿名摘要；真正的原始记录保存在获批系统中，并通过 session_id 关联。

访谈结束后尽快做 15 分钟复盘：主持人和记录者分别写下最重要的观察、反例和未知项，再对照记录。先保留分歧，不急着把每个发现都变成功能。

七、用需求证据矩阵合并多角色信息

每一行矩阵描述一个问题，不是一项预设功能。推荐这样填写：

1. problem_statement：角色在什么场景下无法完成什么目标，造成什么影响；
2. role_types：哪些角色提供或受到该问题影响；
3. source_session_ids：关联证据来源，避免“大家都说”；
4. frequency 与 impact：分别记录发生频率和后果，不用一个主观分数替代；
5. existing_workaround：当前替代方式及其成本；
6. evidence_strength：区分单次陈述、重复行为、观察记录、产品数据或多来源一致证据；
7. risk：安全、合规、收入、交付或体验风险；
8. next_test：还需要什么证据才能做决定。

证据数量不等于市场占比

五次访谈中三人提到某问题，只说明这批研究出现了该模式，不能直接推出“60% 客户都有该需求”。访谈用于理解机制和差异；市场规模、使用频率或转化影响还应结合代表性抽样、产品数据、支持工单和商业数据。

反例同样重要。如果四位管理员都要求更多配置，而一位管理员通过简化流程避免了配置，后者可能提示更低成本的产品方向。

八、从证据决定标准化、配置、集成或定制

把客户请求分到以下路径，而不是只做“做/不做”：

决定 solution_route 时同时记录反对证据、影响的现有客户、负责人和 review_date。销售紧急程度可以进入决策，但不能替代用户证据和长期维护成本。

权限类需求尤其要先识别主体、资源、动作和数据范围，再进入方案。可配合B2B SaaS 权限模型设计使用本模板。

九、合成示例：折扣审批调研

以下仅演示证据如何流转，不代表真实客户或研究结果。

团队收到“增加批量审批”请求后，没有直接排期，而是分别研究申请人、区域主管和财务：

• 申请人真正的问题是退回原因不清楚，重复填写；
• 区域主管只在月底积压时需要连续处理，但高折扣仍需逐条核对；
• 财务关心申请人与审批人职责分离，以及规则变更后的审计记录；
• 现有绕行方式是在线下表格汇总，再回到系统逐条操作。

矩阵可拆出三个不同问题：

1. 退回原因缺少结构化反馈；
2. 低风险同类申请的处理效率低；
3. 高风险审批需要职责分离和可追溯规则。

因此下一步不一定是“一键批量通过”。团队可以先测试结构化退回原因、低风险筛选与连续审核，再单独验证批量动作的权限、确认和审计边界。这个过程把一句功能请求变成可验证的产品决定。

十、把调研变成可追踪的产品交付

一轮研究结束时，至少完成：

• 每个结论能回到匿名 session_id 或其他证据；
• 购买者、管理员、终端用户和交付角色没有被混为一类；
• 事实、原话、解释和假设可以区分；
• 记录了反例与未覆盖人群；
• 不用访谈次数冒充市场占比；
• 每个优先问题有 owner、next_test 和 review_date；
• 方案路径包含标准化、配置、集成、服务、定制和不做；
• 个人数据、录制和保留方式符合有效同意与组织规则；
• 决策结果回传给参与的销售、实施、客户成功和研发团队。

想进一步理解 B2B 产品从需求到交付的完整职责，可阅读B2B 产品经理岗位指南；需要把调研继续做成项目交付物，可查看B2B SaaS 产品设计项目；更多相关内容在B2B 产品专题。