网站外包：维护范围怎样约定
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e6d23c7f3645.html
📄
网站外包：维护范围怎样约定
维护范围要在合同里写成一份可验收的任务清单，而不是“日常维护”“技术支持”这类概括词。做法是从你希望网站持续达到的结果倒推：哪些内容必须更新、哪些故障必须处理、多久响应、谁出素材、改到什么程度算完成。范围越具体，后期越不容易为“这算不算维护”扯皮。
先定结果，再定维护任务
维护不是一种动作，而是一组结果。你可以先列出网站必须保持的状态，例如页面能正常打开、表单能收到提交、商品和价格与实际情况一致、文章能按期发布、被攻击或误删后能恢复。再把每项状态翻译成具体任务。
- 内容类：每月发布几篇、谁提供文字和图片、谁负责上传和排版、错别字和失效链接由谁清理。
- 功能类：表单、支付、登录、搜索等模块出现异常时，由谁排查、修复到什么程度。
- 安全与备份：备份频率、保留几份、是否做恢复演练、发现异常后如何处理。
- 环境类：服务器、域名、证书、数据库由谁续费和监控，到期前由谁提醒。
这里的关键是区分“保持现状”和“新增需求”。修一个已经存在的表单属于维护，新增一个报名系统通常属于二次开发。如果合同不写清这条界线，双方很容易对同一件事有不同理解。
把责任分给具体一方
维护范围里最容易含糊的是责任主体。建议对每项任务写明：需求由谁提出、素材由谁提供、执行由谁完成、验收由谁确认。例如“每月更新四篇文章”这句话并不完整，还要写明文章由甲方提供还是乙方撰写、配图由谁准备、发布后由谁检查。
可以按下面的方式在合同中列项：
- 任务名称：例如“首页轮播图更换”。
- 触发条件：例如“甲方每月提供一次素材”。
- 执行方与配合方：例如“乙方负责替换，甲方负责提供图片和文案”。
- 完成标准：例如“在桌面端和手机端显示正常，链接可点击”。
- 时间要求：例如“素材确认后两个工作日内完成”。
响应时间和解决时间是两件事。响应指对方多久给出回音，解决指问题多久处理完。故障类任务可以约定响应时限，但不宜对所有问题都承诺固定修复时间，因为有些故障依赖第三方服务商或需要额外采购。
用验收标准判断是否完成
验收标准要能被检查，而不是靠感觉。内容更新可以检查页面是否可访问、文字图片是否正确、链接是否有效；功能修复可以检查操作路径是否能走通、提交后是否收到记录；安全维护可以检查备份文件是否存在、能否按流程恢复。
假设合同约定“每月备份四次”，验收时就不应只看对方说做了，而应确认备份文件的数量、时间和可恢复性。这里说的可恢复性，指的是能否用备份把网站还原到某个时间点，而不只是文件躺在那里。具体检查方式取决于使用的服务器和程序，签约前可以要求对方说明备份存放位置和恢复流程。
如果某项任务无法验证，比如“优化网站性能”，就要把它拆成可观察的指标，例如“首页在常用网络环境下能正常打开”“图片不过大导致加载明显变慢”。指标不必写成技术参数，但必须能通过实际访问来判断。
写清不包含什么和如何变更
维护范围不仅要写包含什么，也要写不包含什么。常见的外包维护不含：全新页面设计、新功能开发、第三方平台账号申诉、内容原创撰写、服务器硬件更换、因甲方误操作导致的数据丢失。把这些写在合同里，不是推卸责任，而是让双方知道超出范围时该怎么走。
变更流程可以简单约定：提出需求、评估是否属于维护范围、给出工作量和费用、确认后再执行。若属于维护范围，按约定时限处理；若属于新增需求，另行确认。这样既不会让维护方无限接活，也不会让甲方觉得所有改动都要额外付费。
最后，把维护范围附在合同后面，作为可更新的清单。每次新增或调整任务，用补充确认的方式记录，避免只靠聊天记录。下一步可以做的，是拿现有合同或报价单，逐条对照上面的任务、责任、时限和验收标准，把“日常维护”四个字拆成能执行、能检查的具体条目。
