选型时所有供应商的功能清单都差不多，真正拉开差距的是上线之后：系统出问题时多久有人响应、提的需求多久能排上、谁对结果负责。这部分在合同里往往只有一句"提供技术支持"，等于没写。
先给问题分级
"支持"是个含糊词。落地时第一步是把问题分清楚：
| 级别 | 定义 | 典型场景 |
|---|---|---|
| P0 故障 | 系统不可用，业务停摆 | 前台无法办理入住 |
| P1 严重 | 核心功能异常 | OTA 订单不进系统 |
| P2 一般 | 功能异常但有变通办法 | 某报表数据不准 |
| P3 咨询 | 使用问题 | 不知道怎么配置某项 |
分级的意义在于：不同级别配不同响应时效，避免所有问题都"尽快处理"。
响应时效怎么谈
建议在服务约定里写清三件事，而不是笼统的"7×24 支持"：
1. 响应时间（多久有人接手）：P0 建议 15 分钟内，P1 1 小时内，P2/P3 按工作日 2. 解决时间（多久有结果）：故障类要承诺恢复时限，咨询类可宽松 3. 升级路径：多级都解决不了时，找谁、多久内必须升级
> 谈判技巧：把"响应时效"和"服务费/续约"挂钩。只承诺不担责的 SLA，等于没有 SLA。
工单必须闭环
服务质量能不能被管理，取决于有没有工单闭环。一个完整的工单要有：提交人、问题描述与截图、分派对象、处理过程、解决结果、以及客户确认关闭。少了最后一步，"已解决"就只是供应商单方面说了算。
需求排期：区分 bug 与优化
上线后提的需求分两类，必须分开走：
- Bug：功能没按预期工作 → 属于服务范围，应免费修复
- 优化/新需求：功能正常但想要更好 → 属于产品迭代，走排期评估
把两类混为一谈，供应商会把 bug 当需求拖，客户会把需求当 bug 催。分开走之后，双方预期都清楚。
怎么验收服务质量
季度或年度做一次服务复盘，看四个数字：
- 工单总量与各级别占比
- 平均响应时间 vs 承诺时效
- 一次解决率
- 未关闭工单数量
这些数字应该由系统导出，而不是供应商口头汇报。 一个连工单数据都给不出的服务方，谈什么 SLA 都是空的。
上线不是终点而是起点。把运维保障写进流程、写进合同、写进考核，系统才可能在三年里持续产生价值，而不是上线半年就被员工绕开。