约定维护范围,核心是把“上线后谁负责什么”写成可验收的条款:哪些属于日常维护、哪些属于故障修复、哪些属于新增需求,以及响应和完成的标准。第一次接触时,不必先谈价格,先把边界列清楚,再谈费用和周期。
维护范围之所以容易扯皮,是因为“维护”常被当成一个笼统的词。实际可以拆成三类:
把这三类写进合同或服务说明,判断标准就清楚了:一件事属于哪一类,决定它是否包含在维护费里。
观察:先记录现状。网站由谁托管、用什么建站方式、后台谁有账号、有没有备份、上次改动是什么时候。这些信息决定维护的起点。
判断:对照上一步的分类,把每项工作归入保障、日常或变更。归属有争议的,提前写明按哪一方认定,或写明“超出约定条目的按变更处理”。
处理:写明响应方式。例如“工作日提交的故障,几小时内确认;确认后多久恢复”。响应时间和恢复时间是两件事,要分开写。
复查:约定周期性的检查项,例如每月检查备份是否可恢复、证书是否临近到期、页面是否能正常打开。复查结果以什么形式反馈,也一并写清。
举例来说(假设场景):某企业约定每月包含 4 次内容更新、2 小时以内的页面调整,超出部分按工时另计;服务器故障由主机商处理,服务方负责跟进和恢复网站。这样的写法比“负责网站日常维护”更容易执行,也更容易判断某次请求是否在范围内。
可以用一个简单方法检验:拿最近三个月实际发生过的事情,逐条对照清单,看有多少能明确归入某一条。如果多数事项找不到对应条目,说明范围还太粗。反过来,如果条款细到连改一个字都要单独审批,执行成本也会偏高。适用条件是:网站规模不大、更新频率稳定时,条目清晰即可;功能复杂、对接系统多的网站,需要把变更流程写得更细。
复查时重点看两件事:一是约定的事项是否真的按标准执行,二是实际发生的工作是否大量落在“除外”或“变更”里。如果后者频繁出现,说明初始范围定得偏窄,应在下一周期重新协商,而不是靠临时沟通解决。
下一步,把上面七项检查项整理成一页清单,和对方逐条确认后再落笔签字;对无法当场确认的条目,写明由谁在什么时间前补充说明。