维护范围要在合同或SOW里逐项写清“做什么、多久做一次、谁触发、做完给什么证据”,并把不包含的事项单独列出。只写“负责日常维护”等于没约定,出现故障时双方对责任的理解必然不同。下面用一个假设例子说明怎么落地。
假设某公司官网由外部建站团队交付,合同只写了“提供一年维护”。某天上午首页返回502,企业方认为维护方应立即恢复,维护方认为这属于服务器故障,应由企业自己购买的主机服务商处理。双方都没有错,错在合同没写。
正确的做法是在签约前把维护拆成可判断的条目。可以按下面的顺序操作:
可用性维护:程序报错、页面无法访问、证书到期、域名解析异常的处理责任。要写清是7×24还是工作时间,是远程处理还是含现场。
内容与功能变更:每月含多少小时或多少次小改,改文字、换图、加栏目分别算不算。超出部分按什么单价计。
安全与备份:是否含漏洞修补、是否含恶意代码清理、备份频率与保留时长、恢复演练由谁发起。
性能与兼容:是否含打开速度优化、是否含新浏览器或新手机型号的适配。
第三方依赖:主机、CDN、短信、地图、统计工具的费用与故障由谁承担。这一项最容易被漏掉。
交付物:每次维护后给什么,例如工单记录、变更日志、月度报告。没有交付物的维护无法验收。
最常见的错误是只写总价和年限,不写颗粒度。由此产生三类典型争议:
另一个错误是只约定义务不约定前提。例如要求维护方保证网站不宕机,但企业方不提供主机后台权限、不指定对接人、不按时确认需求,维护方实际上无法履约。范围条款应同时写清企业方需要提供的配合。
可以用下面这组问题自查,任何一项答不上来就说明范围还没约定清楚:
判断结果很直接:如果一份维护条款能让你在不咨询对方的情况下回答“这件事该不该他做”,范围就算约定清楚了;如果需要每次打电话确认,说明条款还停留在口号层面。
这套写法适用于外部团队交付后的持续维护,也适用于内部团队之间的责任划分。如果网站还在建设阶段,维护范围应作为交付验收的一部分同步确定,而不是等上线后再补。
下一步:把现有合同或SOW中的维护条款复制出来,按上面六类内容逐条打勾,空缺项整理成一页补充说明,发给对方确认后再执行。