Launch HN: Skope (YC S25) – Outcome-based pricing for software products
Here’s a demo video: https://www.youtube.com/watch?v=ORxhACQbu64
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.
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 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.
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.
So, we decided to build it…which turned out to mean rebuilding billing from scratch. 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/credit based models with a focus on making iteration on price really easy.
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/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).
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.
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 20 years ago.
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.
The way AI companies do business needs new billing infrastructure, and that'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.
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!
It sounds like your first approach is to verify that events met an agreed-upon threshold.
Have you looked into Mechanism Design and getting customers to e.g. pay more for great outcomes, and a little for ok outcomes?
Setting a fixed price is a simple way to help these two parties transact. But hypothetically, it may be more efficient - e.g. you will let more mutually-beneficial events happen - to ask both parties for what their number is for a given event, and having both transact when the numbers are far enough apart (cost is $10, value is $100).
The problem is, you can't directly ask the parties, because they don't want to reveal how high/low they're willing to go for no reason. So, you should essentially structure your questions into a pre-defined algorithm so that everyone is incentivized to reveal at least the ballpark of where their cost/value is. The study of how to structure those questions is a subset of mechanism design / information design, which is a branch of Econ related to game theory
I can see why people buying/using software would want this, but why would any software startup want to use it? What are the markets (other than non-profit), where pay vs success (and not attention/friction) is the limiting factor? The idea is you’re unlocking new markets or models, right?
And when/how is success measured? Otherwise it’s just like API billing, right?
The entire AI customer support industry has pretty much already converged into this model. Tickets closed without being escalated to humans are usually what’s defined as an outcome. We think this model makes the most sense for any vertical AI company where agents are actually completing tasks end to end.
Success is defined by the buyer and seller before they use us. We just facilitate the parameters they agreed upon, so it’s pretty variable. A successful outcome can be anything from sourcing a real estate property that ends up closing to finding $X in cost savings for a dental clinic, using research agents. The biggest difference is you’re not just charging for tokens, but assigning a dollar figure to what a job well done looks like, no matter how many tokens it takes to get there.
I don't see detail here. As someone who would be interested in using this, can you clearly explain how you will measure and track the outcomes? That's the key detail that matters.
Relying on customers to self-report is not sufficient, and an automated self-report-system is not a true improvement.
Would love to chat as well (ben@useskope.com) if you have any questions specific to your use case. May be able to give a better answer, as the nuance really varies by use case.
How do you verify that work got completed?
https://www.useskope.com/resources/why-now
"Salesforce, Sierra, Zendesk, and Intercom are a few of the early movers in adopting an outcome based model. Their definitions of a 'successful outcome' vary from simply facilitating a conversation (Salesforce) to completing a customer support query with no human elevation needed (Sierra)."
"Chargeflow is another company that automates the process of collecting revenue and preventing chargebacks for ecommerce, which has adopted this model. They take 25% of each recovery and charge $39 for each chargeback prevention. Their pricing page explains the idea perfectly: success first, pay second."
Are these examples of "outcome-based billing" or just the redefinition of usage and/or fees as an "outcome"? "Facilitating a conversation" and "completing a support query" are not trust-based outcomes, that's just usage. A thing happened within the service's boundary. Stripe's usage based billing (and Orb etc.) can be used for this already.
I guess you are in a tough position because you are trying to provide real world examples of a category you are hoping to define, but in this case, perhaps it's best to wait for some clear real world examples instead of muddying the waters like this. I fear that reading this, most people would conclude that outcome-based billing is just a way to define your usage-based pricing, rather than something that needs a platform like Skope.
You're right in that the cases of real-world examples are rare, but I believe it's only in software. The concept of outcome-based pricing have always existed throughout different work for a long, long time – think about test-prep service that promises to only need to pay if you get X score, real-estate agent that carry commission as a % of sale price, etc.
I think this instills confidence in something like this and makes me wonder why such pricing models haven't been applied to tech yet.
I think those examples work because there is a clear, tight relationship and linkage between their work and outcome with very few external dependencies. If a a real estate agent can’t find you a seller, they’re 100% useless. They control 99% of the results.
There is very few software, on the other hand that clearly has that relationship. A sales tool that bills based on number of meetings has no control whether you have product market fit, whether you’re in a saturated market, or whether your sales rep is good at cultivating relationships. What makes more sense is billing you based in your usage. How successful the outcomes are from that usage is too dependent on so many variables that the software simply can not control… i don’t see why any software company would want to bill based on outcomes because of this