SaaS 定价指南:从第一天起建立正确的定价体系
一套可执行的 SaaS 定价框架,系统讲解常见定价模式、价值指标、套餐设计、价格区间、免费试用、订阅制、一次性付费与价格验证。
SaaS 定价指南:从第一天起建立正确的定价体系
一套可执行的 SaaS 定价框架,系统讲解常见定价模式、价值指标、套餐设计、价格区间、免费试用、订阅制、一次性付费与价格验证。
SaaS 如何从第一天就定对价格
一个花了三个月才开发完成的功能,并不天然比一个周末做出来的自动化工具更值钱。
客户看不到你的 Commit 历史。他们不知道哪个集成让你痛苦不堪,也不知道哪个边界情况消耗了整整一周。他们愿意付费,是因为你的产品能帮助他们增加收入、节省时间、降低风险,或者比其他方案更好地完成一项重要工作。
因此,根据开发难度给 SaaS 定价,是一个非常危险的误区。开发投入会影响你的成本和产品路线图,但它并不能决定客户愿意支付多少钱。
更合理的原则是:
成本决定价格底线,客户价值决定价格上限;产品定位、替代方案和真实证据,帮助你在两者之间找到合适的价格。
这篇指南会提供一套可执行的 SaaS 定价流程。你将学会如何比较常见的 SaaS 定价模式、选择价值指标、设计套餐、估算初始价格、验证客户的付费意愿,以及在订阅、一次性付款和混合计费之间做出选择。
你的第一个价格不会完美,也不需要完美。它只需要逻辑自洽、经济上可持续,并且便于测试和迭代。
SaaS 定价是一个系统,而不是一个数字
创始人经常把定价简化成一个问题:
产品应该卖每月 19 美元、49 美元,还是 99 美元?
但这个问题其实问得太晚了。一套完整的 SaaS 定价系统,包含多个彼此关联的决策:
| 层级 | 需要回答的问题 | 常见结果 |
|---|---|---|
| 客户 | 谁能从产品中获得足够价值,并愿意为此付费? | 理想客户画像和购买决策者 |
| 套餐结构 | 客户具体可以买到什么? | 单一套餐、分层套餐或定制方案 |
| 价值指标 | 价格应该随着什么因素增长? | 席位、用量、项目数、联系人、交易量或固定费用 |
| 价格水平 | 每个方案应该收多少钱? | 套餐价格、超额费用和附加项 |
| 计费方式 | 客户如何付款、何时付款? | 订阅、一次性付款、点数或混合计费 |
| 购买前体验 | 客户如何在正式购买前体验产品价值? | 试用、免费版、演示或付费试点 |
| 持续迭代 | 随着认知增加,定价应该如何演进? | 指标体系、复盘周期和迁移政策 |
改变其中一层,会影响其他层。按席位收费可能会阻碍产品在整个团队中的普及;对 AI 产品提供低价且不限量的套餐,可能会直接破坏毛利;即使订阅模式本身合理,如果入门套餐没有包含帮助用户获得第一个有效结果的核心功能,依然可能失败。
所以,不要从选择一个价格数字开始。先理解你的客户、客户获得的价值,以及哪一个计量单位最能代表这种价值。
常见 SaaS 定价模式一览
“定价模式”这个词经常被使用得过于宽泛。**分层定价、按席位定价和订阅计费,并不是三个互斥的选项。**它们描述的是定价系统中的不同部分。
一个 SaaS 产品可以同时采用:
分层套餐 + 按席位定价 + 月付或年付订阅
另一个产品可以采用:
单一套餐 + 按用量定价 + 预付点数
还有一个产品可以采用:
一次性许可证 + 可选的付费升级
理解常见 SaaS 定价模式最简单的方法,是把它们拆成三个维度。
1. 套餐结构:客户可以买什么
| 套餐模式 | 运作方式 | 更适合 | 主要风险 |
|---|---|---|---|
| 单一套餐 | 绝大多数客户购买同一个付费方案 | 客户类型单一、用途明确的垂直产品 | 难以覆盖不同客户的付费意愿 |
| 分层套餐 | 提供 Starter、Pro、Business 等不同级别 | 大多数存在客户规模或成熟度差异的 B2B SaaS | 如果分层边界缺乏依据,套餐会令人困惑 |
| 按功能分层 | 更高套餐解锁更高级的功能 | 自动化、集成或控制能力能显著创造更多价值的产品 | 如果核心功能被锁在过高套餐,客户容易反感 |
| 定制版或企业版 | 根据范围、服务、安全或合同条款协商价格 | 部署复杂、由采购流程主导的客户 | 销售周期长,折扣容易失控 |
2. 价值指标:什么因素会让价格提高
| 价值指标 | 运作方式 | 更适合 | 主要风险 |
|---|---|---|---|
| 固定价格 | 在正常使用范围内,不论用量多少都收取固定费用 | 客户需求和服务成本相近的简单产品 | 扩张收入弱,轻度用户可能补贴重度用户 |
| 按席位收费 | 价格随用户数或活跃成员数增加 | 协作工具和员工生产力工具 | 可能阻碍团队推广,甚至诱导共享账号 |
| 按用量收费 | 价格随 API 调用、算力、消息数、分钟数等使用量变化 | 基础设施、AI、通信和开发者工具 | 账单难以预测,收入波动较大 |
| 按业务单位收费 | 价格随联系人、项目、网站、客户、文档或工作区数量增加 | 某个业务单位与客户价值高度相关的产品 | 客户可能为了省钱而不导入数据或不创建有用单位 |
| 按交易收费 | 每笔交易或按处理金额收取费用 | 支付、电商、预订和物流产品 | 客户规模扩大后,会更强烈地比较费率 |
| 按结果收费 | 价格与收入、节省金额、线索、招聘结果等成果绑定 | 结果可衡量且可明确归因的产品 | 归因、信任和审计较复杂 |
| 混合定价 | 基础费用包含一定额度,之后再按席位、用量或超额部分收费 | 既需要可预测收入,又需要公平覆盖增长用量的产品 | 更难解释,也更难实现 |
3. 计费方式:客户如何以及何时付款
| 计费方式 | 运作方式 | 更适合 |
|---|---|---|
| 月度订阅 | 每月循环付费获得访问权限 | 新产品或自助式产品,客户更看重灵活性 |
| 年度订阅 | 预付一年费用,或签署年度合同 | 已经融入稳定工作流、客户对长期价值有信心的产品 |
| 一次性付款 | 一次付款获得有限的资产、许可证或使用权益 | 模板、Boilerplate、数据包和独立工具 |
| 预付点数 | 客户先购买额度,再按实际使用消耗 | AI 生成、媒体处理和使用频率不稳定的产品 |
| 订阅加一次性费用 | 循环订阅之外,再收取设置费、实施费、附加包或点数包费用 | 同时包含持续价值和非持续价值的产品 |
| 终身买断 | 一次付款,获得长期访问权限 | 边际成本低、且使用限制定义非常清楚的产品 |
这些模式是可以组合的构件,而不是必须从中“三选一”的标签。你的目标,是把它们组合成一种客户容易理解、与客户价值一致,并且在经济上可持续的方案。
为什么开发投入不是正确的定价锚点
假设有两个产品。
产品 A 是一个报表仪表盘。它花了四个月才开发完成,但客户用电子表格也能生成类似报表。它每个月大约只能帮客户节省一小时。
产品 B 是一个十天做完的小型对账工具。它每个月可以避免财务团队花 20 个小时手工匹配交易记录。
产品 A 更难开发,但产品 B 很可能更值钱。
开发投入是供给侧事实,它反映了你的投资。定价是需求侧决策,它取决于某一类具体客户认为结果值多少钱。
成本依然重要,因为成本决定了你的方案是否可持续。你需要估算服务一个账户时,每月会产生多少可变成本:
- 基础设施和存储
- AI 或第三方 API 用量
- 支付处理费用
- 特定客户产生的数据成本
- 随客户数量或用量增长的支持与实施成本
- 任何会直接随使用量增长的服务成本
然后估算最低可持续价格:
最低可持续价格 =
每个账户的可变成本 /(1 - 目标毛利率)如果服务一个账户每月需要 8 美元,而你的目标毛利率是 80%:
$8 / (1 - 0.80) = $40这只是你的成本底线,不是最终价格。一个客户可能每月从你的软件中获得 1,000 美元的价值,而你的运行成本只有 8 美元。如果仅仅因为代码运行成本低就只收 10 美元,相当于主动放弃了绝大部分可获得价值。
第 1 步:选择目标客户,并量化客户价值
一个同时面向“自由职业者、创业公司、代理机构和大型企业”的定价页,通常会变成一个谁都不真正适合的折中方案。
不同客户群体的问题、紧迫程度、预算、购买流程、支持需求和付费意愿都不一样。首先选择一个主要客群,并完成下面这句话:
对于需要**[完成某项重要工作]的[具体客户],我们的产品通过[实现机制]帮助他们获得[可衡量的结果],而不必继续使用[当前替代方案]**。
例如:
对于管理 10–50 个客户的记账服务公司,我们的产品可以自动提取并分类发票数据,减少每月的数据录入工作,不再需要初级员工把 PDF 中的信息手工复制到会计软件里。
这句话已经提供了不少定价线索。购买者是企业;价值会随文档量和客户数量增长;节省的人力成本可以估算;当前替代方案也存在可见成本。
在选择价格之前,先回答这些问题:
- 谁在使用产品?
- 谁批准购买?
- 什么事件会让这个问题突然变得紧迫?
- 客户现在如何解决这个问题?
- 当前方案需要花费多少钱和时间?
- 如果问题不解决,会造成什么后果?
- 这个问题多久发生一次?
- 购买费用来自哪个预算?
- 购买流程是自助购买、销售辅助,还是需要经过采购?
然后保守估算客户价值:
客户价值 =
新增收入
+ 节省的人力和工具成本
+ 避免的风险与损失
- 切换和采用成本假设这个记账产品每月可以节省 12 小时。执行这项工作的员工,计入工资、福利和管理成本后的综合人力成本是每小时 45 美元:
每月人力价值 = 12 × $45 = $540如果它还能避免大约 100 美元的返工和纠错成本:
保守估算的每月价值 = $540 + $100 = $640客户不一定愿意支付 640 美元,因为他们仍然需要承担实施风险和不确定性。但现在,你已经得到了一个有依据的价值上限。相比直接拍脑袋定成 19 美元,你有更充分的理由测试 79、149 或 249 美元。
第 2 步:选择能随客户成功增长的价值指标
价值指标决定了什么因素会让客户支付更多。它应该反映客户业务的增长,或者客户获得价值的增加,而不是仅仅选择数据库中最容易统计的字段。
可以对每个候选指标按照 1–5 分进行评分:
| 判断标准 | 需要回答的问题 |
|---|---|
| 与价值的相关性 | 这个指标增加时,客户通常是否也会获得更多价值? |
| 可预测性 | 客户能否在使用产品前大致预估账单? |
| 可计量性 | 系统能否可靠地统计,并能解释计费争议? |
| 扩张能力 | 当客户成功并扩大使用时,收入是否会自然增长? |
| 易理解程度 | 买家能否在几秒钟内理解它? |
| 行为一致性 | 它会鼓励健康的产品使用,而不是压制使用吗? |
最后一点经常被忽视。如果协作本身就是产品价值的重要来源,激进的按席位收费可能会阻止客户邀请同事。此时,按工作区收费、按活跃席位收费,或者在基础套餐中包含一定席位数,可能更合理。
不要选择一个会迫使客户为了省钱而减少成功行为的收费指标。
对 AI SaaS,要为结果定价,而不是直接卖 Token
模型 Token 对内部成本核算有意义,但大多数商业客户更关心结果:
- 处理了多少份文档
- 生成了多少张图片
- 创建了多少分钟的视频或音频
- 产出了多少份研究报告
- 解决了多少次客服对话
- 完成了多少次工作流运行
把底层技术消耗转换成买家能够理解的业务单位,再通过套餐额度、超额费用、点数或硬性上限来保护毛利。
例如:
Pro — $149/月
包含 800 份文档处理额度
超出部分:每份 $0.15客户可以提前预估账单,而你的收入和成本也能够随着用量同步增长。
第 3 步:根据客户成熟度设计套餐
价格决定客户支付多少钱,套餐设计决定客户具体购买什么。
一个实用的默认做法,是围绕不同客户场景组织套餐:
| 套餐 | 目标客户 | 应该体现的差异 |
|---|---|---|
| Starter | 正在验证工作流的个人或小型客户 | 较低额度、核心结果、标准支持 |
| Pro | 你的主要理想客户 | 完整工作流、自动化、集成和更高额度 |
| Business | 较大团队,或将产品用于关键业务流程的客户 | 角色权限、治理、协作、报表和优先支持 |
| Enterprise | 有采购、安全或合同要求的客户 | SSO、审计控制、SLA、实施服务和定制条款 |
有效的升级边界通常来自以下几类差异:
- **容量:**更多文档、联系人、客户、存储空间或运行次数
- **协作:**更多席位、工作区、角色或审批流程
- **自动化:**定时任务、批量操作和高级工作流
- **集成:**API、Webhook、高级连接器和导出能力
- **控制:**权限、审计日志、安全和治理能力
- **服务:**实施支持、响应时间、SLA 和客户成功服务
不要从入门套餐中拿走那个能帮助客户获得第一个有效结果的核心功能。合格客户应该能够通过入门套餐体验产品的核心价值。更高套餐应该针对更大的规模、更深的自动化、更多协作、更强控制,以及更低的业务风险收费。
你也不需要默认提供三个套餐。如果你只服务一个非常明确的细分客户、所有客户的使用方式相近,或者你还不知道哪些套餐边界真正重要,那么先提供一个付费套餐即可。只有当证据显示存在不同客户群体或明显不同的付费意愿时,再增加套餐层级。
第 4 步:确定一个有依据的初始价格区间
不要拍脑袋猜价格。至少使用三个锚点。
1. 成本底线
根据可变成本和目标毛利率,计算最低可持续价格。
每个账户的可变成本 = $12/月
目标毛利率 = 80%
成本底线 = $12 / (1 - 0.80) = $60/月此时,一个 29 美元且不限量的套餐,显然值得警惕。
2. 市场参照
梳理直接竞争对手和可信的替代方案:
| 替代方案 | 价格 | 收费指标 | 重要限制 | 目标客群 |
|---|---|---|---|---|
| 直接竞争对手 A | ||||
| 直接竞争对手 B | ||||
| 通用工具 | ||||
| 人工或代理服务 | ||||
| 企业内部工作流 |
不要简单复制市场平均价。竞争对手的价格能告诉你买家熟悉什么、哪些收费指标已经被市场接受,以及你的定位是更便宜的替代品,还是价值更高的升级方案。但竞争对手的价格,并不能证明客户愿意为你的产品支付同样的金额。
3. 价值上限
回到第 1 步中的保守价值估算。以记账产品为例:
成本底线:约 $60/月
常见替代方案:假设为 $99–$249/月
保守估算的客户价值:约 $640/月一个合理的初始假设可能是:
| 套餐 | 目标客户和包含额度 | 示例价格 |
|---|---|---|
| Starter | 小型事务所,最多处理 250 份文档 | $79/月 |
| Pro | 核心理想客户,最多处理 800 份文档 | $149/月 |
| Business | 较大型事务所,最多处理 2,500 份文档 | $299/月 |
| 超额费用 | 额外使用量 | $0.15/份文档 |
这些并不是“正确答案”,而是根据客户价值、成本、替代方案和客群差异推导出来的、逻辑自洽的假设。
不要把“收取客户价值的 10%”或任何类似经验法则当作定律。你应该提出多个候选价格,并用真实买家的行为验证。
第 5 步:用真实证据验证付费意愿
只有经过测试,定价假设才真正有用。
先从行为访谈开始
不要一上来就问:“你愿意每月支付 99 美元吗?”口头上的兴趣几乎没有成本。你应该还原客户最近一次真实解决问题的过程:
- 上一次遇到这个问题是什么时候?
- 当时你是怎么处理的?
- 哪些人参与了?
- 花了多长时间?
- 使用了哪些工具?
- 这些工具花了多少钱?
- 因此延误或损失了什么?
- 你是否已经为其他解决方案付过费?
- 谁会批准购买这个产品?
这些问题能揭示问题的紧迫程度、现有替代方案、预算来源和实际成本。
用定价调研确定候选区间
Van Westendorp 价格敏感度分析会在所有受访者看到同一个、定义清楚的产品方案后,询问四个问题:
- 价格低到什么程度时,你会因为太便宜而怀疑产品质量?
- 什么价格会让你觉得很划算?
- 什么价格会让你觉得有点贵,但仍值得考虑?
- 什么价格会贵到让你完全不再考虑?
它可以帮助你找到买家的心理价格边界,但不能证明真实购买意愿。
Gabor-Granger 测试会向受访者展示一个定义清楚的产品和具体价格,并记录他们是否愿意购买。当你需要比较几个明确的候选价格,并估算价格上升后需求如何变化时,它更有用。
尽可能优先观察真实交易
对于早期 B2B SaaS,一次付费试点往往比大规模通用问卷更有信息价值。明确展示服务范围、预期结果、价格和条款,然后观察买家是否愿意继续、是否要求折扣、是否需要引入其他决策者,或者因为某个具体原因拒绝。
礼貌地说一句“听起来很有用”,不是定价证据。完成付款、购买付费试点、续费、升级、降级,以及明确拒绝,才是。
优化收入质量,而不只是转化率
降低价格通常会提高转化率,但它不一定能创造更好的业务。
| 价格 | 付费转化率 | 每位合格访客带来的初始收入 |
|---|---|---|
| $29 | 8% | $2.32 |
| $49 | 6% | $2.94 |
| $79 | 3% | $2.37 |
对于订阅产品,可以用一个更完整的指标比较不同客户 Cohort:
每位合格线索的预期 12 个月毛利润 =
付费转化率
× 每账户月均收入
× 毛利率
× 预计付费月数同时还要比较激活率、留存率、支持成本、使用成本、退款和扩张收入。价格更低的客户群体可能转化率不错,却更容易流失,并需要不成比例的支持投入。
当流量较少时,可以采用顺序测试:保持套餐和获客渠道不变,向一组相似客户报价同一个价格,记录结果和异议,再向下一组测试另一个价格。每次只改变一个主要变量。
第 6 步:选择计费条款和购买前体验方式
计费方式应该匹配产品创造价值和产生成本的方式。
适合使用订阅的情况
- 客户持续获得价值。
- 产品持续存储或处理数据。
- 托管、API、支持或监控会持续产生成本。
- 产品会成为客户日常运营流程的一部分。
- 客户获得的价值会随时间扩大。
适合使用一次性付款的情况
- 客户获得的是有限的资产、许可证或交付物。
- 持续服务成本较低。
- 客户只需要完成一次,或偶尔完成某个结果。
- 买家更重视所有权,而不是持续服务。
模板、Boilerplate、可下载工具、固定数据包和独立许可证,通常适合这种模式。
适合使用混合计费的情况
当你的方案同时包含持续价值和非持续价值时,可以组合多种收费方式。常见组合包括:
- 设置费或实施费 + 订阅
- 基础订阅 + 用量超额费用
- 订阅 + 一次性点数包
- 一次性许可证 + 付费大版本升级
- 平台费 + 交易费
每增加一种收费项,都会提高解释和实现复杂度。只有当客户能够理解它存在的原因时,才应该加入。
有意识地设计月付和年付
月付降低客户的承诺门槛。年付改善现金流,也给客户更长的产品采用周期。
如果月付价格为 M,年付折扣为 d:
年付价格 = 12 × M × (1 - d)“买十个月送两个月”相当于 16.7% 的折扣,因为客户只支付十个月的费用。折扣应该补偿客户提前做出承诺的风险,但同时应低于年付给你带来的经济收益。
不要用年度合同掩盖糟糕的留存率。
根据价值实现周期选择试用、免费版、演示或付费试点
| 购买前体验方式 | 更适合 |
|---|---|
| 免费试用 | 客户可以在有限时间内体验到有意义的产品价值 |
| Freemium 免费版 | 边际成本低,并且存在自然的用量或协作升级触发点 |
| Reverse Trial 反向试用 | 希望用户先体验高级能力,试用结束后再降级到免费版 |
| 交互式演示 | 不接入敏感数据也能让客户理解产品 |
| 付费试点 | 需要实施、服务、安全审核或可衡量的部署工作 |
| 不提供免费方案 | Onboarding 成本高,或产品已有充分证据并采用销售驱动模式 |
试用时长应该根据价值实现周期确定,而不是沿用行业习惯。用户需要有足够时间完成设置、获得第一个有效结果、重复使用工作流,并验证产品是否可靠。
对终身买断尤其要谨慎。一次性、有限的收入,无法安全地承担无限期的 AI、存储、合规和支持成本。在出售 Lifetime Deal 前,必须明确用量限制、支持范围、更新政策,以及“终身”究竟指什么。
第 7 步:让定价页和计费系统真正匹配定价策略
一个好的定价页,应该直接回答买家的实际问题,而不是迫使买家自己打开电子表格计算。
对于每个套餐,都应该明确展示:
- 适合什么客户
- 能带来的核心结果
- 价值指标和包含额度
- 最重要的功能能力
- 月付或年付条款
- 达到使用上限后会发生什么
- 试用条件以及是否需要绑定银行卡
- 取消和退款条款
- 下一步操作:付款、开始试用、查看演示或联系销售
使用以结果为导向的文案:
Pro — 适合管理不超过 20 个活跃客户的代理机构。
每月 99 美元,按月计费。包含客户工作区、自动化报表、定时发送和 5 个团队成员席位。
计费信息也必须诚实透明。如果你展示的是年付套餐折算后的月均价格,就应该明确写明实际按年收费。不要把设置费、最低承诺或用量费用藏在 Tooltip 里。
不要让支付基础设施反过来决定你的定价
一个可用于生产环境的计费架构,至少应该支持:
- 独立的产品、套餐和支付服务商 Price ID
- 根据需要同时支持订阅产品和一次性付款产品
- 将订单或交易记录与访问权益分开建模
- 经过验证且具备幂等性的 Webhook
- 试用中、已激活、逾期、已取消和已过期等状态
- 沙盒环境和生产环境配置
- 价格版本管理和老客户保留原价
- 明确定义升级、降级、取消和退款行为
创始人不应该仅仅因为一次性付款难以接入,就被迫维持只支持订阅的商业模式;也不应该因为计费逻辑与某一家支付服务商深度耦合,就放弃更合适的支付渠道。
LaunchSaaS 提供了一套可用于生产环境的核心系统,订阅和一次性付款已经与计费及访问权限打通。它的支付层通过统一接口,将 Stripe、Creem、Polar、Dodo Payments 和 Lemon Squeezy 分别封装为独立 Provider Package。订单与权益分开建模,并且可以在需要时扩展新的支付服务商。
因此,你可以根据客户价值和单位经济模型,选择订阅、一次性购买或混合方案,而不是被“哪个 Checkout 最容易先写出来”限制商业模式。
当定价假设准备好后,可以查看 LaunchSaaS 支付文档,或者直接使用 LaunchSaaS Core 模板 实现计费。
第 8 步:把定价视为一个可版本化的假设
随着你对产品、市场和客户的了解不断增加,定价也应该越来越准确。你需要定期复盘,但不要仅仅为了“做点事情”而频繁修改价格。
按套餐和客户群体跟踪这些结果:
- 访客到 Checkout、Checkout 到付费的转化率
- 试用激活率和试用转付费率
- 每账户平均收入和套餐分布
- 毛利率和使用成本分布
- 客户流失率、收入流失率和留存率
- 扩张收入和降级收入
- 折扣率、退款率和拒付率
- 支持成本和销售周期
- 与价格和套餐有关的异议原因
价格可能过低的信号包括:合格买家几乎立即接受报价、客户持续反馈投资回报极高、重度用户毛利很差,或者销售团队不断私下创建更高价格的定制方案。
套餐设计可能存在问题的信号包括:买家不知道哪个套餐适合自己、入门套餐无法带来核心结果、某个必需功能被锁在高出太多的套餐里,或者价值指标与客户获得的价值明显无关。
调整定价时,可以遵循以下流程:
- 使用客户、用量、销售和毛利数据诊断问题。
- 重新确认目标客群和价值指标。
- 提出新的套餐和价格假设。
- 先在新潜在客户或新客户 Cohort 中测试。
- 先对新客户上线新的价格目录。
- 决定老客户是保留原价、迁移到新价格,还是获得过渡期。
- 清楚沟通调整原因、生效时间和可选方案。
- 保留历史价格和订单数据。
绝不要直接覆盖旧价格,以至于历史交易失去明确含义。应该创建一个新的价格版本。
7 天 SaaS 定价冲刺
你不需要先做一个持续六个月的咨询项目,才能得到一套有用的初始定价模型。
| 天数 | 工作内容 | 交付物 |
|---|---|---|
| 第 1 天 | 定义一个 ICP、购买者、核心任务和购买触发点 | 定位陈述 |
| 第 2 天 | 访谈目标买家,并梳理替代方案 | 痛点、成本、预算和异议记录 |
| 第 3 天 | 估算客户价值和可变成本 | 价值上限和成本底线 |
| 第 4 天 | 为候选价值指标评分 | 选定指标及其理由 |
| 第 5 天 | 设计 1–3 个套餐 | 套餐表格 |
| 第 6 天 | 通过真实报价或付费试点测试候选价格 | 证据和异议日志 |
| 第 7 天 | 发布定价、配置计费并埋点关键指标 | 正式上线的定价假设 |
一周结束时,检查以下问题:目标客户是否足够明确?客户价值是否具体?价值指标是否容易理解?价格是否高于成本底线?计费系统能否准确支持这个方案?
如果答案都是肯定的,就上线并开始学习。
可直接复制使用的 SaaS 定价工作表
1. 客户
主要细分客群:
使用者:
购买者:
购买触发点:
2. 问题与价值
当前工作流:
当前工具或人力成本:
新增收入或节省成本:
避免的风险:
保守估算的每月价值:
3. 单位经济模型
每个账户的可变成本:
目标毛利率:
最低可持续价格:
4. 定价架构
套餐结构:单一 / 分层 / 定制
候选价值指标:
选定指标及理由:
计费方式:订阅 / 一次性付款 / 点数 / 混合计费
5. 套餐与价格
Starter 的目标客户、额度和价格:
Pro 的目标客户、额度和价格:
Business 的目标客户、额度和价格:
年付条款、超额费用或附加项:
6. 验证
已完成访谈数:
已发出的付费报价数:
购买与拒绝情况:
价格异议:
套餐异议:
7. 复盘
需要跟踪的指标:
下次复盘日期:
老客户政策:常见 SaaS 定价错误
| 错误 | 为什么会失败 |
|---|---|
| 根据实现难度定价 | 客户为结果付费,而不是为你的开发痛苦付费 |
| 直接照抄竞争对手 | 对方的客群、成本、定位或战略可能完全不同 |
| 为了“先获得用户”而把价格定得极低 | 容易吸引错误客群,并形成难以摆脱的低价锚点 |
| 对高成本用量提供不限量方案 | 用得最多的客户可能反而最不赚钱 |
| 创建太多套餐 | 每增加一个套餐,都会增加购买困惑和运营复杂度 |
| 做 Freemium,却没有升级触发点 | 免费用户没有理由转为付费用户 |
| 对持续产生成本的服务出售终身访问 | 一次付款无法长期承担算力和支持成本 |
| 只优化转化率 | 客户质量、留存、毛利和扩张收入同样重要 |
| 将商业模式耦合到单一支付服务商 | 当基础设施决定产品方案时,定价就很难继续演进 |
SaaS 定价常见问题
一个新的 SaaS 应该收多少钱?
不存在适用于所有产品的统一数字。先计算成本底线,保守估算价值上限,梳理替代方案,再针对一个明确客群测试多个价格。一个有依据的 149 美元价格,比拍脑袋得到的 19 美元价格更好。
是否应该先低价进入市场,以后再涨价?
不一定。起步价过低,可能吸引意愿较弱的客户,并建立一个不可持续的价格锚点。如果不确定性很高,可以使用范围明确的付费试点或创始客户优惠,而不是让客户误以为临时价格会永久保留。
SaaS 应该提供一个套餐还是三个套餐?
当你服务一个明确细分市场,并且客户使用方式相近时,可以只提供一个套餐。当你能够识别出不同客户场景、不同价值水平或不同运营需求时,再提供多个套餐。三个套餐只是常见惯例,不是硬性要求。
什么时候一次性付款比订阅更合适?
如果产品交付的是有限资产或一次性结果,并且持续成本较低,适合一次性付款;如果价值和运营成本都会持续存在,适合订阅;如果方案同时包含循环和非循环部分,则适合混合计费。
应该多久调整一次定价?
当目标客群、客户价值、产品能力、成本结构或销售方式发生变化时,就应该复盘定价。复盘结果可能是涨价、重新设计套餐、更换价值指标、新增套餐,也可能是什么都不改。
最终原则:先为结果定价,再搭建计费系统
一套合理的 Day-One 定价流程并不复杂:
- 选择一个明确的目标客户。
- 理解客户要完成的重要工作,以及当前替代方案。
- 保守量化产品带来的结果。
- 选择套餐结构、价值指标和计费方式。
- 在成本底线和价值上限之间设定价格。
- 通过真实报价和支付行为进行验证。
- 用可以持续演进的方式实现计费。
- 根据证据定期复盘,并为定价创建新版本。
不要问:“这个功能开发起来有多难?”
应该问:
对于这类客户来说,这个结果值多少钱?什么样的定价模式能够在双方共同增长时,依然保持公平、易懂和可持续?
这个问题,会把你带向一个好得多的价格。