先说结论：上线不是终点，维护期要写进合同
很多客户验收那天很开心，过两周发现一个小 bug，再找服务商，对方一句「已经交付了」就接不下去了。
「交付完就没人管」是外包体验里最常见的落空感。但这件事不是在出问题后才谈的，它必须在签约时就写清楚：维护期多长、谁来响应、覆盖什么、不覆盖什么、到期之后怎么办。
下面四件事，建议逐条写进合同或补充协议。
一、维护期从哪天起算
维护期（也叫质保期、缺陷责任期）的起点必须明确：验收通过之日，不是「开发完成之日」。
差别很大：如果按开发完成起算，服务商把项目往你手里一塞就开始倒计时，等你内部走完验收流程，维护期可能已经过了一半。明确写「验收通过之日起算」，时间才真正属于你。
我们的标准承诺是：验收通过之日起 30 天，开发原因产生的缺陷免费修复。
二、响应时效要写具体数字
「及时响应」这四个字在合同里等于没写。什么叫及时？是当天还是下周？
可执行的写法长这样：
- 紧急问题：影响线上使用的（支付失败、页面打不开、数据错误），2 小时内响应，24 小时内给出方案；
- 一般问题：功能咨询、小缺陷，1 个工作日内响应；
- 响应 ≠ 解决：响应是「我收到并开始处理」，解决时间按问题复杂度另定，但要有个上限预期。
把数字写进去，出问题时的「催进度」才有依据，而不是靠关系催。
三、维护期覆盖什么、不覆盖什么
这是最容易产生分歧的地方，必须白纸黑字划边界。
覆盖的：开发原因导致的功能缺陷、验收时未发现的逻辑错误、上线后发现的与需求清单不符的问题。一句话——东西本身没做对，我们来修。
不覆盖的（通常会另行报价或签运维协议）：
- 你主动提出的新需求、新功能；
- 第三方服务变动引起的（比如微信接口调整、支付费率变更）；
- 因你自行改动代码或环境导致的故障；
- 非功能性的体验优化建议（不阻塞验收，但你想改，算新需求）。
边界划清了，双方都不会觉得「对方在推」。
四、维护期到期之后怎么办
30 天（或你们约定的期限）之后，bug 还修不修？这个答案要提前定，别等到期那天才想。
通常两条路：
- 按需付费：单次问题单次报价，灵活但单价高；
- 年度运维协议：固定年费，覆盖一定工时的维护、监控、小改、版本适配。业务稳定运行的客户通常更划算，也省去每次比价的麻烦。
我们自己的做法是：维护期结束后，客户可以平滑转成年度运维协议，也可以按需付费，选择权在客户。这条的底层逻辑和源码归属一致——客户随时能走，才说明我们靠服务质量留人，而不是靠锁死。
签约前核对清单
- 维护期起算日：写「验收通过之日」，不是「开发完成日」；
- 维护期时长：明确天数（我们 30 天）；
- 响应时效：紧急/一般分别写具体小时数与工作日口径；
- 覆盖范围：开发缺陷免费修，写清；不覆盖项也写清；
- 到期后：按需付费或年度运维协议，提前约定过渡方式。
五条都在，上线后的预期就清楚了。剩下的才是比服务态度。
准备签约前，可以先找我们要一份合同模板看看——维护条款敢写具体数字，比「我们服务很好」这种话硬得多。