# 客户说的不是需求，是他自己挑好的方案

为什么“我们想要一个文档问答机器人”已经替你定好了结论，以及怎么问到方案背后那个真正贵的问题

> 需求发现 · 咨询式销售 · 隐含需求与明确需求 · 约 6 分钟 · 09 月 14 日

## 本篇要点

1. 客户开口说的通常是方案或症状，不是需求：他把每天感受到的挫败翻译成了自己见过的最接近的东西，这个翻译本身很正常，但信息在翻译中丢了。
2. “想要一个文档问答机器人”这类话已经替你定好了界面、数据源、交互方式，还隐含了一个未经检验的诊断结论（“问题出在大家找不到文档”）。
3. 直接按方案报价或开发，是礼貌地把事做错：每个里程碑都满意，上线后没人用，因为真正昂贵的那个步骤没被碰到。
4. 拆解结构是三层：表面诉求（他说的方案或症状）→ 真正要解决的问题（谁在做、哪一步最贵）→ 影响与代价（多久一次、谁受影响、不解决会怎样）。
5. 让方案答不上来的问法：希望它帮你做到什么；上一次具体是什么情况（要具体那一次，不要理想化流程）；多久一次、每次多久；不解决会怎样；之前试过什么、为什么没成。
6. Rackham 的隐含需求（困难、不满）与明确需求（想要）之别决定了停止条件：大额销售里隐含需求的数量与成交无关，必须发展到明确需求；小额销售里隐含需求本身就能成交。
7. 停止条件随场景变：小额且诉求清楚就直接回应，别把挖需求做成审问；大额且动流程的单子，挖到他亲口说出想解决为止。
8. 把三层用客户的原话复述一遍并请他确认，既校验了理解，也让客户第一次听到自己问题的全貌。

---

“我们想要一个文档问答机器人，能不能做？”

这句话听起来是一个很明确的采购需求。你回去做了方案、报了价，客户说“我们再看看”，然后没有下文。多数人这时候会怀疑自己的能力或价格，但更常见的原因在更前面一步：你接住的是他挑好的一个方案，不是他要解决的问题。

上一篇讲的是顺序——先诊断，再开方。这一篇往下挖一层：诊断要诊断什么。因为客户递给你的那句话，通常不是问题本身。

## 客户先说方案，是正常的说话方式

一个每天被同一件事磨的人，向你描述需求时，最先跳出来的往往不是问题，而是他在别处见过的最接近的解决方案。“我们想要个自动报表”“网站太旧了”“你们能不能便宜点”，这些都是方案，或者至少是被方案包装过的症状。

这不是敷衍。一家给售前工程师做发现训练的机构把这个过程说得很直白：客户不是在偷懒，他恰恰是在帮忙——他把自己每天感受到的那点挫败，翻译成了他见过的最近的一个东西，因为被问“你想要什么”时，正常人都会这么回答。[1]

真正值得注意的，是这句翻译里丢掉了什么。“想要一个文档问答机器人”这一句，已经替你定好了四件事：交互界面是对话，数据源是文档库，互动方式是问答，以及——最后一个不用说的——问题出在“大家找不到资料”。前三个是方案选项，第四个是诊断结论。客户把结论和方案一起打包递给了你，而“找不到”这三个字，从来不是经过验证的。

接住方案的代价是可预测的。Sandler 销售法里有一句被反复引用的话：客户带来的那个问题，永远不是真正的问题。按字面把方案做出来，是“礼貌地把事做错”的标准路径——每个里程碑大家都满意，演示很顺，东西上线了，然后没人用，因为那个真正贵的步骤还在那里。[2]

当然，这不等于客户说错了。他有可能判断准确，小额、标准化的采购里这种情况很常见。要改的不是“别信客户”，而是别把他说的方案当成问题本身。

## 把一句话拆成三层

从“表面诉求”到“真要解决的问题”，中间差的往往是一步结构上的追问：这个症状是由哪个环节产生的。

```mermaid
flowchart TD
  A["表面诉求：他说的方案或症状"] --> B["真正要解决的问题：谁在做、哪一步最贵"]
  B --> C["影响与代价：谁受影响、多久一次、不解决会怎样"]
  C --> D{"他亲口说出想解决了吗？"}
  D -- "还没有" --> B
  D -- "说了" --> E["针对这一点讲产品"]
```

拿那个文档机器人作例子。往下问“你希望它帮你解决什么”，可能得到“销售找报价材料要翻半天”。继续问“上一次具体是怎么发生的”，才会露出真东西：真正的贵步骤往往是两个系统对同一个客户编号的口径不一致，每天早上有人手工把两边的名字对上，而文档本身其实搜得到。机器人做出来是对的、能用的，只是它不碰那个贵步骤。[1]

这就是为什么“听说要什么就做什么”会失败。方案对应的是症状，钱花在症状上，结构没动。

## 什么样的问题，方案答不上来

要把方案背后的问题问出来，问法得让“方案”没法作为答案。下面这几组可以直接用。

“你希望它帮你做到什么？如果它已经有了，对你来说会有什么不一样？”这是在把方案还原成目的，而不是评价方案好坏。

“上一次发生这种情况，具体是什么情况？”注意是那一次，不是“你们一般怎么走流程”。通用的流程是文档里的版本，会主动抹掉异常、临时补丁和“这里我一般手动改一下”这种话——而这些恰恰是你要找的。

“多久发生一次？每次花多久？”频率乘时长得出的那个数字，既决定这件事值不值得改，也是你日后交付时唯一的对照基准。

“如果一直不解决，会怎样？”如果客户的诚实回答是“也没什么”，你找到的是烦恼，不是成本。烦恼撑不过预算会。

“之前试过什么办法，为什么没成？”这是被跳过最多、也最伤人的一句。客户已经否定过三种方案，你没问原因就提出第四种，他只会觉得你没在听。知道前几次为什么失败，比知道他现在想要什么更有用。[3]

## 挖到哪一层就该停

不是问得越深越好。尼尔·拉克姆（Neil Rackham）团队从约三万五千通销售电话里分出了两种需求：隐含需求，是客户说出的困难、不满，比如“现在手工合并老出错”；明确需求，是客户说出的想要，比如“我想找个办法把这个环节缩短”。[4]研究发现，在大额销售里，你挖出多少条隐含需求，和最终成交基本无关——它必须先被发展成明确需求；而在小额销售里，隐含需求本身就足够成交。[3]

这个差别直接给出了停止条件，而且要分场景用。

如果是小额、诉求清楚的采购——比如客户就是要一批标准耗材——听到需求直接回应，别把它做成一场问诊仪式。挖需求在错的地方用，会变成拖延和不专业。

如果是金额大、要动流程的单子，就继续挖，但目的是把“我有这个困难”推到“我想解决它”。他亲口说出想解决的那一刻，才是你开口讲产品的触发点，而且讲的内容只能挂在那一句话上。

还有一层现实边界：不是所有买家都愿意陪你把这一层挖下去。受过采购训练的人被明确教过要挡回这类追问，只给规范、价格和进度，不给痛。[3]遇到这种客户，把深度换成密度——先给一个行业观察或同类客户的情况，等他确认或纠正，再问下一个问题。这跟上一篇讲的“边问边给”是同一件事。

## 最后一个动作：用他的原话复述

挖完之后别急着顺着说自己的产品，先把三层合回去，用他的词说一遍：

“我确认一下理解得对不对。你现在是……（表面诉求）。真正卡住你的是……（他说的那个结构问题）。这个问题……（多久一次、谁受影响），如果不处理，会……。是这样吗？”

客户听到自己的问题被完整说成一个句子的那一刻，往往是他第一次真的意识到它有多大。你也同时得到了一次免费校验：他说“对，就是这样”，你已经知道接下来该讲什么；他说“不完全是”，你就又少了一次做错方案的机会。

顺着“先诊断、再开方”走到这里，你已经能拿到客户真正想解决的问题了。接下来的手艺是反过来的——不是怎么问，而是怎么设计一组问题，让客户在回答的过程中自己把问题的分量说出来，而不只是老老实实回答你的提问。

## 来源

1. [The stated request is a symptom — 客户提出的方案是他已选好的解决方案，一句话里隐含的四个决策与工作流里真正昂贵的步骤](https://fdeinterviews.com/courses/fde-foundations/discovery/the-stated-problem-is-not-the-problem)
2. [SandlerBrief: The Problem the Prospect Brings You Is Never the Real Problem — 表面问题只是症状，诊断先于开方](https://go.sandler.com/neuberger/insights/blog/categories/sales-process/sandlerbrief-the-problem-the-prospect-brings-you/)
3. [Huthwaite: Exploring the power of SPIN Selling questions — 隐含需求与明确需求之别、问题提问与暗示提问的作用、采购训练对追问的防御](https://www.huthwaiteinternational.com/blog/spin-selling-questions)
4. [SPIN Selling Fieldbook 第 6 章 — 隐含需求（implied need）与明确需求（explicit need）的原始定义](https://www.oreilly.com/library/view/the-spin-selling/9780070522350/ch06.html)

---

原文：https://pangzhengboyin.com/articles/stated-request-is-not-the-real-problem-a0d867e8

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com