SaaS 风险登记表：从第一天记录哪些假设可能让项目失败

开场：早期创业不是没有风险，而是风险还没被命名

SaaS 从 0 开始时，团队每天都在做假设：客户有痛点，愿意付费，数据拿得到，功能能做出来，试点能转正，现金够撑到下一阶段。这些假设如果不写下来，就会变成隐形风险。

隐形风险最危险。因为它们不在任务列表里，也不在会议议程里，直到某天突然爆发：客户不给数据、试点没有预算、集成比想象复杂、创始人时间被交付耗光、现金只剩两个月。

风险登记表不是大公司流程，它是小团队保护注意力的工具。它让你知道哪些问题如果不验证，会让项目失败；哪些问题只是普通不确定性；哪些问题必须本周处理。

风险登记表和待办清单不同

待办清单记录“要做什么”，风险登记表记录“什么假设错了会出大事”。

例如：

• 待办：做一个导入模板。

• 风险：客户历史数据格式差异太大，导入无法标准化。

• 待办：约 10 个客户访谈。

• 风险：目标客户说不出高频问题，只是礼貌聊天。

• 待办：上线试点版本。

• 风险：客户没有内部负责人推动，试点无法形成真实使用。

风险比任务更接近项目成败。

从六类风险开始

早期不需要复杂模型，但至少要把风险归类。

风险要写成可验证句子

不要写：

客户风险较大。

要写：

如果目标客户没有现有替代成本，他们可能不会为自动周报付费。

可验证句子包含：假设、影响、验证方式。

更完整的格式：

风险写清楚，才会变成行动。

给风险分级

可以用两个维度：影响程度和发生概率。

例如“客户说不出预算来源”是高影响高概率；“云服务短暂停机”可能是高影响低概率；“客户偶尔填错字段”是低影响高概率。

客户风险优先验证

早期最该先验证的是客户风险，而不是技术风险。

技术通常可以找方案，客户不买才是真正致命。

客户风险包括：

• 问题是否高频。
• 问题是否有人负责。
• 是否有现有替代成本。
• 是否有预算来源。
• 客户是否愿意提供数据。
• 客户是否愿意进入下一步。
• 客户是否愿意为试点付费。

如果这些问题没有答案，先不要花太多时间做复杂功能。

技术风险也不能拖到最后

虽然客户风险优先，但技术风险不能完全忽略。

尤其是：

• 数据集成是否拿得到。
• 多租户隔离是否安全。
• 权限模型是否够用。
• 数据量是否会影响性能。
• 第三方 API 是否稳定。
• 导入错误是否可恢复。

技术风险最好的处理方式，是用小实验验证，不是靠讨论。

例如不要争论“客户数据应该很好导入”，而是拿 3 家真实样本数据跑一次导入检查。

交付风险常被低估

很多 SaaS 早期不是卖不出去，而是每卖一个客户都要深度定制。

交付风险包括：

• 每个客户流程差异大。
• 配置需要创始人亲自判断。
• 上线依赖大量人工整理。
• 客户成功标准不一致。
• 支持问题无法复用。

这些风险如果不控制，收入增长会带来更重的人力负担。

可以记录：

交付能否复用，是 SaaS 和项目制服务的重要分界。

商业风险要和现金表相连

商业风险不是“未来能不能赚钱”这么抽象。

要具体：

• 客户是否接受月付或年付。
• 价格是否覆盖支持成本。
• 试点费是否能抵消前期交付。
• 销售周期是否超过现金跑道。
• 低价套餐是否带来过多客服。
• 大客户定制是否破坏毛利。

风险登记表要和现金跑道一起看。如果一个方向需要 9 个月才可能成交，而你的现金只够 4 个月，就不是好计划。

合规和信任风险要提前记录

早期团队容易觉得合规以后再说。但只要涉及客户数据，就要记录风险：

• 是否处理个人信息。
• 是否存储敏感业务数据。
• 是否有数据删除机制。
• 是否使用第三方服务。
• 是否需要客户授权。
• 是否有合同边界。

不需要一开始做复杂认证，但不能完全没有边界。

每周复查一次风险

风险登记表如果只是写完放着，没有价值。

每周复查：

• 新增了哪些风险。
• 哪些风险已经验证。
• 哪些风险升级。
• 哪些风险可以关闭。
• 下周最重要的 1 到 3 个风险是什么。

早期团队每周只要认真处理几个关键风险，就比盲目推进功能更稳。

一个实用模板

不要追求完美格式。关键是让风险进入团队视野。

常见错误

风险登记表不是为了制造焦虑，而是为了减少突然失败。

落地建议

今天就建一张风险登记表，先写 20 条你最担心但还没验证的假设。然后选出最高优先级的 3 条，把它们变成本周必须完成的访谈、样本测试或试点验证任务。

SaaS 从 0 开始，风险永远存在。成熟的创始人不是没有风险，而是知道哪些风险正在被验证，哪些风险还只是自我安慰。

补充：把风险变成实验，而不是会议讨论

风险登记表最重要的下一步，是把风险转换成实验。比如“客户可能没有预算来源”不能靠团队内部讨论解决，要通过访谈确认谁买单、预算从哪里来、过去为类似问题花过多少钱。“数据格式可能无法标准化”不能靠猜，要拿 3 家客户样本数据跑一次字段检查。

每个高优先级风险都应该对应一个最小实验：访谈、样本测试、原型演示、付费试点、手工交付或销售材料测试。实验要有截止时间和判断标准。没有判断标准的实验，会变成继续收集信息。

例如，风险是“客户不愿意为试点付费”。实验可以是向 5 个高意愿客户提出 3000 元两周试点费，观察是否至少 2 个愿意付款或进入合同流程。如果没有人愿意，就要重新判断痛点强度、价格表达或客户画像。

风险登记表还要避免平均用力。早期每周最多处理 1 到 3 个关键风险。风险太多时，优先处理那些一旦为假就会让方向失败的假设。比如客户是否有预算，比按钮样式是否顺手更早决定项目命运。

当一个风险被验证，也要更新结论。不是简单写“已完成”，而要写清楚学到了什么：客户有预算但归属在运营部门；数据可导入但字段命名差异大；试点费可接受但必须抵扣年费。这样的结论才能进入产品和销售决策。

风险登记表的会议节奏

建议每周固定 30 分钟复查风险。会议不讨论所有任务，只讨论三件事：新增风险、升级风险、关闭风险。

新增风险来自客户访谈、试点、技术实验和销售反馈。比如客户第一次提到数据不能出境，这就是新合规风险；试点中发现客户没有内部负责人，这是交付风险；销售中连续三次卡在价格，这是商业风险。

升级风险是那些影响变大或概率变高的风险。比如原本以为只有一个客户数据格式复杂，后来三家样本都复杂，就要升级。关闭风险则需要证据，不是因为团队暂时不想看。

每次会议结束，只选下周最重要的风险实验。风险管理的目标不是把表格填满，而是让最危险的不确定性尽快变成事实。