翻过不少小程序商城系统的采购合同纠纷，发现一个规律：闹掰的双方，当初合同里八成都写着「系统功能按需求文档执行」这种话，需求文档有没有、写了什么、谁签字确认，全成了罗生门。合同写得细，合作才长久。
功能范围，一条条写死
最容易被含糊掉的就是这条。功能清单要作为合同附件，逐条写明功能名称和验收标准，写不了标准的就写场景：顾客用微信支付完成一笔含运费减免的订单，即视为支付功能验收通过。凡是销售口头答应的「没问题」，都要落到清单里，落不进去的就是对方心里没底的功能，签之前多问一句为什么。需求文档双方各留一份盖章版，口头补充的当天就用邮件确认留痕，这些动作五分钟，纠纷时值几万。
有人觉得小项目不值得写这么细，恰恰相反，越小的项目越要写清：小服务商的人手波动大，一个骨干离职，接手的人对项目的全部认知就来自合同和文档，写得糊弄，交接就是断档。
这几条没写清，后患都在两年后
- 验收流程：验收期限多长、逾期不提异议算不算验收通过、整改几轮
- 源码与知识产权：定制部分代码归谁、要不要交付、交付格式是什么
- 售后范围：免费维保到哪天、响应时长、修bug和加新功能怎么区分计费
- 数据条款：订单会员数据归客户，合作终止时的导出方式和时限
- 违约与退款：延期交付怎么赔、质量不达标按什么标准退
- 培训与文档：含几场培训、给不给操作手册，人员流动后二次培训怎么收费
付款节奏是兜底的保险绳
付款比例要和进度绑死，常见做法是签约三成、功能开发完成演示通过四成、验收上线三成，留一成作为质保金到维保期满支付。一次性付九成再谈验收的项目，主动权全在对方手里，验收做起来就没了底气。另外付款对象要对公账户和合同主体一致，挂靠、转包的团队签的合同出了问题连找谁都不知道。合同里最好再补一条：源码和文档的交付清单列明目录结构，验收时按清单点收，缺项写进整改记录。
签小程序商城系统的合同不是防人，是把双方的预期钉在同一张纸上。比格网络的标准合同里功能清单、验收标准、源码交付都是默认条款，欢迎客户拿去逐条比对别家的合同，谁写得实谁写得虚，一比就知道。签完的合同电子版扫描存档，纸质版放保险柜，将来任何一方换人，这就是唯一说得清的东西。
