上线后的技术支持怎么约定

上线后技术支持要在合同约定。 这篇讲清怎么约定。

上线后支持要约定

很多客户在签约时只关注开发和上线，忽略了上线之后怎么支持。结果软件一上线，服务商收完尾款就"失联"了，出了 bug 找不到人、要改个小功能没人理、服务器出问题没人懂怎么处理——这种情况在行业内并不少见。

上线后一定要在合同里约定清楚这几件事：

• 质保期：上线后免费修 bug 多久。
• 响应时间：出问题后多久有人响应。
• 运维方式：质保期结束之后怎么持续支持。
• 支持范围：哪些事归技术支持管，哪些不属于。

不约定上线后没人管，这是客户最容易踩的坑之一。

约定的内容

1. 质保期

质保期是服务商在上线后免费修复 bug 的承诺期，相当于售后的"三包"。

• 免费修 bug 期限：质保期内出现的 bug 服务商免费修复，不再另收费。
• 常见 30 到 90 天：视项目规模和复杂度而定。
• 范围：明确写清是"bug 免费修"，而不是"任何修改都免费"——新功能、需求变更、第三方服务升级导致的不兼容，通常不属于免费范围。

2. 响应时间

响应时间是"出问题后多久有人响应"的承诺，建议按问题严重度分级。

• 紧急（影响使用）：比如系统无法登录、核心功能不可用、数据丢失，这种问题要几小时内响应甚至立即响应。
• 一般：功能有问题但有绕过方式、体验问题，1 到 2 天内响应。
• 轻微：界面小瑕疵、文案错误，按排期处理。
• 按严重度分级：不分级的话，要么响应慢得让客户崩溃，要么服务商被琐碎问题拖垮。

3. 运维方式（质保期外）

质保期结束之后，软件还在用，但免费修 bug 的承诺到期了。这时候有几种持续支持的方式：

• 按次工单：出一次问题报一次工单，按次计费。适合问题不多、偶尔需要支持的场景。
• 月度套餐：按月支付固定费用，包含一定数量的工单和运维服务，性价比比按次高。
• 长期运维合同：签一年或多年的运维合同，包含日常监控、定期巡检、bug 修复、小功能调整等，适合核心业务系统。

4. 支持范围

支持范围要写清楚，避免双方扯皮。

• bug 修复：系统出现的功能错误、崩溃、数据异常，属于支持范围。
• 小功能调整：文案修改、按钮位置、小界面调整，可以约定每月一定的免费次数。
• 运维：服务器监控、备份、更新、安全补丁，属于运维范畴。
• 不属于的：新功能开发、需求大改、第三方接口变更导致的适配，通常按新项目或工单另算。

质保期

质保期 bug 免费修。 质保期长度和项目复杂度相关——简单的官网或工具类应用，30 天足够把上线后的常见问题暴露出来；复杂的业务系统可能需要 90 天甚至更长，因为很多问题要在真实业务场景下才会显现。

质保期外的方式

建议签运维套餐有持续保障。 不要等出问题了再临时找人——临时找的服务商不熟悉系统、报价高、响应慢，远不如提前签一个运维套餐划算。

响应时间约定

响应时间分级的好处是双方都有预期——客户知道严重问题会快速响应，服务商也知道不是每个问题都要立刻放下手头的活去处理。

别踩的坑

• 无质保期：合同里没写质保期，上线即脱保，bug 只能再花钱修。
• 响应时间不清：只写"及时响应"，没写具体几小时，出问题时各说各话。
• 质保期外无约定：质保期结束后服务商没义务继续支持，客户只能临时找人。
• 范围不清：哪些是免费 bug 修复、哪些是付费需求变更没写清，事后扯皮不断。

成本参考

质保期通常含在项目报价里，不另收费。质保期外的支持方式按需选择——问题少就用按次工单，核心系统建议签月度套餐或长期合同。

怎么约定

1. 合同写质保期（长度/范围）：明确质保期多少天、免费修 bug 的范围。
2. 写响应时间（按严重度）：紧急、一般、轻微分别多久响应。
3. 质保期外运维方式：约定质保期结束后用什么方式持续支持。
4. 支持范围明确：写清哪些属于支持、哪些不属于，避免扯皮。
5. 建议签运维套餐：质保期结束后转入运维套餐，确保有持续的技术保障。

广州市汉诺雷斯（HNREIS）项目含质保期+响应约定，提供运维套餐持续支持。把你的项目需求告诉我们，我们规范售后。