pricing

定价（收取什么费用，以及如何定价）

价格不是最后才选定的一个数字，而是一项定位决策：它告诉市场你是谁、你能替代什么，以及你认为自己值多少钱。要依据证据定价，而不是受恐惧驱使。

适用情形： 你还在猜价格；凭直觉定价后，现在觉得难以调整；不知道免费版的界限该划在哪里；开发者在用，却没人付费；或者你认为“开发者不会为这个付费”，所以从来没有收费。

核心理念

按顺序做出三个决策。大多数创始人直接跳到第三步，然后纳闷为什么无人转化。

1. 价值指标（按什么收费）。这是最重要的定价决策。这里选错了，再好的套餐结构也救不了你。
2. 套餐设计（什么免费、什么付费、什么属于企业版，以及什么情况会触发升级）。
3. 价格（各套餐的实际价格）。

贯穿始终的一条原则是：按客户获得的价值定价，绝不要按你的成本或恐惧定价。 AWS 账单不是定价策略。

首先：你真的准备好定价了吗？

在证明用户会回来之前，不要设置付费门槛。如果第 2 周留存率很低，付费墙只会把漏水的漏斗变成更小的漏水漏斗。先证明留存，再实现变现（参见 know-if-its-working）。只有一种例外：如果买家已经发邮件问“我们能为 X 付费吗？”，无论你处于哪个阶段，这都是一个积极信号。明确表示愿意付费，是最强烈的信号。

框架：价值指标

按能随客户获得更多价值而增长的指标收费。好的指标应当：

• 随客户的成功而增长，客户发展越好，账单越高（席位、活跃用户、项目、事件、API 调用量、GB、构建次数、受监控的端点）。
• 足够可预测，让财务团队能够预测。纯按用量计费若一夜之间飙升 10 倍，会造成账单冲击和客户流失。
• 一句话就能说清楚。 如果开发者无法大致预测自己要付多少钱，就不会采用。

Does the value come mostly from more PEOPLE using it (collaboration, seats)?
├─ YES → per-seat, but watch for seat-sharing and bot accounts deflating it
└─ NO  → value comes from more USAGE (events, calls, compute, data)
         → usage-based, with a floor and caps so the bill stays predictable

混合计费很常见，也完全可行：平台费用加用量费。若价值由机器或用量驱动，避免按席位收费（这会给你希望增加的部分征税）；若价值来自人员协作，避免纯按用量收费（这会迫使团队限制访问）。

框架：套餐设计（免费到付费的界限）

对于 OSS 或 PLG 开发者工具，免费版是**获客手段，不是慈善。**界限不在于“我能免费提供多少”，而在于“严肃团队需要什么，而个人开发者不需要什么”。

• 免费 / 开源： 为一名开发者或一个小团队提供核心价值。要足够慷慨，让它成为其工作流的一部分。这就是你的分发渠道。
• 付费（团队版）： 提供一家公司而非个人一旦开始认真使用就会需要的功能：协作与席位、更高限额和扩展能力、SSO、审计日志、角色、合规能力（SOC 2、本地部署、数据驻留）、支持和 SLA。
• 企业版： “联系我们”。通常从需要进行安全审查、采购和商定定制条款时开始，往往是在有人要求 SSO 或 DPA 时。

升级应由价值积累到一定程度时的自然节点触发，而不是任意设置一道门槛。好的触发点：“你添加了第三位队友”“你的事件数超过了 1 万”“你需要 SSO。”不好的触发点：倒计时，或隐藏一项没有它工具就毫无用处的功能。

经验法则：**团队、规模和信任要收费，个人价值则免费提供。**开发者能接受“公司需要这个”时设置付费墙；但他们会反感“你宣传的功能”竟然要付费。

框架：找到价格

绝不要在会议室里拍板。按依据的强弱排序：

1. 被婉拒的付费意愿。 你已经收到的“我们能为 X 付费吗？”这类消息。回复并询问：没有它会造成什么代价？价格要达到什么水平，才能在公司内部获批？这是免费的，也是现有信号最强的定价研究。
2. 价值锚定。 根据你替代了什么、节省了什么来定价。每月为团队节省 10 小时，按每小时 100 美元的综合成本计算，价值就是 1,000 美元；收费 50 美元就等于把空间拱手让出。获取交付价值的一部分，不要压低价格去打败对手。
3. 竞争对手锚定。 了解买家心里已有的那个价格。如果他们拿你和每月 30 美元的工具比较，你就需要给出收费 99 美元的理由，或者收费 9 美元的理由。两种都可能奏效。“差不多，但便宜一点”注定失败。
4. 区间提问（在 talk-to-users 通话中）：“价格高到什么程度时，你会贵到不考虑？价格低到什么程度时，你会怀疑质量？”两者之间就是你的定价区间。

值得了解的门槛：

• 如果从来没人对价格提出异议，说明你定得太便宜。有人说“这可不便宜”的合理比例是正常的。
• 目标是让客户获得约为价格 10 倍的价值。低于约 3 倍，客户就会流失；这样的账经不起预算审核。
• 年付大约相当于免费两个月（优惠 15% 到 20%）。这能带来现金流和留存。
• 锚定高价。 展示高价档，让你希望客户选择的档位显得合理。三个档位比两个转化效果更好，通常应以中间档为目标。
• 对 OSS/PLG 产品来说，免费转付费转化率达到 2% 到 5% 很正常。接近零通常说明免费转付费的界线划错了，而不是价格不对。

看起来合理的错误

• 成本加成定价。 “算力成本是 8 美元，所以我要收费 12 美元。”成本是底线，不是策略。按价值定价。
• 从不收费。 “开发者不会付费”几乎总是在说“我还没问过，而且我害怕问”。那些被婉拒的付费邮件已经证明事实并非如此。
• 档位太多。 四个或更多档位会让人难以决策。对于自助服务，三个是上限。
• 免费档位过于慷慨。 如果正规公司永远不需要升级，你打造的只是一个很棒的免费工具，而不是一门生意。把界线设在团队使用、规模扩展以及合规需求上。
• 对机器价值产品按席位收费（或对协作产品按用量收费）。最终，你会恰恰对自己希望更多发生的行为征税。
• 靠价格竞争。 “性价比最高”和“比 X 更便宜”都是一场逐底竞争，而且根据夸大宣传规则，无法证明。要凭价值指标和切入点取胜，而不是靠折扣。
• 因恐惧而打折。 客户一说“太贵”你就让步，会让每位买家都学会施压，也会显得你不相信自己的价值。
• 发布没有上限的按用量定价。 可预测性胜过低廉的标价。账单冲击是按用量计费模式中导致客户流失的首要原因。

接下来的 30 分钟

• 用一句话说出你的价值指标：“我们按 ___ 收费。”确认它会随客户的成功而增长，同时保持可预测。
• 划出免费转付费界线：个人开发者可免费获得什么，而公司必须为哪些内容付费（席位、规模扩展、SSO/合规、支持）。
• 找出你婉拒过的所有**“我们能为 X 付费吗？”**消息。拟好包含三个问题的回复（没有它的代价、能获批的档位形式、大致预算）。
• 设计三个档位（免费/OSS、团队版、企业版—联系我们），并为每次升级设置一个明确的触发条件。
• 为团队版定出一个真实价格，以价值而非成本为锚。如果这个价格没有让你稍微有点紧张，那就太低了。

---

内容源自真实的开发者工具 GTM 经验，并借鉴了 Adam Frankl（The Developer-Facing Startup）和 Jakub Czakon（markepear.dev）的框架。 定价是你制定的杠杆效应最高的数字，也是独自制定时最容易出错的数字。想让真人帮你看看？欢迎通过 LinkedIn 联系我。