恭喜！我们为我们的客户构建了一个基于使用量的电话（语音和短信）计费系统，并且我们理解其中的痛苦。并不是要贬低你们的发布，但创始人/产品经理应该仔细考虑，即使使用像Lago这样的工具，基于使用量的计费是否最适合你的业务和客户。我们一开始是基于使用量的计费，但几年后（当我们了解了客户使用趋势后——这是关键）我们发现客户愿意每年多支付约20%来获得无限访问权限，因为客户想要一个可预测的账单。我们实际上是在跟随像移动电话从按使用量计费到无限计划这样的趋势。在我们的发展过程中，后来我们发现投资者（以及我们的会计师）也喜欢这种可预测性。当不处理一些大客户在某一季度使用量下降的情况时（即使业务整体在上升），展示“向上并向右”会更容易。没有一种模式适合所有人——基于使用量的计费肯定有其适用的场景——只是要仔细权衡你的模式，因为中途改变模式是一项巨大的工作。
源讨论Launch HN：Lago（YC S21）– 开源按使用量计费原帖 141 条评论 · 导入时统计大家好，Hacker News，我们是Lago的联合创始人：一个开源的Stripe Billing、Chargebee和Recurly的替代方案。也就是说，我们开发的软件可以帮助企业根据订阅、使用情况、折扣、税款、信用证或协商条款来计算自己的客户应该付多少钱，然后向他们开票。 我们的网站是https://www.getlago.com，我们的Github在这里：https://github.com/getlago/lago。 我们注重可组合性（只使用你需要的部分）、计量（衡量终端用户使用软件服务的程度，以便根据使用情况收费）、代码透明度（我们是开源的，没有黑箱——你可以完全了解我们如何构建我们的API）、可审计的代码、不绑定到任何生态系统的锁定、以及公平的定价（我们不抽取你的收入分成）。 我们已经在金融科技领域有超过7年的时间，并且是最早的企业之一…
完整原文把你的经验，加入这段讨论。
我们完全同意你的观点。实际上，Lago的第一个标语是“为产品驱动的SaaS计费”，用词有点令人困惑，但我们的想法是： （i）“纯按使用量计费”模式（比如Snowflake的模式）不会成为SaaS的主要标准，正如你提到的原因，主要原因是可预测性（对商家和终端用户而言）。现金回收也是一个大问题：如果你在使用后才收取现金，争议率可能会很高。 （ii）然而，定价将越来越多地包含“使用维度”（每月活跃行数、邮件数量、使用的GB数等），并且这一趋势正在迅速传播（根据最新的OpenView报告，五分之三的SaaS公司都如此）。 它可以有多种形式：包括每月基础使用量的年度订阅，或基于消耗的预付信用额度，或处理的付款金额等。 这就是我们在Qonto.com所经历的，并且我们已经解决了这个问题…
完整原文> 展示“向上和向右”更容易 我觉得很有趣的是，MBA们最终做出决策时都是根据快速看一下图表。现在，工程师们也开始为了那个图表而优化了。 我犯了一个错误，随意给出了一个产品的销售数字，结果有人将其纳入了一个被精确到小数点的ROI计算中。
完整原文我对你们如何处理按使用量计费的供应商（我猜这在电信领域是常态）很感兴趣，如果你们无法将这部分费用转嫁给客户，你们会怎么做？你们会为客户提供无限计划，定价较高，然后希望他们不会使用太多以至于你们亏本吗？
完整原文很好的见解。提供“无限”的东西是一个巨大的竞争优势。它能让客户感到安心。关键在于预测每个客户的平均成本，并据此定价（利润+对异常情况的额外准备）。 找到平均成本可能很困难，但通过一些指标和良好的预测能力是有可能的。
完整原文我在一家IT服务提供商工作，同时也提供一些云产品。 客户一开始通常希望有所有灵活性（通常是为他们的开发人员），让他们可以自己启动服务器，并希望按使用量计费。否则不是浪费钱吗？ 然后他们自己的财务部门会抱怨，因为他们使用SAP，每次账单与合同或上个月不同的时候都会很麻烦，需要经过五层的审批/解释/或者其他流程。 所以接下来的步骤是，他们每月购买一定数量的“云积分”，这样发票金额保持不变，同时有报告和/或账户经理的明确（但通常未写明）承诺，如果他们有可能超过配额时会通知客户。 在真正的大公司/不灵活的公司中，采购经理似乎更容易接受更高但稳定的成本。…
完整原文我经营一家SaaS公司，每次我们尝试实施按使用量计费时，都需要花很多精力教育客户它的工作方式。我认为这更多是一个商业问题而不是技术问题。就像你说的，按使用量计费有它的适用场景（可能如果你销售的是面向技术/开发人员的产品，比如计量API）。但如果你与客户打交道的是更偏向B2B的客户，他们需要向采购/财务/会计部门汇报，固定成本总是更容易销售。即使这意味着他们最终支付的总金额更多。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。