SaaS 开发前承诺:还没写完产品,如何拿到客户的明确下一步

开场:口头喜欢不是承诺 客户说“这个有用”“做出来我肯定试试”,听起来很好,但不能直接指导开发。真正有价值的是客户愿意为下一步付出成本:时间、数据、内部资源、预算或公开背书。没有成本的兴趣,往往只是礼貌反馈。

开场:口头喜欢不是承诺

客户说“这个有用”“做出来我肯定试试”,听起来很好,但不能直接指导开发。

真正有价值的是客户愿意为下一步付出成本:时间、数据、内部资源、预算或公开背书。没有成本的兴趣,往往只是礼貌反馈。

开发前承诺,就是在完整产品之前验证客户是否真的愿意推进。

承诺有强弱之分

承诺强度
口头表示感兴趣弱
愿意接受访谈中
提供真实样本数据强
邀请同事一起评估强
签试点意向很强
支付试点费极强

早期不要只统计“感兴趣人数”,要看强承诺数量。

承诺阶梯:从弱到强的渐进验证

把客户的参与意愿看作一条递进阶梯,每一步都需要付出比上一步更高的成本:

第 1 级 ──► 浏览内容 / 填写邮箱        (零成本,无筛选力)
第 2 级 ──► 接受 15 分钟访谈          (时间成本,弱筛选)
第 3 级 ──► 提供匿名样本数据          (信息成本,中等筛选)
第 4 级 ──► 引荐内部决策人参与评估     (社交成本,较强筛选)
第 5 级 ──► 签署试点意向书            (承诺成本,强筛选)
第 6 级 ──► 支付试点费                (真金白银,极强信号)

早期团队常见的错误是直接跳到第 6 级——还没建立信任就要钱。正确做法是从第 2 级开始,每完成一级再邀请下一级。如果客户在某一级停滞超过两次跟进仍无进展,说明需求强度不够,停止投入。

统计承诺时,建议用加权公式而非简单计数:

承诺得分 = (L1×0.1) + (L2×0.5) + (L3×1.0) + (L4×1.5) + (L5×2.0) + (L6×3.0)

一个支付试点费的客户(3.0 分)抵得上 30 个仅填写邮箱的访客(3.0 分)。用这个得分来排序功能开发优先级,比“多少人感兴趣”更可靠。

先设计一个低风险承诺

不是所有客户一开始就愿意付款。可以从低风险动作开始:

  • 20 分钟访谈。
  • 提供匿名样本数据。
  • 参与原型测试。
  • 确认试点成功标准。
  • 引荐内部负责人。

如果客户连这些动作都不愿意做,说明需求可能没那么强。

试点费是重要信号

试点费不一定高,但能区分真实需求。

例如:

两周试点费 3000 元,包含一次流程梳理、基础配置和试点复盘。如果进入年度订阅,试点费可抵扣首年费用。

客户愿意支付试点费,说明他不只是想免费探索。

意向书要写得简单

早期可以用一页意向确认:

  • 客户想解决的问题。
  • 试点范围。
  • 预期时间。
  • 双方投入。
  • 如果达成结果,下一步讨论正式采购。

意向书不是正式采购合同,但能让双方认真对待。

不要用承诺绑架客户

开发前承诺不是套路客户。

你要清楚说明:

  • 当前产品还在验证阶段。
  • 哪些能力已有,哪些还没有。
  • 客户承诺对应什么交付。
  • 如果验证不成立,双方可以停止。

透明会提高信任。

把承诺用于开发优先级

如果 10 个客户都说喜欢,但只有 1 个愿意提供数据;另一个方向只有 4 个客户感兴趣,却有 3 个愿意付试点费。后者通常更值得投入。

开发优先级要看承诺质量,而不是口头数量。

三种低成本的验证实验

在写代码之前,可以用以下三种实验快速测试需求强度,成本远低于开发完整功能:

1. 着陆页测试(Smoke Test)

创建一个描述产品价值的单页网站,包含“预约演示”或“申请早期访问”按钮。通过社交媒体或小额广告投放获取流量,观察转化率。

指标健康基准说明
页面访问 → 填写邮箱≥ 5%表示价值主张有吸引力
填写邮箱 → 接受访谈≥ 20%表示痛点足够痛
访谈后 → 愿意提供数据≥ 30%表示需求真实存在

注意:着陆页的文案要描述当前已有的能力,不要承诺还没开发的功能。虚假承诺会污染验证结果。

2. 人工后端 Wizard of Oz 测试

前端看起来像自动化产品,但后端由团队手动处理。例如:

  • SAAS 声称能“自动生成周报”,实际上第一周是创始人手动整理报告发给客户。
  • 客户如果连续三周都主动催促并给出正面反馈,说明自动化确实值得开发。
  • 如果客户第二周就说“不用发了”,节省了开发成本。

这种测试的关键是尽早暴露人工环节——不要骗客户说是自动化的。Pilot 阶段明确告知:“目前由我们团队手动处理,验证有效后会做成自动化产品。”

3. 并发承诺排序

将多个潜在功能列在一个页面上,请客户排序或打分:

请为以下功能按优先级排序(1 = 最急需):
□ 自动数据同步
□ 实时协作编辑
□ 自定义报表导出
□ 权限分级管理
□ API 开放接口

如果 5 个客户都把“自动数据同步”排第一,这个功能就是首发优先项。如果排名分散,说明还没有找到真正的统一痛点。

支付意愿验证的常见陷阱

不要问客户“你愿意付多少钱?”——这个问题会得到虚高答案。改用以下方法:

错误问法为什么不行正确做法
“这个功能值多少钱?”客户无法为抽象概念定价给出三个定价档位,观察选择分布
“你会买吗?”社交礼貌会扭曲回答要求预付订金或签署意向书
“和竞品比愿意多付多少?”未体验过产品,对比无意义先试用,再谈价格

更可靠的定价验证方式:

  1. 价格锚定测试:展示三档方案(基础版 99/月、专业版 299/月、企业版 799/月),观察客户对哪档最感兴趣。不要只给一个价格。
  2. Van Westendorp 定价模型:询问四个关键价格点——
    • 什么价格太便宜以至于你怀疑质量?
    • 什么价格开始觉得贵但仍然会考虑?
    • 什么价格太贵绝对不会买?
    • 什么价格让你觉得物有所值?
  3. 预付费折扣:“现在预付半年,享受 7 折”——真金白银的预付款是最强的支付意愿信号。

意向书的关键要素

一页意向书虽不是合同,但需要包含以下要素才能引导双方严肃对待:

┌─────────────────────────────────────────────┐
│ 试点意向确认书                                 │
├─────────────────────────────────────────────┤
│ 1. 客户名称与联系人                          │
│ 2. 待验证的核心问题(用客户原话描述)         │
│ 3. 试点范围与边界(做什么、不做什什么)       │
│ 4. 预期时间窗口(起止日期)                   │
│ 5. 双方投入(客户需提供什么、我方交付什什么) │
│ 6. 成功标准(可量化的完成定义)               │
│ 7. 试点费用(如有)及换算规则                 │
│ 8. 下一步:若达成成功标准,双方做什么         │
│ 9. 退出条款:任何一方可在什么条件下终止       │
└─────────────────────────────────────────────┘

第 6 条“成功标准”最关键。不要用"客户满意"这种模糊表述,而要用"导入 1000 条数据后,报表生成时间从 2 小时缩短到 5 分钟"这样的可量化指标。没有明确的成功标准,试点结束后双方对"是否成功"的认定可能截然相反。

常见反模式与自救

反模式症状应对
承诺通胀把"愿意看看"也算成强承诺重新定义标准,只有带成本的才算
幸存者偏差只听愿意承诺的客户的意见同样分析拒绝者的原因,可能更重要
意向书束绑架客户觉得签了就要买,反而犹豫强调"仅是验证,不成功双方都无损失"
创始人自恋用自己的痛苦替代客户的痛点用客户原话写需求,不用自己编的术语
功能蔓延试点过程中不断加需求严格遵守试点范围,新需求延后评估

落地建议

在下一个功能开发前,先找 5 个目标客户获取明确承诺:样本数据、试点时间、内部联系人或试点费。没有承诺,就先不要重开发。

建议本周内完成以下动作:

  1. 列出你正在考虑的 3 个功能方向。
  2. 为每个方向找 3~5 个目标客户。
  3. 设计一个最低成本验证实验(着陆页/Wizard of Oz/排序打分)。
  4. 记录承诺阶梯上每个客户到达的层级。
  5. 按加权承诺得分排序,最高分方向优先开发。

SaaS 从 0 开始,客户愿意为下一步付出成本,才说明你正在解决真实问题。口头喜欢不是承诺,真金白银才是信号。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页