SaaS 产品质量门槛：早期哪些问题不能靠客户容忍

开场：早期产品可以简陋，但不能不可靠

客户能接受早期 SaaS 功能少、界面朴素、部分流程还需要人工协助。

但客户很难接受基础可靠性问题：登录失败、数据丢失、权限错乱、账单混乱、错误提示看不懂。因为这些问题伤害的不是体验，而是信任。

早期产品质量门槛的意义，是明确哪些不完美可以带着跑，哪些问题必须在交付客户前解决。

先定义不可破坏的底线

对多数 B2B SaaS，底线包括：

这些地方不能用“早期版本”解释。

区分 P0、P1、P2

建立简单缺陷分级。

没有分级，团队容易把按钮样式和数据错误放在同一个列表里讨论。

发布前做 30 分钟手工验收

早期即使没有完整自动化测试，也要有发布前检查。

检查项：

• 新用户能注册或被邀请。
• 核心角色能登录。
• 创建、编辑、删除关键对象正常。
• 权限边界没有明显越界。
• 样例数据和真实数据都能显示。
• 关键错误有提示。
• 旧客户配置不受影响。

这 30 分钟能拦住很多低级事故。

不要让客户替你做基础测试

可以让客户参与试点，但不能把明显未验证的功能直接丢给客户。

客户试点应该验证：

• 场景是否成立。
• 流程是否顺手。
• 结果是否有价值。
• 配置是否满足业务。

不应该让客户发现：

• 页面打不开。
• 数据保存失败。
• A 客户看到 B 客户数据。
• 导出文件为空。

前者是产品学习，后者是质量失职。

质量门槛要写进发布习惯

每次发布前问：

• 这个改动影响哪些客户？
• 是否涉及数据迁移？
• 是否涉及权限？
• 是否涉及账单？
• 是否需要灰度或开关？
• 出问题如何回滚？

不是所有发布都要复杂流程，但所有发布都要有风险意识。

客服问题是质量输入

如果同一个问题反复出现，不要只怪用户不会用。

可能是：

• 文案不清楚。
• 默认值不合理。
• 错误提示不具体。
• 流程顺序反直觉。
• 权限反馈不明确。

质量不仅是没有 Bug，也包括用户能否稳定完成关键任务。

落地建议

写一份一页纸质量门槛，列出 P0/P1/P2 定义和发布前 30 分钟检查清单。

SaaS 从 0 开始，快很重要，但基础可靠性更重要。客户能原谅早期产品不够完整，但很难原谅你不尊重他的业务数据和时间。