SaaS 轻量 SLA：早期支持承诺要清楚，但别承诺做不到的赔付

开场：支持承诺含糊，会让客户和团队都痛苦

早期 SaaS 创始人常对客户说：“有问题随时找我。”

这句话听起来负责，但长期会变成不可控承诺。客户不知道什么问题多久能解决，团队也不知道哪些问题必须立刻处理。

轻量 SLA 的目标，不是做复杂赔付条款，而是把支持边界说清楚。

先区分问题等级

可以从四级开始。

响应目标不是保证修复时间，而是保证开始处理和沟通。

写清支持时间

不要让客户默认你 24 小时在线。

例如：

标准支持时间为工作日 9:00-18:00。影响核心业务使用的紧急问题可通过专属渠道提交，我们会优先响应。

如果没有夜间值班能力，就不要承诺全天候支持。

维护窗口要提前说明

即使早期用户少，也要说明系统维护方式。

包括：

• 计划维护提前多久通知。
• 维护一般安排在哪个时间段。
• 是否可能短暂停机。
• 紧急修复如何沟通。

客户能接受维护，但不喜欢突然中断。

客户也有责任

SaaS 支持不是单方面义务。客户需要：

• 提供问题截图或复现步骤。
• 指定管理员作为联系人。
• 及时反馈修复结果。
• 保持账号和权限管理。
• 按约定提供数据或接口权限。

客户责任写清楚，很多支持问题会更快解决。

不要把需求当故障

客户说“这里不能按我们的方式审批”，不一定是故障，可能是需求。

支持分类要区分：

• 故障。
• 使用咨询。
• 配置问题。
• 数据问题。
• 新需求。
• 合同或账单问题。

分类清楚，团队才不会被所有请求打成紧急。

是否要写赔付

早期通常不建议轻易写带赔付的 SLA，除非你确实有监控、值班、备份和财务承受能力。

可以先写支持承诺：

• 响应时间。
• 沟通频率。
• 问题分级。
• 修复后复盘。

等企业客户和基础设施成熟后，再考虑正式可用性 SLA。

轻量 SLA 的量化指标

把模糊承诺转化为可测量的指标，团队和客户都能对齐预期：

注意：轻量 SLA 的核心是"响应"而非"修复"。早期团队资源有限，承诺"4 小时内开始处理"比"4 小时内修复"更现实，也更不会透支团队。

MTTR 与 MTBF 的实践意义

提升 MTBF 靠预防（自动化测试、监控告警、灰度发布）；提升 MTTR 靠预案（Runbook、故障演练、自动化回滚）。

客户自助服务：降低支持成本

最好的支持是不需要支持。通过自助服务减少工单量：

状态页面尤其重要。当系统确实故障时，主动在状态页公告比等客户来问工单好得多。推荐工具：Atlassian Statuspage（付费）、Cachet（开源）、或自建静态页面。

支持工单系统选型

早期建议用邮件或飞书表单收集，超过 20 个付费客户后迁移到专业工单系统。迁移成本主要是历史工单数据，越早迁移越简单。

升级路径：从轻量 SLA 到正式 SLA

升级触发条件：

• 客户主动要求 SLA（尤其是企业客户）
• 月工单量超过团队处理能力
• 出现一次严重的支持体验差评
• 竞品 SLA 成为销售障碍

竞品 SLA 基准参考

早期 SaaS 不必对标 AWS，但应该知道行业天花板在哪。客户问"你们的 SLA 是什么？“时，能清楚回答比模糊回避更能建立信任。

落地建议

写一页轻量支持承诺，包含支持时间、问题等级、响应目标、维护窗口和客户责任。发给付费客户和试点客户。

本周行动项：

1. 列出你的 P0/P1/P2/P3 分级标准（参考本文表格）。
2. 选择一个工单收集渠道（邮件/飞书/工单系统）。
3. 为每个分级设定 FRT（首次响应时间）目标。
4. 建一个"状态页面"雏形（哪怕只是静态 HTML）。
5. 收集 5 个最常见的支持问题，写成帮助文档。

SaaS 从 0 开始，客户支持要有温度，也要有边界。说清楚承诺，反而更容易建立专业信任。