一句话：同一套系统，范围差一个数量级价格就差数倍。所以先把范围钉死，再谈价格——顺序反了，报价单就白写。
客户要「订单→拆单→报价→派单」全自动。若直接报「一个智能报价系统」，交付必然翻车——真实校验显示尺寸覆盖仅 29%、客户匹配 0%（33,176 单/ 387 经销商 / 2,799 型号）。所以报价拆成两段：先做数据治理（前置依赖），报价引擎等数据达标再启动。
这就是「报价的核心不是单价，是范围」的最好例证。延伸：模块 13 · 定价引擎的算法边界 讲怎么把能力边界讲清而不夸大。
客户拿着我上一份报价去问第二家，第二家报的价格是我的三分之二。他很得意地回来告诉我这件事，想证明我报高了。
我问他：两家的范围一样吗？
他说不知道，只是「功能都差不多」。
| 报价里含的东西 | 不含的话会怎样 |
|---|---|
| 数据清洗与建库 | 客户自己拉数据拉三个月，拉完发现型号对不上，引擎空转 |
| 与现有系统的对接 | 只在页面里手动导出导入，客户说「这不是我要的自动化」 |
| 试点门店的现场支持 | 没试点直接全量上，出问题算谁的说不清 |
| 培训与文档 | 上线即闲置，客户说「不好用」 |
| 上线后的支持期 | 交付完成当天开始无限期被当成免费客服 |
| 模型 | 适合什么情况 | 优点 | 缺点（真实踩过的） |
|---|---|---|---|
| 人天计价 | 范围不确定、需要客户深度参与、需求会持续长出来 | 灵活，需求变了不用重新谈判，双方都能接受 | 客户会盯着人天数——你花 3 天搞定的活，他觉得 3 天太多；反过来做慢了也不好看，双方都难受 |
| 固定总价 | 范围清晰的交付物、有明确验收标准 | 客户痛快：钱是确定的一个数，决策快、预算好批 | 需求一变就得加钱，没有变更单机制就一定会扯皮——客户觉得「这点小改动还要加钱？」 |
| 按结果 / 分成 | 业务价值能被清晰量化的场景 | 客户零风险，前期阻力最小 | 风险全在我这边：投入的时间和钱是固定的，回报是不确定的。而且结果很难界定——「省下来的」多少算我的？ |
这是最有说服力的一段，因为它说明了诊断直接决定报价，而不是报价技巧。
客户的需求很明确：「订单 → 拆单 → 报价 → 派单」全自动。听起来就是一个智能报价系统，按常规做法直接报「做一个智能报价系统」就行了。
我用 33,176 笔真实订单、387 家经销商、2,799 个型号跑了一遍数据校验，结果是：
| 校验项 | 真实覆盖率 | 对报价的影响 |
|---|---|---|
| 型号匹配 | 96.6% | 基本可用，不构成阻碍 |
| 厚度匹配 | 95.2% | 基本可用，不构成阻碍 |
| 尺寸数据 | 29% | 🔴 致命——样本 400 单里 97% 没有尺寸，没尺寸就算不出价 |
| 客户 / 经销商对应 | 0% | 🔴 致命——不知道这个单是哪个经销商的，不知道给谁报 |
客户提的新需求，不是拒绝的理由，是重新计价并确认排期的理由。区别只在于你是有准备地谈，还是被动地吵。
最贵的不是客户提出新需求，是客户以为他买了但其实没买。以下几项必须在报价单或合同里写明，不写就等于你默认承担。
| 客户以为包含 | 实际不包含 | 建议的写法（写进报价单/合同） |
|---|---|---|
| 「你教到我们所有人都会为止」 | 只含约定的场次和对象，不含无限次改需求式培训 | 培训含 3 场（安装部署 / 日常操作 / 故障处理），每场时长与对象见附表；超出场次或新增角色的培训按 X 元/场另计；培训后一次性复训免费，新员工入职后的常规培训由客户自行组织 |
| 「上线以后有问题你随时管」 | 只含支持期内的缺陷修复，不含长期运维 | 交付后提供 30 天免费支持（响应时效见附表）；此后按年度运维包或人天计费；新增功能、新报表、新对接系统一律走需求变更单 |
| 「这个功能能顺便对接一下我们的小工单吗」 | 对接不在原范围内，涉及对方系统的联调和变更 | 接口对接范围为 A系统 ↔ B系统，共 N 个接口；第三方系统（云服务/短信/支付/ERP）产生的费用由客户承担；对方系统变更导致的适配另计 |
| 「你把数据都整理好」 | 历史脏数据清洗不是引擎开发的一部分 | 数据治理范围为 清洗规则、字段映射、缺失数据标注；源数据本身缺失（如订单无尺寸）需客户补录，我方只做标注与告警，不做推测性填充 |
| 「弄好了我们就能用了」 | 硬件、网络、现场线路、打印机/扫码设备不在软交付范围 | 软交付含应用部署与配置；服务器/网络/终端设备及现场施工由客户自行准备；设备就绪时间以客户通知为准，不计入工期 |
不是所有事都该收钱，也不是所有事都该白干。分清这条线，才能既不显得抠，也不亏自己。
| 环节 | 收/ 不收 | 理由 |
|---|---|---|
| 初步沟通、需求诊断 | 可以免费 | 这是建立信任的入口，也是筛客户的关口。给方向和判断，不给完整方案 |
| 可行性判断、风险提示 | 可以免费 | 比如「尺寸数据只有 29%」这个结论，价值很大但属于判断而非交付，收费会让客户不敢听真话 |
| 完整方案设计 | 要收费 | 方案是核心工作成果，包含架构、数据模型、排期、报价构成。送方案等于送报价的底牌 |
| 原型 / Demo（可交互、非生产） | 收费或送简化版 | 完整原型一旦做好，客户拿去换三家比价，方案能力就白送了。最多送静态页面示意 |
| 开发实施 | 按项目收 | 主体交付 |
| 培训、文档 | 含在项目内，超出另计 | 基础场次含在报价里，理由见模块 08——它是让系统真正用起来的必要环节 |
| 上线后支持期 | 含 30 天，超出收费 | 见模块 08 的运维边界 |
| 知识库、模板、复用资产 | 算我的资产 | 需求诊断表、验收清单、变更单、灰度节奏表这类东西是我沉淀下来的，内容可以给客户看，但不作为交付物免费让出。它是我的能力证明 |
| 坑 | 说明 / 对策 |
|---|---|
| 报价时不敢划范围 | 怕说「这个不做」客户就走了，于是含糊其辞。结果是什么都含，最后全白干。范围划不清，报价就是个数字，没有商业意义 |
| 口头承诺没落到单据 | 会议里说「这个我顺手帮你改一下」，一周后成了扯皮的证据。所有承诺当场写进单据，哪怕是一封确认邮件 |
| 被压价就妥协范围 | 客户砍 20%，你就把范围砍 20%——错。应该做的是缩范围不缩质量：功能少做几项，但做出来的部分必须是能用的。宁可报价高一点接不下来，也别做一摊半成品 |
| 忽略第三方 API 与服务器成本 | 视频生成、语音合成、云存储、短信这些按量计费的项目，成本会随客户使用量线性上升。报固定总价时必须写清超出额度由客户承担，否则客户跑量了你就倒贴 |
| 把前置依赖藏在总价里 | 像德莉玛那样，数据治理是引擎的前提。把它埋进总价，客户会觉得「买个报价系统凭什么这么贵」，也不理解为什么引擎迟迟不上。拆出来单独报，客户才看得懂钱花在哪 |
| 怕报高了丢单，不管风险敞口 | 为了签下来签固定总价，但范围和风险没算清。这种单子做起来必然亏，而且交付质量一定会下降——宁可少接一单，不要接一单注定做不好的 |
我的核心观点是：报价的核心不是单价，是范围。同一套系统，范围差一个数量级价格就差数倍。所以我的顺序是固定的三步——先钉范围，再拆前置依赖，最后才给价。跳过第一步就报数字，等于在不知道自己卖什么的情况下先把价报了。
举个我真实做过的例子。德莉玛要做「订单→拆单→报价→派单」全自动，看起来就是一个智能报价系统。但我用 33,176 笔真实订单、387 家经销商、2,799 个型号跑校验，发现型号覆盖 96.6%、厚度 95.2% 都还行，但尺寸只有 29%（抽样 400 单里 97% 没有尺寸），客户匹配是 0%。
所以我没有报「一个智能报价系统」，而是把单子拆成两段：第一段先做数据治理——建型号↔尺寸数据源、建订单↔经销商 ID 对照表、补出厂价红线表；这段不产出「智能」，但不做它，第二段根本无法启动。第二段报价引擎等数据达标再启动，范围和价格单独谈。
这个判断的价值很直接：避免了客户花钱买一个算不出价的系统。他花的钱落在真正缺的地方，而且第一段还能先在 4 家经销商门店跑，风险降了一个量级。诊断做扎实了，报价才是有依据的，而不是猜的。
至于客户嫌贵——我缩的是范围，不是质量。预算少三成，功能就少做几项，但交出去的部分必须是能用的、能验收的。质量不能降，因为降了就是拿尾款和口碑去填窟窿。缩到极限还做不好的单子，我宁愿不接。
还有一点我坚持很久：变更不是拒绝，是重新计价并确认排期。客户提新需求，我不回答「这个不能做」，我回答「可以，加 X 人天，顺延 Y 天」。所有口头承诺都必须落到《需求变更单》上，写清原约定、变更内容、新增工作量、排期影响和客户签字——因为三个月后双方都会忘，只有单据记得住。