做不到就退，延期就赔：把承诺写进合同

报价时什么都敢答应，合同里什么都不敢写——这是软件外包最常见的问题。

开发费动辄几万到几十万，交付的却是一段看不见的过程。等系统上线才发现功能不对、晚了两个月、改一点就要加钱，甲方其实没有多少可依据的东西。问题往往不在技术，而在于风险从一开始就没有被分配到纸面上。

写不进合同的承诺，都不算承诺。

一、口头承诺为什么不算数

「放心，肯定好用」「差不多一个月」「后面有小改动不算钱」——这三句话在项目顺利时都不会被追究，一旦有分歧，没有任何一句能拿来核对。原因很简单：它们没有主体、没有标准、没有时间点、也没有后果。

把模糊的说法换成可核对的条款，是签约前最值钱的一步。下面这张表可以直接照着改。

常见口头说法	合同里该写成	为什么
「系统好用、速度快」	功能清单逐项列明，并约定并发量、响应时间、可用率	「好用」没有判定人，指标才有
「一个月上线」	里程碑日期 + 每个节点的交付物 + 延期处理方式	没有节点，就追不了责
「小改动不算钱」	明确需求边界与变更流程，写清哪些属范围内	避免「合同外全是增项」

二、把「效果」翻译成可验收的条款

验收标准最好由三部分组成：功能清单（做什么，逐条可勾选）、性能与稳定性口径（多少人同时用、多久响应、数据怎么对）、验收方式（谁测、测几天、不合格怎么改）。有了这三样，交付那天双方看的是同一张表，而不是各自的感觉。

这也是「不达标不收费」能成立的前提——先把标准写清楚，才谈得上按标准逐条验收、达不到就不收费。

三、三道把关，把风险拦在交付之前

合同写得再细，也要有人在每个节点对照核一遍。我们的做法是把质量控制拆成三段，每一段都有明确的负责人和记录。

需求评审：项目启动时老板亲自参与，把边界和交付标准聊透。前期想清楚，后面少返工，也没有借口乱加钱。进度质检：开发期内定期检查进度与质量，每个节点对照合同标准核一遍，发现问题当场解决，不把问题攒到交付那天。验收签字：上线前逐项核查，签字确认才交付——因为退款条款就写在合同里，我们比甲方更在意这一步。

四、退款与补偿条款，怎么写才有用

「做不到全额退款」「技术失误双倍补偿」这类承诺，如果只写一句话，执行时仍然会扯皮。有效的写法要把四件事补齐：

1. 触发条件：什么情况算「做不到」，什么情况算「延期」，由谁认定、依据哪份验收表。
2. 金额口径：退多少、按什么基数计算双倍补偿，是否包含已投入的第三方费用。
3. 时限：确认触发后几个工作日内完成退款或补偿，逾期怎么处理。
4. 例外边界：因甲方资料延迟、需求变更、第三方平台规则变化造成的延误，如何另行约定。

愿意把这四条写细的服务商，通常也愿意在过程中认真执行。反过来，只肯在宣传页上写「全额退款」、合同里却回避细节的，值得多问两句。

五、升级系统，不必推倒重来

还有一类风险容易被忽略：为了上新能力，得先把旧系统和现有设备全换掉。我们做方案时优先在原有系统上兼容叠加，多平台数据互通、消除信息孤岛——之前花过的钱继续值钱，改造成本和过渡风险一起降下来。这一点也应该写进方案，而不是等开工后才发现要重新采购。

六、签约前的三个动作

七、一句判断

信任是合作的结果，不是合作的前提。把风险先写清楚，双方才敢把精力放在把系统做好上——这也是我们愿意把保障条款一条条写进合同的原因。