先写一页定价假设

定价不应等到产品做完以后再填一个数字。价格会反过来影响产品服务谁、需要交付什么、可以承担多少支持，以及团队用什么方式找到客户。

一款每月几美元的自助工具，与一项需要演示、实施和持续服务的高价方案，需要不同的产品范围、销售流程和成本结构。即使两者使用相似技术，也可能是两门不同生意。

早期定价的目标不是一次找到永久正确的价格。团队需要先写出一套可以被验证的假设：客户为何付费，当前怎样解决，价值随什么变化，采用什么计费单位，套餐之间怎样区分。随后再用访谈、页面、报价和真实交易修正。

在完整开发前，可以先回答这些问题：

• 付款者是谁，使用者是谁；
• 他在什么场景下遇到什么问题；
• 问题有多紧迫，多久发生一次；
• 当前替代方案是什么；
• 替代方案花费多少金钱、时间和风险；
• 产品交付什么可观察结果；
• 价值随人数、用量、交易或结果怎样变化；
• 每个客户会带来哪些持续成本；
• 客户怎样发现、评估和购买；
• 采用什么计费单位最容易理解；
• 哪些客户应进入不同套餐；
• 需要什么证据来改变当前假设。

这张纸会暴露产品中的空白。团队如果说不清谁付费、为什么现在要付、价值如何增长，继续讨论 19 美元还是 29 美元通常没有意义。^[1]

定价连接产品、人群和渠道

产品、人群和渠道需要同时定义。同一个产品功能，面向个人爱好者、小商家和企业团队时，问题强度、预算来源、采购过程和支持要求都不同。^[2]

可以用一张表整理：

这些是常见差异，不是硬规则。一个专业个人用户可能比小企业支付更多，一项企业工具也可能完全自助。真正需要确认的是付款路径和决策条件。

价格还会约束获客方式。低客单价产品很难承受大量人工销售，高客单价产品若只依赖低意图流量，也可能缺少解释和建立信任的过程。^[1]

因此，定价评审至少要把这四件事放在一起：客户、价值、销售动作和交付成本。

从正在发生的替代方案开始

「客户愿意为这个功能付多少」很难直接回答。更可靠的起点是观察客户现在怎样处理问题。

替代方案可能包括：

• 雇人或外包；
• 使用另一个软件；
• 用表格和手工流程拼接；
• 延迟处理；
• 接受错误与损失；
• 完全不做。

访谈时可以追问最近一次：谁完成了任务，花了多久，使用了哪些工具，谁批准费用，发生错误后怎样处理。真实行为比「以后可能会购买」更接近预算证据。

替代成本不是产品价格的自动答案。软件若只能交付人工服务的一小部分价值，就不能直接把整项人工费用当作价格锚。还要比较结果范围、可靠性、采用成本和客户承担的风险。^[1]

区分价值、成本和价格

这三个概念经常被混在一起：

• 价值：客户因为产品获得的结果，或避免的损失；
• 成本：团队交付和维持服务需要付出的资源；
• 价格：客户为约定权益支付的金额。

服务器、模型和开发工时可以帮助判断最低可持续边界，却不能单独决定价格。一个成本很低的自动化，可能替客户节省大量重复劳动；一个开发很久的功能，也可能没有足够客户价值。

价值定价同样不能脱离成本。若重度用户持续消耗模型、存储、带宽和人工支持，统一低价可能让最活跃客户带来亏损。定价方案需要同时容纳客户价值和履约成本。

早期可以先写一个范围，而非一个精确数字：最低可持续价格、当前可解释价格，以及有更强证据和服务后可能达到的价格。每个数字都写明假设。

用问题强度检查付费可能

可以用 Must-have 与 Nice-to-have 区分问题强度，并用「头上着火」的直观说法判断客户是否正在迫切寻找方案。^[2]

可以继续问：

• 问题是否与收入、成本、合规、时间或关键体验相关；
• 不解决会发生什么；
• 客户是否已经主动搜索、采购或搭建替代；
• 使用频率和影响范围多大；
• 谁能够批准预算；
• 购买后多久可以看到结果。

紧迫问题通常更容易建立付费理由，但紧迫本身也不保证市场。客户可能预算很小、已有免费替代，或问题只发生一次。需要把问题强度与客户数量、购买路径和交付成本一起看。

找到最接近价值的计费单位

计费单位决定客户怎样理解账单，也决定收入能否随价值增长。

一个好的单位通常满足几项条件：

• 与客户获得的价值有明确关系；
• 客户能够预测和核对；
• 产品可以稳定测量；
• 不容易被规避或操纵；
• 使用增加时，客户和卖方都能接受；
• 销售、账单和支持容易解释。

常见候选包括账号、席位、项目、工作区、处理量、存储量、API 调用、生成次数、交易额、成功结果和固定周期。

例如，团队协作产品按 Seat 收费容易理解，价值也可能随成员增加；一项批处理服务按处理量收费更接近使用；一项需要持续维护但使用波动不大的工具，固定月费可能更简单。

不要因为底层成本按 Token 计算，就默认向客户销售 Token。客户可能更理解文档、分钟、任务或完成的工作量。内部成本单位和外部价值单位可以不同。

计费模型的六种常见起点

截至 2026 年 8 月，Stripe 的产品与价格文档把 Flat rate、Per-seat 和 Usage-based 列为常见模型。^[3] 实际产品还会使用一次性、抽成、附加项和混合结构。

一次性收费

适合一次性交付、永久许可或主要价值在购买时完成的产品。需要写清更新、支持、设备、版本和未来兼容范围。持续产生服务器与模型成本的服务，使用一次性价格时要核算长期履约。

固定周期费

每月或每年支付固定金额，解释和预测都比较简单。若客户用量差异很大，需要限制公平使用、设计升级条件，或接受重度客户对毛利的影响。

按席位收费

适合价值随团队成员、权限和协作扩大而增长的产品。需要定义访客、只读成员、机器人账号和临时成员是否计费，避免账单与实际协作方式冲突。

按用量收费

客户根据处理量、调用、存储或其他使用单位付款。价格与使用更同步，也会带来预算不确定、计量、延迟、争议和异常消耗问题。

按交易抽成

平台从成交、预订、支付或撮合金额中收取固定费用或比例。它与交易价值接近，但要处理退款、拒付、取消、税费、线下成交和归因边界。

混合收费

固定订阅加额度、超额、Seat、附加模块或服务费。混合模型可以覆盖多类价值和成本，也更难解释、实现和维护。早期只在单一模型明显失真时增加复杂度。

模型名称不能决定是否合适。最终要回到客户怎样获得价值、怎样预算，以及团队能否准确出账。

用量计费首先是一套数据系统

用量计费在页面上可能只是一行「按使用付费」，背后需要完整计量。

Stripe 当前文档将用量计费拆成四部分：接收使用数据、配置产品与价格、按使用出账、监控阈值与趋势。Meter Event 需要关联事件名、客户、数值、时间和防重复标识，Meter 再按周期汇总。^[4]

选择用量模型前要回答：

• 哪个事件代表可计费使用；
• 失败、重试和重复请求是否计费；
• 事件迟到或丢失怎样修正；
• 客户能否实时查看用量；
• 是否提供预算、额度和告警；
• 账单发生争议时保留什么证据；
• 内部成本与客户账单的时间差多大；
• 价格变更怎样影响当前周期；
• 取消时最后一段用量怎样结算。

复杂计费会增加开发、客服和财务成本。若客户价值可以用简单套餐表达，早期不必为了显得专业而引入多维费率。

Outcome-based Pricing 的边界

按结果收费听起来最接近价值。只有在结果可以清楚定义、可靠测量，并能够合理归因时才容易执行。

需要提前约定：

• 什么算成功结果；
• 数据由谁提供，何时冻结；
• 多个渠道共同作用时怎样归因；
• 客户改变流程后怎样处理；
• 结果被撤销、退款或作弊怎么办；
• 最低费用、上限和结算周期；
• 双方如何核对和申诉。

招聘、销售、广告和交易场景常受外部因素影响。产品只控制其中一段流程时，按结果收费可能把不可控风险全部留给卖方，也可能让客户不愿分享完整数据。

可以先使用固定费加明确成功奖励，或先以手工服务验证计量和归因，再决定是否产品化。