Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Skope (YC S25) – Outcome-based pricing for software products

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#21

Post by JoshPurtell »

benjsm wrote: post #17
JoshPurtell wrote: post #16

This is a really great idea! 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?

Thank you - yes! Would love to lean more about mechanism design. Mind diving deeper?

The basic idea is this. The customer has some "curve" that represents how much he values different outcomes. Maybe he values good outcomes at $1, and great outcomes at $100. The supplier also has a cost curve - by definition, it will cost him more to supply a great outcome than a good outcome (otw he'd just always supply the great outcome).

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

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#22

Post by JoshPurtell »

JoshPurtell wrote: post #21
benjsm wrote: post #17

Earlier quoted context omitted.

Thank you - yes! Would love to lean more about mechanism design. Mind diving deeper?

The basic idea is this. The customer has some "curve" that represents how much he values different outcomes. Maybe he values good outcomes at $1, and great outcomes at $100. The supplier also has a cost curve - by definition, it will cost him more to supply a great outcome than a good outcome (otw he'd just always supply the great outcome). Setting a fixed price is a simple way to help these two parties transact. But…

FWIW, if this sounds like arcane academic musing ... applied mechanism design for a while was essentially just the study of google ad auctions, and Google invested very very heavily in researchers to figure out how to do this for them

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#23

Post by AznHisoka »

benjsm wrote: post #6
mushufasa wrote: post #4

This sounds really great in concept. 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.

Thank you! To define the outcomes, it will be up to our customer and their users to state precisely what an outcome is and how it will appear. Once we have that information, we sync into their systems of record and act as that verification layer. It’s not an automated self-report-system, because they don’t have to report anything. As the work gets completed successfully (ie, a meeting booked or a customer support tic…

>> we will see it, verify it and bill it in realtime.

How do you verify that work got completed?

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#24

Post by benjsm »

JoshPurtell wrote: post #22
JoshPurtell wrote: post #21

Earlier quoted context omitted.

The basic idea is this. The customer has some "curve" that represents how much he values different outcomes. Maybe he values good outcomes at $1, and great outcomes at $100. The supplier also has a cost curve - by definition, it will cost him more to supply a great outcome than a good outcome (otw he'd just always supply the great outcome). Setting a fixed price is a simple way to help these two parties transact. But…

FWIW, if this sounds like arcane academic musing ... applied mechanism design for a while was essentially just the study of google ad auctions, and Google invested very very heavily in researchers to figure out how to do this for them

Very very interesting. It makes a lot of sense. I appreciate you sharing.

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#25

Post by AznHisoka »

l3onl1ur wrote: post #14
abxyz wrote: post #5

Outcome-based billing is interesting. I think some people may balk at the idea of trusting customers to self-report their outcomes but self-reporting already happens often in enterprise billing. A customer can defraud their service providers by underreporting but the risk to their relationship with the service provider is rarely worth it (if the service isn't delivering value, drop it, if the service is delivering va…

> 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 pl…

>> 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 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

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#26

Post by benjsm »

JoshPurtell wrote: post #22
JoshPurtell wrote: post #21

Earlier quoted context omitted.

The basic idea is this. The customer has some "curve" that represents how much he values different outcomes. Maybe he values good outcomes at $1, and great outcomes at $100. The supplier also has a cost curve - by definition, it will cost him more to supply a great outcome than a good outcome (otw he'd just always supply the great outcome). Setting a fixed price is a simple way to help these two parties transact. But…

FWIW, if this sounds like arcane academic musing ... applied mechanism design for a while was essentially just the study of google ad auctions, and Google invested very very heavily in researchers to figure out how to do this for them

Definitely digging deeper into this now. I think it becomes more and more important as models improve.

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#27

Post by benjsm »

tomjohnneill wrote: post #10
benjsm wrote: post #9

Earlier quoted context omitted.

It’s a really tough time for non-profits. Large amounts of their funding was cut, which is genuinely impacting their day-to-day. Employees work long hours and are not paid well. Turnover rate is really high. It’s just a really hard industry right now.

Did the agents you built work? I think we're doing something similar in the UK and intrigued to know how it went for you ( https://www.plinth.org.uk )

Agents are pretty good at finding people on the internet now. It worked. We never got into grant-writing though, but it seems to be a different service. How do you do it?

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#28

Post by benjsm »

AznHisoka wrote: post #25
l3onl1ur wrote: post #14

Earlier quoted context omitted.

> 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 pl…

>> 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 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…

I get it. It definitely isn’t the right fit for every use case at this point in time. That’s why we’ve built support for subscription and usage models as well. Then there's incentive for a sales tool to still charge on usage or subscriptions (slightly less than they normally would), but have the upside of an outcome converting. For buyers, this should be seen as the seller having confidence in their product.

Re: Launch HN: Skope (YC S25) – Outcome-based pricing for software products

#30

Post by hermitcrab »

benjsm wrote: post #12
svnt wrote: post #11

This is interesting, but it seems to be at odds with SaaS models where the idea can be you get high margins because you get low usage generally. 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…

Thanks! Definitely see where you’re coming from. Software startups with really good products are generating massive amounts of business value for their customers right now. Subscriptions and usage models really constrain them in how much they can capture of that. Incentives are also constantly misaligned, especially with usage as buyers will always try to minimize usage as much as possible. Charging on outcomes chang…

This whole area sound so incredibly ripe for gaming.

>Tickets closed without being escalated to humans are usually what’s defined as an outcome.

So I can make bank with a bot that replies to every query with "** you! Ticket closed." ?

>cost savings for a dental clinic

How can you software possibly know that?

Post reply on HN