上个月一个做餐饮的朋友找我，说他小程序挂了三天，外包公司回复“合同里没写这条，得另外报价”。我让他把合同发过来，翻到服务范围那一页，果然只写了“系统交付及验收”，维护两个字提都没提。这种事我见得太多了，今天就把小程序维护合同这件事说透，省得你后面扯皮。
先搞清楚：维护到底维护什么
很多人签合同的时候脑子里想的是“出问题有人管”，但“问题”这两个字太模糊了。我一般建议客户在合同里把维护拆成三块写清楚：
- 故障修复：程序报错、接口不通、支付掉单、页面白屏这类影响正常使用的问题，响应时限和修复时限要写死。
- 环境维护：服务器、域名、SSL 证书、微信侧接口变更（比如微信支付 v2 升 v3 这种）导致的适配。
- 内容与配置：改个 banner、上下架商品、调个活动价格，这类算不算维护，最容易吵。
第三块是重灾区。有的公司把“改文案”也算一次需求变更，一次收两百；有的则包含在年费里。没有对错，但必须写明白，不然每次改个字都要走一遍报价流程，你会疯。
响应时效，别只写“及时处理”
“及时响应”这四个字在合同里等于没写。我自己的合同模板里是这么分的：
- P0 级（支付不可用、小程序打不开）：30 分钟内响应，4 小时内给出方案或临时恢复；
- P1 级（核心功能异常，如下单失败）：2 小时内响应，24 小时内修复；
- P2 级（非核心功能、样式问题）：1 个工作日内响应，随版本迭代处理。
分级不是为了刁难乙方，而是让双方对“急”有共同语言。真出了 P0，你半夜打电话过去，对方也知道这是合同里写了的，赖不掉。
费用结构：年费、工时、还是按次
常见的三种模式，我列一下各自的坑：
- 包年维护费：一般是项目金额的 10%~20%。好处是省心，坑在于“包”的边界不清，乙方容易把稍微大点的改动都推成“新需求”。签的时候一定要附一份维护范围清单。
- 按工时计费：适合改动频率低的项目。坑在于工时不可控，改一行 CSS 报你两小时你也说不清。建议约定单次工时上限，超过要提前确认。
- 按次报价：最灵活也最没保障，适合小项目。坑是急事来了对方先谈钱再动手。
我一般推荐客户选“基础年费 + 超出部分按工时”，年费覆盖故障响应和小改动，大改动单独报价，双方都好接受。
源码和账号归属，这条比维护还重要
见过太多人合同到期想换服务商，结果发现代码拿不到、服务器是对方账号、小程序后台管理员是对方手机号。维护合同里必须明确：
- 源码交付形式（Git 仓库权限或完整压缩包），交付时间点；
- 服务器、域名、微信开放平台、小程序后台的账号归属，管理员必须是甲方或至少甲方持有可接管权限；
- 合同终止时的数据导出与交接义务，以及交接期限（建议 15 个工作日内）。
这几条不写，你付的维护费本质上是“人质赎金”。
一个容易被忽略的条款：第三方服务变更
微信小程序有个特点，平台规则和接口会变。比如隐私协议要求、订阅消息模板调整、支付接口升级。这类变更不是乙方的 bug，但会实实在在影响你的小程序。合同里最好约定：因平台强制变更导致的适配，年费内包含一次或按约定工时结算，避免到时候互相甩锅。
最后给个实操建议
签之前让对方把维护范围写成一张表，逐条过一遍，能写“包含”就别写“视情况”。金额不大也别嫌麻烦，一份两页的维护附件，能省掉你未来两年的扯皮。真到了要维权的时候，合同里那几行字比任何口头承诺都管用。
顺带说一句，如果对方连维护范围都不愿意写清楚，只肯口头保证“有问题随时找我”，那基本可以判断：他也没想好怎么维护，或者压根没打算长期做。
评论 (0)
还没有评论，快来抢沙发吧~