维护范围要在合同里写成一份可核对的工作清单,而不是一句“负责日常维护”。比较常见的两种方案是按固定项目包月和按实际需求计次:前者适合网站上线后需要持续更新内容、监控可用性的团队,后者适合改动少、预算需要按次控制的团队。约定时至少写清维护对象、响应时限、每月次数、超出后的计费方式,以及哪些情况不属于维护。
很多争议来自范围混在一起。建议在合同里把工作分成三类,分别约定:
判断方法很简单:让对方把过去一个月实际做过的事列出来,逐条归入上面三类。归不进去的,就是范围模糊地带,需要单独写明。
包月方案把每月工作内容固定下来,例如每月更新若干篇文章、检查一次表单和备份、处理若干次页面小改。它的优点是费用可预期、响应有优先级;风险是工作量用不完会浪费,用超了容易扯皮。
约定时建议写清四个数字:每月包含的改动次数、单次改动的工时上限、响应时限、超出部分的单价。例如约定“每月包含8次页面内容修改,单次不超过1小时,超出按次计费”,比只写“每月维护”可执行得多。验收信号是每月收到一份维护记录,列出日期、事项、耗时和结果。
按次方案不承诺每月做多少,只在提出需求时报价和执行。它适合页面结构稳定、更新频率低的站点,也适合暂时不确定维护量的阶段。风险是紧急故障时响应可能靠后,且单次价格通常高于包月折算价。
约定时要明确:报修后多久给初步回复、故障类问题是否优先、单次费用包含哪些动作、是否含备份恢复。如果网站承载表单提交或在线咨询,建议把“页面无法访问”和“表单收不到信”列为优先项,并单独约定处理时限。
假设某站点每月平均修改5次页面、偶尔出现一次访问异常,按次结算的单次价格若明显高于包月折算单价,包月更划算;反之若多数月份没有改动,按次不会产生闲置成本。这里的数字只是举例,实际应以自己记录的历史数据为准。
下一步,把自己站点近两三个月的实际改动和故障记录整理成一页清单,带着它去和对方逐条确认。范围写得越具体,后续对账和验收就越省力。