把付款节点绑定到可验证的交付物,而不是绑定到时间表。假设一个改版项目总价10万元,拆成“原型确认—视觉稿确认—前端开发完成—内容迁移完成—上线验收”五个节点,每个节点约定一笔付款。验收通过才触发付款,验收不通过则进入整改,整改期间不进入下一笔付款。这样价格因素里的“工作量、复杂度、返工风险”就变成了可核对的验收项,而不是口头承诺。
付款比例应当跟着交付物的可验证程度走。越靠前、越容易确认的节点,比例可以低一些;越靠后、越接近上线的节点,比例可以高一些。常见错误是先谈“分几期付款”,再回头补验收标准,结果每期都变成“看起来做完了”。
判断结果的方法:每个验收物必须能被第三方独立复核。如果只能由承接方自己说“已完成”,这个节点就不适合直接触发付款。
以下为假设示例,用于说明拆解逻辑,不代表任何真实报价。假设合同总价10万元,分五笔:
常见错误有三种:一是把“开发完成”等同于“上线可用”,导致测试环境里的问题被拖到最后一笔;二是没有约定整改期限,验收不通过时付款无限期悬空;三是把尾款比例压得过低,承接方缺乏动力做上线后的收尾。适用条件是双方能对验收物达成书面一致;如果验收标准模糊,再细的付款比例也解决不了争议。
验收不通过不等于合同终止,而是触发整改流程。建议在合同里写明:验收方在收到交付物后若干工作日内给出书面意见;承接方在约定时间内整改并再次提交;再次验收仍不通过的,双方按缺陷等级决定是继续整改还是调整节点。付款节点应当暂停,而不是自动顺延到下一期。
检查项可以包括:缺陷是否属于约定范围、是否影响核心流程、是否由第三方因素导致。如果缺陷属于范围外的新需求,应走变更流程,单独计价,不占用原付款节点。这样处理,价格因素里的“变更成本”才有明确归属。
第一步,把每个付款节点对应的验收物写成一句话,确保双方理解一致。第二步,给每个验收物列出三到五项可检查的具体内容。第三步,约定验收意见的提交期限和整改期限。第四步,约定尾款与上线后交接文档、账号权限、源码或素材交付的关系。第五步,把变更请求的计价方式写进合同附件。
判断结果的标准是:任意一方拿着合同,都能独立判断某个节点是否已经满足付款条件。如果做不到,说明验收标准还需要继续细化。
下一步,把本文的五个节点替换成你项目实际需要的节点,逐条写出验收物和检查项,再与承接方确认付款比例。验收标准先于付款比例确定,改版价格才不会被模糊的“完成”二字反复拉扯。