定价页不是竞争对手价格表的翻译，也不是把成本加上一个比例。它要让目标用户理解：自己为何会付费、付费后能获得什么、使用增加时规则如何变化，以及遇到问题要找谁。
本篇提供一条从用户任务到套餐规则的决策路径，不给出适用于所有产品的价格或转化率。
先定义用户交换的结果
从最近一次真实任务开始：谁在什么场景下使用产品，替代方案是什么，产品替他节省了什么风险、时间或协调成本。若无法把结果说清，先不要用“无限”“专业版”或功能数量填充套餐。
再选择一个用户能预先理解的计费单位，例如成员数、处理量、项目数或固定服务范围。好的单位不一定最容易计量，但用户应能在超额前预估自己会怎样变化。它也不能惩罚产品最希望看到的正常成功行为。
把套餐写成可比较的承诺
每个套餐只回答几个实际问题：适合谁、包含哪些边界、达到限制后发生什么、怎样升级或取消。把差异放在能帮助决策的能力上，而不是隐藏在数十个勾选项里。
| 需要说清 | 读者应能判断 |
|---|---|
| 使用范围 | 当前任务能否在此套餐完成 |
| 计费单位与上限 | 增长后会否触发变化 |
| 支持与可靠性边界 | 出现问题能得到什么帮助 |
| 试用或免费规则 | 哪些数据、功能和期限会变化 |
| 取消与退款规则 | 何时停止扣费、历史数据如何处理 |
不要把“联系我们”用作所有不确定规则的出口。若确有人工报价或例外条件，应写清它适用的对象和下一步所需信息。
在价格页之外验证理解
价格研究不是问用户“你愿意付多少”。更有用的证据是：他们能否复述适合自己的套餐、是否因为某个边界停止、是否愿意在真实任务中留下可验证的承诺。
每次只测试一个假设，例如“团队不理解项目数如何计算”。先改成可预估的说明和示例，观察支持咨询、升级路径和用户回访，再决定是否改计费单位。把结论写成可被推翻的句子，并将定性原因交给《用户反馈：先保留情境，再决定是否改变路线图》的记录方式处理。
价格变更前先设计迁移
价格变化会影响信任，不只是收入。发布前写清受影响对象、何时生效、现有用户是否保留原规则、如何通知、能否导出或取消，以及支持团队如何回答常见问题。不要把公告当作最后一步才补的文案。
计费规则、账单状态和产品权限必须能相互解释；支付事件的处理边界见《订阅与支付：让授权状态由可验证事件驱动》。
定期复查
- 计费单位是否仍与用户实际得到的结果相符？
- 用户能否在购买前预估限制和升级后的变化？
- 哪些支持问题来自模糊规则而非价格本身？
- 试用、取消、欠费和历史数据的处理是否在产品内可见？
- 最近一次改价的证据和未解决反对意见是否被保留？
清晰的定价不会替你证明价值，但会让合适的用户能作出知情选择，也让团队知道下一步该学习什么。
延伸阅读
用模拟数字核对工具口径
在资金可维持月数中，现金 120000、月支出 15000、月收入 3000 得到净月支出 12000 和 10 个月。使用同一货币与同一月份口径，额外记录一次性支出；日期按运行当天和 30 天/月简化计算。净支出不为正只说明当前恒定假设下没有算出耗尽时间，不表示未来资金充足。
在SaaS 单位经济计算中，月客单价 29、月客户流失率 5%、CAC 150 得到生命周期 20 个月、收入 LTV 580、LTV/CAC 约 3.87，收入覆盖获客成本约 5.2 个月。工具没有毛利率输入，未扣除服务成本，不能把这个覆盖时间当成利润回本；采用毛利口径时需另建相应模型。稳态简化及其假设可对照 Stripe：SaaS business model（复核于 2026-09-20）。
上述均为合成练习。零流失率、未知值或不同时间口径无法通过补一个看似合理的数字解决，应先回到来源。工具只接受明确数字与规范千位逗号，月流失率可带百分号；无效数字或重复字段会被拒绝，不会自动改成零。