启动 HN:Skope(YC S25)——基于结果的软件产品定价

12作者: benjsm6 个月前原帖
嗨,HN,我们是Ben和Connor,Skope的联合创始人(<a href="https://www.useskope.com">https://www.useskope.com</a>),我们提供一种支持基于结果定价的软件计费系统——也就是说,只有在您的软件实际有效时才向客户收费。我们是Stripe Billing、Orb和Metronome的替代方案,原生支持这种定价模式,因为我们相信这对于涌入市场的AI产品尤其必要,并且未来还会继续出现更多这样的产品。 <p>这是一个演示视频:<a href="https://www.youtube.com/watch?v=ORxhACQbu64" rel="nofollow">https://www.youtube.com/watch?v=ORxhACQbu64</a></p> 在创办Skope之前,我们开发了为非营利组织筹款的AI代理。我们在非营利领域没有找到合适的方向,原因之一是非营利组织(预算本就有限)没有动力承担购买昂贵软件的风险,这些软件声称能够以高昂的前期成本取代人类,但在此之前并未证明其价值。 <p>相反,他们应该能够在我们的产品真正有效时支付费用(例如,通过获得捐款或预约会议)。采用这种模式,我们不会从表现平平的产品中获利。同时,如果我们所销售的产品确实能发挥作用,我们也会获得更多的收益。所有这一切都将风险转移给我们的买家。</p> 尽管我们非常希望这样做,但在大规模上实现这一点并不容易。这将依赖于信任,并且依赖于每个客户快速准确地报告每个结果。这并不是最佳的解决方案。 <p>因此,我们决定自己构建这个系统……这意味着我们需要从头开始重建计费系统。但我们认为,一个人们为软件的实际工作付费的世界是美好的,在这种情况下,基于结果的定价将会流行,但我们并不认为这会一蹴而就。还有很多细节需要解决。与此同时,我们也建立了支持传统订阅和基于使用/信用的模型的基础设施,重点是使价格迭代变得非常简单。</p> <p>它是如何运作的:我们的用户可以通过单位(如消耗的代币或发送的电子邮件)轻松跟踪客户的使用情况,并设置定价规则,例如每个单位的价格或每月的使用限制。这些定价规则旨在灵活,可以轻松为每个客户进行修改。使用情况通过我们的API/SDK上传的事件记录,这些事件与定价规则映射,以便进行准确且不可更改的计费计算。在每个计费周期结束时,系统会根据该周期内记录的事件自动生成发票。我们正在与LLM可观察性平台(如Helicone和Langfuse)开发集成,以便轻松记录客户的使用数据。最后,我们通过Stripe(与Stripe Billing无关)简化了收款流程。</p> 对于具体的结果,我们正在努力充当客户与其用户之间的中介层。设置价格和单位的过程与之前所述相同,但我们将能够访问我们用户和他们客户的记录系统,以验证这些结果确实发生了。我们建立了一个客户门户,以便一旦结果被我们验证,客户就可以实时查看和确认这些结果。如果使用Skope的公司的客户想要对收费提出异议,我们计划通过平台自行处理。透明度和信任在这一模式下对所有参与方都非常重要,因此我们希望尽一切可能来促进这一点。 <p>我们非常喜欢基于结果的模型,因为它鼓励真正优秀的软件,并在买卖双方之间对齐激励。我们认为,随着越来越多的公司采用这一模式,软件的标准将会提高,从而带来更多的创新。同时,买卖双方都无法通过不正当手段来获得更好的交易。这类似于谷歌广告,它首次为在线广告引入了按点击付费的定价模式。我们正在努力使整个软件行业能够进入按表现付费的领域,就像谷歌20多年前所做的那样。</p> 我们以固定的订阅价格推出。反直觉的是,我们认为基于结果的模型并不适合Skope本身。计费产品不是“可能有效或可能无效”的产品,它需要确保有效。 <p>AI公司所需的商业模式需要新的计费基础设施,这正是我们正在努力提供的。我们还有很多需要学习的地方,期待听到其他人对未来的看法。</p> 请告诉我们您对想要看到的内容有什么想法。我们总是乐于讨论这个话题,并非常欢迎您的评论!
查看原文
Hi HN, we’re Ben and Connor, the co-founders of Skope (<a href="https:&#x2F;&#x2F;www.useskope.com&#x2F;">https:&#x2F;&#x2F;www.useskope.com&#x2F;</a>), a billing system that supports outcome-based pricing for software—that is, which charges your customers only when your software actually works. We’re an alternative to Stripe Billing, Orb, and Metronome that natively supports this pricing model, because we believe it’s especially needed for the AI products which are flooding the market and that will continue to be built in the future.<p>Here’s a demo video: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ORxhACQbu64" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ORxhACQbu64</a><p>Prior to working on Skope, we built AI agents that fundraised for nonprofits. We weren’t able to find our stride within the nonprofit world, one reason being that there was no incentive for a nonprofit (with an already small budget) to take on the risk of buying expensive software claiming to replace humans at a high upfront cost, without proving its value first.<p>Instead, they should’ve been able to pay every time our product really worked (in this case by securing a donation or booking a meeting). With this model, we wouldn’t profit off of nonprofits with a mediocre product. At the same time, we’d give ourselves more upside if what we were selling truly did its job. All while taking all the risk off of our buyers.<p>Although we really wanted to, there was no easy way to make this happen at scale. It would have had to rely on trust, and depend on every single customer reporting each outcome quickly and accurately. Not the best recipe.<p>So, we decided to build it…which turned out to mean rebuilding billing from scratch. But we think a world where people pay for software doing its job is a good one, in which case outcome-based pricing will catch on, but don’t think it’ll happen overnight. There are a ton of wrinkles to figure out still. In the meantime, we’ve also built the rails to support traditional subscriptions and usage&#x2F;credit based models with a focus on making iteration on price really easy.<p>How it works: Our users can easily track customer usage through units (like tokens consumed or emails sent) and set pricing rules such as the price of each unit or a limit for usage per month. These pricing rules are designed to be flexible items that can be modified easily for each customer. Usage is recorded as events uploaded via our API&#x2F;SDK, which are mapped to pricing rules for accurate, immutable billing calculations. Invoices are automatically generated at the end of each billing period based on the events logged during the given period. We are working to develop integrations with LLM observability platforms such as Helicone and Langfuse to make it easy to record customer usage data. Finally, we make it easy to collect payments via Stripe (disconnected from Stripe Billing).<p>For outcomes specifically, we’re working on acting as a middle layer between our customers and their users. The same process for setting prices and units follows as said before, but we’ll have access to both our users’ and their customers’ systems of record to verify that these outcomes actually happened. We built a customer portal so that once outcomes are verified by us, the customer can see and validate them as they happen. If a customer of a company using Skope, wants to dispute a charge, we plan to handle it ourselves through the platform. Transparency and trust are really important between all parties within this model, so we want to do everything possible to encourage that.<p>We really like the outcome-based model because it encourages truly good software and aligns incentives between buyers and sellers. We think that the bar for software will become higher as more companies adopt it and it’ll lead to cool things. At the same time, neither buyers nor sellers can pull a fast one on the other to get a better deal. It’s similar to Google Ads, which introduced pay per click pricing to online advertising for the first time. We’re trying to make it possible for the entire software industry to come into the pay per performance realm, just like Google did over 20 years ago.<p>We’re rolling out at a flat subscription price. Counterintuitively, we don’t think the outcome-based model makes sense for Skope itself. A billing product isn’t one that “may or may not work”, it needs to just work.<p>The way AI companies do business needs new billing infrastructure, and that&#x27;s what we’re working to provide. We have a ton to learn and are eager to hear how others see the future playing out.<p>Please let us know if you have any thoughts on things you’d like to see. Always excited to riff on this and we’d absolutely love your comments!