运城软件开发售后维护一般包含什么？服务等级怎么定
维护不是“系统坏了给修”
很多企业以为维护就是修 bug。实际上软件上线后的维护是四件事，修 bug 只是其中一件。
搞清楚这四件事分别是什么，才能判断一份维护合同值不值。
第一类：故障修复（bug 修复）
系统不能用了、功能报错了、数据算错了——这些属于缺陷，维护方应当免费修复。
判断标准：这个功能在需求文档里约定了，但没按约定工作，就是 bug，免费修。
如果需求文档里没写，那是新需求，不算 bug。
这就是为什么需求文档重要——它是界定“免费”和“收费”的依据。
第二类：日常运维
这部分常被忽略，但出问题最急：
- 服务器状态监控（CPU、内存、磁盘、带宽）
- 数据库备份与恢复演练
- 日志检查，发现异常
- 安全补丁更新
- 账号与权限管理（员工入职离职）
- 定期巡检报告
这些工作不出事的时候看不见，出了事就是大麻烦。数据库没备份、磁盘满了导致系统崩溃这类事故，在真实运维里并不罕见。
一个问题要提前确认：服务器归谁管？
如果服务器是甲方自己的（自己买的云服务器），乙方是否负责运维？很多合同里这块是空白，出问题时两边都说不是自己的责任。
建议明确写：服务器由甲方购买，乙方负责系统层面的运维（部署、监控、备份策略），甲方负责资源续费。或者干脆把服务器托管给乙方，费用另计。
第三类：小需求调整
改个字段名称、加个筛选项、调整报表格式——这些不算新功能，但也要工时。
通常约定一个额度，比如“每月免费 8 人时，超出部分按人天计费”。
不建议承诺“所有小改动都免费”——没有上限的承诺，要么乙方亏本不干了，要么用降低质量来补。
第四类：系统升级与扩展
新功能模块、流程改造、对接新系统、适配新的操作系统版本——这些是二次开发，按项目计费。
一个容易被忽略的点：运行环境会变。微信接口升级、操作系统更新、浏览器版本变化、第三方服务调整接口，都可能导致原有功能失效。这类“被动适配”算不算维护范围，要提前约定。
比较合理的做法是：因外部平台强制变更导致的适配，属于维护范围；因业务变化导致的功能扩展，属于新需求。
响应时间怎么分级
维护合同里最该量化的是响应时间。建议分三级：
一级（系统不可用）：整个系统或核心功能无法使用，影响全员。响应时间 1—2 小时，修复时间 24 小时内（或提供临时方案）。
二级（功能受影响）：某个功能不能用，但业务可以绕行。响应时间 4—8 小时，修复时间 3 个工作日内。
三级（一般问题）：体验问题、非关键缺陷。响应时间 1—2 个工作日，修复排入迭代计划。
注意区分“响应时间”和“修复时间”。响应时间是你多久开始处理，修复时间是你多久解决。复杂问题的修复需要时间，但响应必须快。
还要写明服务时间：是 7×24，还是工作日 9:00—18:00？多数中小企业系统，工作日 + 紧急问题电话响应就够了，7×24 通常要加价。
常见收费模式
按年包干：一年一次性付，包含约定范围的维护。常见价格是合同总额的 10%—20%。比如 10 万的项目，年维护费 1—2 万。
按次/按人天：不签年合同，出问题了按次计费，800—1500 元/人天。适合系统稳定、问题少的场景。
包含在质保期内：项目验收后一年质保（只修 bug），之后另签维护合同。这是最常见的模式。
托管式：乙方负责全部运维，包括服务器。费用包含服务器成本 + 运维人力，适合没有技术人员的甲方。
企业自己该承担什么
有些事不该指望维护方：
内容和数据维护：录入商品、维护客户资料、清理脏数据。这些是业务工作，不是技术工作。
用户培训：新员工怎么使用系统，企业内部要有能带教的人。可以要求维护方提供培训材料和一次集中培训，但不能指望每次来新人都找乙方。
需求梳理：想要新功能，企业内部要先想清楚要什么，再提给开发方。把“我想要个更好的报表”丢给开发方，谁也做不出来。
账号与安全管理：谁有权限、离职员工账号什么时候注销。这是甲方的管理责任。
维护合同里要写清的几件事
- 服务范围（上面四类，哪些包含、哪些不包含）
- 响应时间和修复时间（按级别）
- 服务时间（工作日 / 7×24）
- 服务器运维责任划分
- 小调整的免费额度
- 超出范围怎么计费
- 维护期内的交付物（巡检报告、备份记录）
- 第二年及以后的价格调整机制
第 8 条容易被忘。维护费逐年上涨是行业常态，最好提前约定涨幅上限（比如不超过 10%）。
一个建议：维护期内也要留文档
要求维护方在维护期间同步更新文档——改了什么、为什么改、怎么部署。
这些文档在系统需要换维护方时极其重要。没有文档的老系统，接手的人要花几周才能搞懂，成本很高。