一句话：客户嘴上说的往往是「解法」，不是「问题」。诊断做错，后面全是白干。
客户表面需求是「自动报价」。用 33,176 笔真实订单 / 387 个经销商 / 2,799 个型号跑校验后发现：型号匹配 96.6%、厚度 95.2% 可用，但尺寸覆盖仅 29%、客户匹配 0%。真正卡点不是缺算法，而是三个前置数据缺失（出厂价红线 / 尺寸数据源 / 订单↔经销商ID 对照表）。
结论：先做数据治理，报价引擎等数据达标再启动——否则客户花钱买到一个算不出价的系统。延伸：模块 11 · 数据迁移实战 讲这批数据怎么落地成真库。
零售/建材老板最常说的一句话是：「我想要个系统，能自动算报价」。这句话里藏着三个坑：
| 坑 | 他真正表达的意思 | 如果你照字面做会怎样 |
|---|---|---|
| 把解法当需求 | 他要的是「少出错、少加班」的结果 | 你做了个报价计算器，他说「不好用」——因为真正痛点是录入慢 |
| 没说成功标准 | 他自己也不知道算不算「做成了」 | 交付时双方各说各话，尾款收不到 |
| 没提使用场景 | 他设想的是办公室用，门店的人根本没权限 | 上线即闲置，三个月后系统废了 |
按顺序问，不要跳。每问都有它的目的：
「现在这件事，是谁、用什么、怎么完成的？」——问出真实流程，而不是他描述的理想流程。经常一问就发现：他其实有 Excel 版本，而且已经在用了。
让他排出顺序。真正的切入点通常是「最容易错」而不是「最耗时」——错一次的代价远大于省一小时。
用的人是谁决定技术方案。门店销售用手机扫码 vs 老板自己在电脑上看报表，是两套系统。
一定要逼出一个可量化的数字。「报价错误率从 5% 降到 1% 以下」比「报价更快了」强十倍。
三个都是硬约束。尤其决策人——使用者满意没用，要拍板的人满意才算。
拿你真实做过的项目当例子，这段是知识库里最有说服力的部分。
表面需求是「自动报价」。但用33,176 笔真实订单跑一遍校验，诊断结论是：
| 校验项 | 真实覆盖率 | 对报价的影响 |
|---|---|---|
| 型号匹配 | 96.6% | 基本可用 |
| 厚度匹配 | 95.2% | 基本可用 |
| 尺寸数据 | 29% | 🔴 致命——没尺寸就算不出价 |
| 客户 / 经销商对应 | 0% | 🔴 致命——不知道给谁报 |
每次接单先填这张表，填不满就别报价。可直接复制到备忘录或文档。
| 坑 | 说明 / 对策 |
|---|---|
| 客户说不清就替他定 | 需求不明确时不要猜，约定「先做诊断，两周内出结论」——这是可以收费的环节 |
| 把培训当成咨询 | 客户说「想请你教教我们怎么用」，真实需求往往是「我不会用所以做不下去」——要么补培训，要么把产品做得不需要培训 |
| 漏问决策人 | 使用者全票通过，决策人一票否决。项目黄了才知情 |
| 诊断变免费咨询 | 诊断给方向和判断，不给完整方案。「往这个方向做，具体方案另议」 |
先说一句立场：客户说的往往是解法不是问题。我会用五问挖出真实痛点，并且一定要逼出可量化的成功标准和明确的不做什么。
举个我真实做过的例子：德莉玛要「自动报价」，我用三万多笔真实订单跑校验，发现型号覆盖 96.6%、厚度 95.2% 都还行，但尺寸只有 29%、客户匹配是 0%。真正的卡点不是缺算法，是三个前置数据缺失。
所以我把方案改了——先做数据治理，报价引擎等数据齐了再上。这避免了客户花大钱买到一个算不出价的系统。诊断的价值就是让钱花在真正缺的地方。