先讲结论
维护合同真正需要谈清楚的只有三件事：哪些项目属于维护范围、响应时间为何、超出范围如何计费。把这三件事写清楚，比合同的厚度更重要。模糊的「终身维护」承诺在双方认知不同时，反而是争议的来源。
先区分缺陷修正与功能开发
这是最常被混为一谈的两件事。系统原本即应达成、但未正确实现的部分属于缺陷修正，本即由开发方负责；上线后因业务调整而新增的需求属于功能开发，应另行评估工期与费用。
两者之间另有一段灰色地带：法规变动与第三方服务改版所导致的调整。建议于合同中明确归类，例如支付服务商 API 改版是否纳入年度维护。
三种常见的维护模式
一、年度维护费
按系统规模核算固定年费，涵盖缺陷修正、环境运维与小幅调整。适合流程已趋稳定、每年仅有少量微调需求的系统。
二、工时包
预先购买一定时数，需要调整时扣减。适合上线初期或业务仍在变动的阶段，弹性较高，亦无须为未使用的服务付费。
三、项目式
不签固定合同，有需求时单独报价。适合系统相对单纯、变动频率低的情况，但须接受排期等待。
签约前应确认的五个问题
- 响应时间如何定义：是完成回复，或是完成修复，两者差异甚大。
- 问题分级标准为何：系统无法使用与界面显示异常不应具有相同的处理优先级。
- 维护是否包含主机、域名、证书等环境费用，或另行核算。
- 源代码与数据的归属，以及日后转由他方承接时的交接方式。
- 维护团队是否为原开发团队——更换团队的成本通常高于预期。
我们的做法
我们自咨询、设计、开发至上线后维护均由同一团队负责，不在交付后将系统转由另一组人员接手。理由相当明确：最了解这套系统为何如此设计的，是当初做出决定的团队。
