SaaS 试点协议：小团队也要把范围、结果和退出条件写清楚

开场：没有协议的试点，很容易变成无限陪跑

早期 SaaS 为了拿下客户，常说“先试用看看”。

这句话听起来灵活，但风险很大。客户不知道要投入什么，你也不知道什么时候算成功。试点做着做着，范围扩大、需求增加、时间延长，最后既没有成交，也没有清晰结论。

试点协议的目的，不是把关系搞得很正式，而是让双方知道这次试点到底验证什么。

试点协议至少写七件事

这七件事写清楚，试点就不容易漂移。

目标要具体

不要写：

验证产品是否适合客户使用。

可以写：

验证客服一组是否能在两周内用系统完成每周 300 条会话的抽样、标注和周报生成，并让主管确认重复整理时间是否减少。

目标越具体，试点结束时越容易判断。

范围要小

早期试点不要一上来覆盖全公司。

建议限定：

• 一个团队。
• 一个流程。
• 一类数据。
• 一到两个关键角色。
• 两到四周周期。

小范围成功比大范围拖延更有价值。

费用要提前说

免费试点不是不可以，但必须有边界。

几种方式：

如果客户完全不愿承担任何成本，也不愿投入时间，要重新判断需求强度。

成功标准要双方认可

成功标准不能只有你说了算。

可以包括：

• 是否完成关键流程。
• 是否减少人工时间。
• 是否降低错误。
• 是否让负责人更容易管理。
• 是否有下一阶段扩展意愿。

试点前让客户确认这些标准，避免结束时临时换判断口径。

退出条件也要写

试点不成功并不可怕，可怕的是没有退出条件。

可以约定：

• 客户未按期提供数据，试点延期或终止。
• 产品无法支持关键流程，双方复盘后停止。
• 试点结束未达到成功标准，不进入正式采购。
• 双方发现目标客户不匹配，保留后续联系。

体面退出也是一种专业交付。

试点结束必须开复盘会

复盘会问：

• 哪些目标达成了。
• 哪些没有达成。
• 客户是否愿意正式采购。
• 需要补哪些材料。
• 是否适合扩展到更多团队。
• 如果不继续，主要原因是什么。

没有复盘的试点，学习价值会大幅下降。

落地建议

把下一次试点写成一页协议，包含目标、范围、周期、责任、成功标准、费用和退出条件。不要再用“先试试看”开始正式客户关系。

SaaS 从 0 开始，试点不是免费陪跑，而是一次有边界的商业验证。