两份维护报价可能涵盖不同的服务。在比较价格之前，请先比较所包含的任务、支持时间、事件处理流程和排除项。仅凭“维护”一词无法定义协议内容。
一个词涵盖的四种服务
纠正性维护 — 诊断并修复缺陷。请明确是否包含调查、修复、回归测试和部署，以及如何处理现有缺陷。
适应性维护 — 随着周围环境变化，确保应用继续运行。包括操作系统更新、浏览器变化、第三方 API 版本、库安全补丁和证书续期。这是客户通常没有预料到的部分，也是导致未被改动的应用发生故障的原因。
预防性维护 — 用于防止未来问题的工作。包括依赖项更新、重构、性能调优和改进日志记录。
完善性维护 — 小型改进和新功能。它经常被混入维护服务包中，也是不同报价差异如此之大的主要原因。
仅涵盖纠正性工作的报价，与涵盖全部四种维护的报价是不同的产品。询问四种维护分别包含哪些内容，可以将两个原本无法比较的数字转化为可比较的结果。
为什么未被改动的应用仍然会发生故障
客户合理地会问：没有进行任何改动的软件，为什么仍需要持续投入？诚实的答案是，底层环境会发生变化：
- 移动操作系统可能改变行为或弃用 API。请明确支持的设备和版本，以及更新所需的测试。
- 应用商店可能改变提交和上架要求。请针对具体应用核查当前平台规则和相关截止日期，并确定由谁监控和执行所需工作。
- 第三方 API会升级版本并停止旧版本。一旦支付或地图服务提供商弃用旧版本，就会按照其时间表而不是你的时间表强制进行更新。
- 安全漏洞会持续在库中被发现，其中一些严重到需要及时打补丁。
- 证书会过期，并且过期日期是已知的；证书过期后，网站会停止运行。
这些问题都不是由应用本身造成的，但都需要对应用进行相应工作。
响应时间与解决时间
两者并不相同，而报价中往往只说明前者。
响应时间衡量确认收到问题的时间，或开始调查的时间，具体取决于合同。请明确哪个事件会停止响应计时，以及客户如何接收更新。
解决时间衡量修复完成的时间。同时还应定义恢复时间，即让核心工作流程恢复可用所需的时间，这可能通过回滚或临时变通方案实现。服务可能在根本原因被永久解决之前就已恢复。
一种可行的结构是将两者都与严重程度挂钩：
以下内容是范围界定模板，不是 Manboo 的 SLA，也不是承诺的恢复时间。请将可衡量的确认、更新和恢复目标、支持时间及升级联系人写入实际协议。应区分目标与有保证的解决时间。
| 严重程度 | 含义 | 需约定的响应控制措施 | 恢复规划 |
|---|---|---|---|
| 严重 | 应用不可用或数据面临风险 | 指定的支持覆盖、确认目标和升级路径 | 遏制、回滚或变通方案；记录恢复目标和更新计划 |
| 高 | 核心工作流程中断且没有变通方案 | 约定优先级和进度更新频率 | 评估依赖项和修复工作量；确认针对该事件的具体估算 |
| 中 | 功能受损但有变通方案 | 约定工作时间内的响应窗口 | 在影响评估和发布审查后规划修复 |
| 低 | 外观问题或轻微问题 | 待办事项确认和优先级排序流程 | 通过约定的发布计划安排 |
请说明支持的时区、工作时间、节假日以及任何非工作时间的支持覆盖。对于额外支持，应确认其价格和升级安排，不要假定存在行业统一标准。
常见商业模式
- 包含小时额度的月度服务包。对双方而言都更容易预测。请询问未使用的小时如何处理，以及超出额度后如何计费。
- 按需付费。需求出现时，根据范围明确的估算授权工作。请另行确认可用性和任何响应承诺；这种模式本身并不能保证最低成本或特定的队列位置。
- 年度预算。估算包含的工作量、支持覆盖、事件额度以及计划中的平台和安全工作。应单独列明托管和第三方成本。原始构建成本的某个百分比可以作为比较指标，但不能证明所需工作量，也不存在通用的 15–25% 费率。
让报价具备可比性的问答
- 四种维护类型中，哪些包含在内？
- 按严重程度划分，响应和解决承诺分别是什么？
- 承诺覆盖哪些时间？
- 托管费和第三方费用包含在内，还是单独计费？
- 操作系统和应用商店合规更新包含在内，还是发生时另行报价？
- 包含多少小时的小型变更？用完后如何处理？
- 终止该安排需要提前多久通知？
使用这些答案比较实际服务和总预算。记录排除项和超额费用；仅凭较低的标价，无法证明价值更高或范围更窄。
相关 Manboo 服务
- Flutter 应用开发，适用于 iOS 和 Android MVP。
- 业务软件开发，适用于 CRM、预订、库存和工作流程系统。
- 管理面板开发，适用于运营仪表板和后端管理。
- AI API 集成，适用于产品准备加入智能搜索、聊天或自动化功能的情况。
- 申请范围审查和项目估算，适用于准备规划第一个版本的情况。