接项目报价怎么定：范围、排除项与付款节点

接项目最难的一步不是写代码，是报价。

报高了怕客户跑，报低了做完一算不如去上班。更麻烦的是：很多时候价格是谈拢了，项目还是亏的。

亏在哪？不在单价，在那些报价时没写清的东西 —— 需求比想的多、改动没完没了、尾款拖着不给、工期被客户那边的资源卡住。

所以我现在的做法是：报价单不写成一页价格表，写成一页风险分配书。价格只是其中一个字段。

下面这四项，是我报价模板里固定存在的字段。之所以固定，是因为每一条都是补在亏过之后的。

报价单里必须有四个字段

一、范围：写到“能验收”的程度

“做一个管理系统”不是范围，是愿望。

能验收的范围长这样：谁、在什么场景下、做什么操作、看到什么结果。 一条一条列，客户能指着说“这个有/没有”。

我习惯把范围写成两张表：

• 做什么：功能清单，按模块列
• 不做什么：见下一节 —— 这张表比第一张更重要

范围写得越具体，报价越有依据。反过来，“先做起来再看”的项目，价格根本没有锚点。

二、排除项：这一节决定你会不会亏

大多数人报价只写“做什么”。亏钱的项目，问题几乎都出在“没写不做什么”。

最常见的漏项甚至不是功能，而是客户侧的等待时间。报价时按“我这边三周做完”算，没写“客户什么时候给到素材、账号和确认”。结果是自己的部分确实三周做完了，客户那边资料拖了四周，整个项目在客户眼里做了两个月 —— 下次谈价的时候，你还得为这四周解释一遍。

我现在固定写进排除项的：

• 不限次数的修改和持续扩张的需求 —— 变更按约定单价另行报价
• 大型系统重建或全公司系统替换 —— 这是另一个项目，不是一个功能
• 未约定的第三方订阅、接口调用费和云资源费 —— 由客户承担
• 全天候值守 —— 没有 7×24 这回事，除非单独签运维协议
• 客户未提供的账号、数据、权限和内部协调 —— 这部分等待时间不计入工期
• 范围外的后续功能开发 —— 除非书面确认
• 对第三方平台的稳定性、接口变更、客户原始数据质量作无条件保证 —— 保证不了的事不保证

最后一条经常被忽略，但它保护的是最要命的一种情况：上游平台改了接口，你的项目“坏了”，客户认为这是你的责任。

三、付款节点：不要只写比例，要写触发条件

比例是次要的，触发条件才是关键。

“预付 40%” —— 什么时候付？合同签字后几日内？ “验收后付 20%” —— 谁验收、按什么标准、几天内必须给结论？

没有触发条件和时限的付款节点，等于没有付款节点。

三条我坚持的原则：

1. 定金不到不启动。 不是不相信客户，是让双方都在同一个承诺水平上。
2. 每个节点对应一个可见的交付物。 客户付钱时应该能看到东西，而不是“付了我们继续做”。
3. 尾款和源码交付绑定。 尾款结清才交完整源码 —— 这条要写在报价单里，不是临时提。

我自己常用的是 40 / 40 / 20：签约后付 40%，中期交付付 40%，验收通过后付 20%。金额大或者周期长的项目，定金提到 50%。

比例可以按项目谈，但“什么时候付”和“付了能看到什么”必须清楚。

四、工期：写清起算点和等待条款

“预计 X 周完成”这句话单独写是没有意义的。

工期必须跟两个条件绑定：

• 从什么时候起算 —— 通常是定金到账 + 客户提供完所需资料之后
• 什么情况不计入 —— 客户侧资源未到位、等待确认、等待第三方接口开通

不写这一条，最典型的亏法是：你三周做完了自己的部分，但客户那边素材拖了一个月，最后客户觉得“你这项目做了两个月”。

变更：写一句话，省掉后面的所有争吵

在上面四个字段之外，报价单里再放一句：

超出本报价范围内的功能变更，按 800–1200 元 / 人天另行报价，双方书面确认后执行。

单价具体填多少按项目和自己的时间成本定，但这句话本身不能省。它的作用不是真的去收这笔钱，而是让“加个功能”从一句话变成一次决策。

配套的做法是：任何口头变更，48 小时内用文字（邮件或聊天记录）回一句确认，写清影响和是否加价。不改文档、只在会上说过的需求，最后都会变成“你当时不是说能做吗”。

客户压价的时候，缩范围，不要降价

这是我最想强调的一条。

客户说“预算只有一半”，直接降价的结果是：范围不变、价格减半，你自己吸收差额。 这是纯粹的自损。

正确反应是把它变成一个交换：

这个预算可以做，但范围要相应调整。我们砍掉 A 和 B，先上 C 和 D，跑通之后再评估要不要补。

这样做有三层好处：

• 价格和范围始终匹配，你不会亏
• 客户拿到的是“能用的第一阶段”，不是“打折的完整版”
• 后续补做 A 和 B 是新的报价，不是免费的返工

如果客户连缩范围都不接受，那说明他要的不是这个价格，而是无限范围低价格 —— 这种单子本身就是亏损合同，早一些识别出来更省钱。

什么时候不用这么麻烦

这套结构是给“有一定复杂度、要交付、要维护”的项目准备的。两种例外：

• 几千块的小单、几天就能做完：写清楚做什么、多少钱、什么时候交，够了。上完整合同反而把小事做重。
• 老客户的持续合作：已经有信任和习惯，可以走简化流程。但范围确认这一步不要省 —— 出问题的往往正是“都这么熟了”。

小结

报价的三个层次，按重要性排序：

1. 排除项 —— 决定你会不会亏
2. 付款节点（含触发条件） —— 决定你能不能拿到钱
3. 价格 —— 决定你赚多少

价格排在最后，不是因为它不重要，而是因为前三项没写清的时候，价格定得再准也保不住利润。