1.3 客户为什么愿意付钱：我从一次客户沟通说起

刚开始做 FDE 时，你很容易被客户说出的要求带着走。

客户说想做知识库，你就开始研究知识库；客户说想做 AI 销售，你就开始梳理销售功能；客户说想做经营分析，你就开始找数据。

我也犯过这种错误。后来我才明白，客户说出的通常只是他能想到的办法，不一定是他真正想买的结果。

这一章，我从自己在云枢科技参加的一次客户沟通说起。我会告诉你，我最初听到了什么，后来为什么改变判断，以及我最后把什么任务交给了 AI 全栈工程师。

说明：本章采用 FDE 的第一人称讲述。云枢科技、客户和数字都是虚构的教学案例，但判断过程来自真实企业中经常出现的问题。

我先把功能要求还原成具体事件和经营后果，确认什么变化值得，再讨论 AI。

1. 我先拿到了一张“客户需求表”

进入云枢科技的第二天，销售小林递给我一张客户需求表。

表里只有四行重要内容：

• 客户有一百多家门店；
• 想做 AI 经营分析；
• 希望接入现有数据；
• 最好三个月上线。

小林告诉我，这是一笔很有希望的生意。客户的运营负责人张总很着急，预算看起来也不是问题。他已经请售前顾问准备产品演示了。

我问小林：“客户为什么现在突然想做这件事？”

他想了想，说：“因为他们的数据比较乱，管理效率不高。”

这是一个听起来很合理、实际上没有多少用的回答。

几乎所有公司都能说自己数据乱、效率不高。只知道这一点，我无法判断客户的问题有多严重，也无法判断云枢科技应该承诺什么。

于是我没有先看演示，而是请小林再约张总谈一次。我只想弄清一件事：这家公司到底希望什么发生改变？

2. 客户说要 AI，我却一直问周一早上的会议

第二次沟通开始后，张总还是先说系统。

“我们想把所有门店数据接进来，让 AI 自动发现问题，最好还能给出经营建议。”

如果我顺着这句话继续问，接下来大概会讨论接哪些数据、生成什么报表、需要哪些功能。但我没有这样做。

我问他：“你最近一次因为这些数据感到麻烦，是什么时候？”

张总停了一下，然后讲起了刚刚过去的周一。

每周一上午，明日成长都会召开门店经营会。总部有六位员工提前收集各区域的表格，再把数字放到一起。问题是，各门店对同一个指标的理解并不一样。

有的门店把体验课学员算作新客户，有的门店只统计正式付费的人。会议开始后，区域经理经常先争论“这个数字到底对不对”。两个小时过去了，大家还没有谈到“下周应该帮助哪几家门店”。

我继续问：“如果三个月后还是这样，会有什么后果？”

张总说，经营不好的门店会继续亏损，总部却总是晚两三周才发现。等到区域经理真正介入时，店长已经错过了最容易调整的时间。

到这里，我才第一次听见客户真正想解决的问题。

他不是想买一个会分析数据的 AI。他想更早发现哪些门店需要帮助，让区域经理在问题变严重之前采取行动。

你会发现，这两句话的差别很大：

一开始听到的要求	继续追问后发现的结果
做一个 AI 经营分析系统	更早发现需要帮助的门店
接入所有门店数据	先让关键数字不再互相打架
自动生成经营建议	让每个建议都有依据和负责人
三个月上线	下一次经营会就能开始验证

左边是在说要做什么东西，右边是在说客户希望发生什么变化。

FDE 必须先看见右边，才有资格讨论左边。

3. 我以为张总就是客户，后来发现还差四个人

谈完后，小林很高兴。他觉得需求已经清楚，可以准备方案了。

我却问了他五个问题：

1. 谁每天要使用这份分析？
2. 谁会因为门店改善而受益？
3. 谁能决定购买？
4. 谁要拿出预算？
5. 谁有权让项目停下来？

小林只能回答第一个问题。他知道总部运营人员会使用，其他问题都不确定。

接下来两天，我们才逐渐把人找齐。

区域经理告诉我，他们不怕看分析，怕的是总部又让他们多填一套表。如果每周要花半天解释 AI 为什么判断错了，他们宁愿继续用原来的办法。

COO 关心的是，能不能更早阻止门店连续亏损。他愿意支持试点，但不能一个人批准采购。

CIO 关心的是，系统要读取哪些数据，是否会影响现有系统。他提醒我们，有几家加盟门店的数据并不归总部所有。

财务负责人问得最直接：“你们说能提高效率，最后准备怎样证明？这笔预算应该由运营部门出，还是数字化部门出？”

采购和法务虽然不会使用系统，却需要检查供应商怎样处理门店与员工数据。只要这个问题说不清，他们就有权暂停项目。

这时小林才发现，张总只是最先感到问题、也最积极推动改变的人。他很重要，但他不是整个“客户”。

以后你进入一家陌生公司，也不要只问“客户是谁”。你要继续问：谁使用、谁受益、谁决定、谁付款、谁能叫停。

在小公司里，这五种身份可能集中在老板一个人身上。在大公司里，它们可能分散在五个部门。你不需要背这些名称，只要别漏掉任何一种决定。

4. 我问了一个最容易被忽略的问题：不买会怎样

很多销售喜欢问客户：“为什么选择我们？”

我更喜欢先问：“如果不买我们的方案，你准备怎么办？”

张总给出了四个答案：

• 继续让总部员工收表格；
• 再招聘两名数据分析人员；
• 把一部分分析工作交给外部服务公司；
• 暂时不改，先要求各区域自己管好门店。

这些办法听起来不够先进，却都有明显好处。

继续用表格，不需要等待新系统上线；招聘员工，出现错误时容易找到责任人；交给外部公司，总部可以少操心；暂时不做，则完全不用承担改变流程的风险。

客户真正比较的，不是“云枢科技和另一家 AI 公司谁更先进”，而是“换一种办法带来的好处，是否大到值得我承受新的麻烦”。

这一步对 FDE 很重要。你不能只研究自己的方案，还要看客户现在的笨办法为什么一直没有被淘汰。那个办法很可能保留了某种客户不愿失去的东西，例如灵活性、控制权，或者出错后能马上找到人。

如果新系统只去掉了表格，却拿走了这些保护，客户不会觉得它更好。

5. 我没有替客户计算价值，而是让客户自己定义“值得”

回到公司后，小林准备在方案里写：“每周节省二十小时，显著提高经营效率。”

我让他先不要写。

这二十小时是我们估出来的，不是客户确认的。即使以后收集报表更快，区域经理仍然要判断原因，运营人员仍然要安排帮助门店的行动。我们不能把“少整理一些数据”说成“所有工作都消失了”。

我再次找到张总，问他：“三个月后出现什么变化，你会认为这笔钱花得值得？”

他最后给了我三个答案：

1. 周一开会前，大家能看到同一份门店情况；
2. 每个异常都能找到数据来源，也能找到负责跟进的人；
3. 连续使用四周后，区域经理还愿意按照这份材料安排工作。

这三句话就是本次项目最早的验收标准。

商业书里常说“价值主张”。这个词不用想得很复杂。它就是告诉客户：你会得到什么变化，我们用什么事实证明变化真的发生了。

“智能分析”“提高效率”“降本增效”都不能直接证明一件事做成了。你必须继续追问：谁的哪件事变了？以前需要多久？以后准备怎样做？出现什么结果才算有效？

答案不一定一开始就有，但“不知道”比编出一个漂亮数字更有用。

6. 到这一步，我才开始讨论 AI

我花了几天理解客户，却一直没有讨论模型，也没有设计系统页面。

这不是在绕远路。恰恰因为前面的事情说清楚了，我们现在才能判断 AI 应该做什么。

在这次试点里，我认为 AI 可以做五件事：

• 把不同门店交来的资料整理到一起；
• 找出同一个指标在不同表格里的不同叫法；
• 列出表现异常的门店，并附上原始数据；
• 按照已经确认的规则准备周会材料；
• 发现资料缺失时，提醒对应的人补充。

我同时写下五件不能交给 AI 的事：

• 不能自行宣布哪家门店经营失败；
• 不能把猜测写成已经确认的事实；
• 不能擅自给区域经理下达任务；
• 不能承诺一定为客户节省多少成本；
• 不能因为资料找不到，就显示“没有风险”。

我的判断方法很简单：如果一个动作出错，会影响价格、合同、正式评价、客户承诺或员工利益，就必须由一个明确的人负责。AI 可以准备材料，但不能让人的责任凭空消失。

7. 我交给 AI 全栈工程师的，不是一份功能清单

确定这些边界后，我才整理了一份任务交给 AI 全栈工程师。

我没有告诉它按钮放在哪里，也没有写代码。我先告诉它为什么要做这件事：

帮助总部在经营会前形成一份可信的门店材料，减少整理和争论时间，让每个需要行动的门店都有依据和负责人。

然后我说明第一批只给五个人试用：两名总部运营、两名区域经理和一名财务人员。试用期间不改变原来的门店考核，也不修改财务记录。

第一版必须做到：

• 每个数字都能找到来源、门店和时间；
• 两份资料互相冲突时，清楚标出来；
• 把原始资料、AI 整理的内容和负责人确认的结果分开；
• 负责人修改结论时，能留下原因；
• 周会材料发布前，列出所有还没确认的问题。

第一版不能自动给门店排名，不能把结果写入绩效系统，也不能把未确认的建议发给所有区域经理。

最后，我要求 AI 全栈工程师在开始建设前先回来回答五个问题：

1. 你理解客户想改变什么？
2. 你还缺哪些资料？
3. 谁能看到哪些内容？
4. 资料冲突时，你准备怎样停下来请人确认？
5. 试用失败后，大家怎样回到原来的工作方法？

如果这五个问题没有说清楚，功能做得再快也不能开始试用。

8. 我怎样在不懂代码的情况下验收

系统准备好后，我没有让工程师演示所有功能，而是和业务人员一起拿四种真实情况去试。

我们拿来测试的情况	我希望看到的表现
各门店资料完整，数字口径一致	生成周会材料，并保留数据来源
两张表对同一家门店给出不同数字	停止下结论，指出冲突在哪里
一位区域经理没有提交本周数据	明确显示缺失，不能拿上周数据冒充
运营负责人要求直接发布门店排名	等待有权的人确认，不能自动发布

你不需要会写代码，也能判断这些结果对不对。

业务人员最清楚正常工作是什么样、哪些错误不能接受。工程师负责判断系统是否稳定、安全。两边一起验收，才算真正做完。

9. 如果明天换成你进入一家陌生公司

你不必照抄云枢科技的门店案例。换成制造、零售、专业服务或互联网公司，我仍然建议你按同一个顺序问：

1. 最近一次问题发生在什么时候？
2. 如果继续不改变，会造成什么后果？
3. 谁使用、谁受益、谁决定、谁付款、谁能叫停？
4. 客户现在用什么办法应对，为什么这个办法还能继续存在？
5. 什么变化会让客户亲口承认“这件事值得”？

问完以后，再讨论 AI。

如果前五个问题没有事实答案，就先把“不知道”写下来。FDE 最危险的习惯，不是暂时不懂一个行业，而是在还没看懂时就急着给出方案。

10. 这次对话怎样进入商业系统图

我没有把访谈结束时的理解藏进会议纪要，而是填写成客户决策卡 0.1，交给销售和客户共同纠正。

要回答的问题	明日成长案例的填写结果	仍需确认
什么事件让客户想改变	周一经营会花大量时间争论数字，亏损门店晚两三周才被发现	问题在不同区域是否同样严重
谁使用	总部运营与区域经理	店长是否需要直接看见建议
谁受益	COO、区域负责人和经营较弱的门店	改善结果怎样与门店自身变化区分
谁决定和付款	COO 推动，财务与数字化预算共同决定	最终预算归属尚未确定
谁能叫停	CIO、采购、法务以及数据不属于总部的加盟门店	加盟数据的合法使用范围
当前替代办法	收表格、增加分析人员、外包或暂时不改	每种办法的真实成本
客户希望的变化	开会前形成同一份可信材料，并让异常有负责人	“可信”的指标口径和确认方式
最早验收证据	连续四周仍有区域经理依据材料安排工作	尚不能证明门店利润已经改善

这张卡修改了商业系统图中的两处内容：客户不再被画成一个“运营负责人”，而是一组能够使用、受益、付款和叫停的角色；价值主张也从“AI 经营分析”改成“更早发现需要帮助的门店，并让行动有依据和负责人”。

它仍然没有告诉我云枢科技应该收多少钱，也没有证明客户会最终购买。下一节继续跟着同一笔生意，看客户怎样来到公司、价格怎样决定，以及合同签下以后收入是否真的成立：合同签了，公司就赚到钱了吗。