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 ticket closed) we will see it, verify it and bill it in realtime.
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.
"we sync into their systems of record and act as that verification layer"
As long as those 'systems of record' are controlled by the customer, then that is self reporting. If they don't enter a sale into their CRM or tag it differently there's nothing you can do.
The industries where I have seen pay-for-outcomes work are industries where there are regulated legal controls or strong third parties. For example, a lot of financial services have commission payments that are based on the actual invested assets as measured by the bank/custodian, that then get paid out to salespeople or partnerships.
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 value, the fees are worth it). SaaS companies are already regularly writing off unpaid bills. That said...
"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.
> 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.
>> 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
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.
This is a totally valid concern - we believe that outcomes cannot be treated the same as "usage events". Facilitating trust between a seller and a buyer requires that the buyer can see exactly what they are being billed for. Existing platforms ingest event data, but only display it back to their users' customers in the form of an aggregated summary (ex. 500 API calls), rather than the specific details of each event. We believe that this approach works for granular usage data, but not outcomes. Hope this helps!
Great concept, and love the approach of solving your own problem. There is a wide gulf between consuming something (tokens, emails sent, etc) and outcomes.
There has to be a translation layer the customer 1) can understand, and 2) agrees with.
Most companies settle for a consumption-based proxy to value and outcomes.
SaaS vendors do these business value assessments, which are useful to the executive buyer and the vendor. The issue I find with them is customers don't want to do them in collaboration with the vendor since the vendor will use that to justify higher prices. 'Outcome' and 'business value' seem somewhat synonymous - so maybe need to focus on the business value more closely (and all the modelling that goes into that). I don't know if all of the billing needs to go through this, but perhaps discounts or bonuses could - at the very least helping with retention.
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
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
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 models, right?
And when/how is success measured? Otherwise it’s just like API billing, right?
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 changes that.
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.
Thank you - would love to hear more about the gaming use case.
Not quite, because the buyer and seller would never agree to that being a real outcome. It would have to meet certain requirements/thresholds for customer satisfaction. That’s where we come in to verify that those contract terms are actually met as it happens.
There are a ton of ways to calculate cost savings depending on what it’s built for. Voice agents that handle booking and outbound calls, supplier sourcing agents that only buy the best priced items, etc. It’s then possible to translate those things into a monetary figure, relative to the business.
> depend on every single customer reporting each outcome quickly and accurately.
Why would the end customer have to report this? The company should be determining this and in very specific scenarios, ask the customer to approve the outcome.
It’s very easy to game though if you’re relying on end-customers to always self report, just look at all the people getting refunds on Uber Eats because the food wasn’t the “right outcome”
Congrats on the launch guys, but is this any different from setting up usage based pricing in stripe? This kind of seems like a solution in search of a problem.
We've designed our platform to use a smaller set of primitives than Stripe Billing (no Meters + Subscriptions + Prices + Rate Cards), making it easier to configure, and more friendly for non-technical users. For outcome-based pricing, we are able to provide greater transparency than Stripe in displaying the specific outcomes achieved and the context for each of them.
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.
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?
I'd suggest making your developer documentation public. A huge part of understanding whether I need this or not is reading how to build in your outcome-based pricing integration into my product.
100%! We think pricing and biz model will become a differentiator. Being able to adapt and iterate on pricing will be really important as underlying models get better
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 ticket closed) we will see it, verify it and bill it in realtime.
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.
"we sync into their systems of record and act as that verification layer"
As long as those 'systems of record' are controlled by the customer, then that is self reporting. If they don't enter a sale into their CRM or tag it differently there's nothing you can do.
The industries where I have seen pay-for-outcomes work are industries where there are regulated legal controls or strong third parties. For example, a lot of financial services have commission payments that are based on the actual invested assets as measured by the bank/custodian, that then get paid out to salespeople or partnerships.
>> we will see it, verify it and bill it in realtime.
How do you verify that work got completed?
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 value, the fees are worth it). SaaS companies are already regularly writing off unpaid bills. That said...
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.
> 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.
>> 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
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.
This is a totally valid concern - we believe that outcomes cannot be treated the same as "usage events". Facilitating trust between a seller and a buyer requires that the buyer can see exactly what they are being billed for. Existing platforms ingest event data, but only display it back to their users' customers in the form of an aggregated summary (ex. 500 API calls), rather than the specific details of each event. We believe that this approach works for granular usage data, but not outcomes. Hope this helps!
Great concept, and love the approach of solving your own problem. There is a wide gulf between consuming something (tokens, emails sent, etc) and outcomes.
There has to be a translation layer the customer 1) can understand, and 2) agrees with.
Most companies settle for a consumption-based proxy to value and outcomes.
Thank you. I agree, that transparency piece is crucial and something we’re really focused on.
SaaS vendors do these business value assessments, which are useful to the executive buyer and the vendor. The issue I find with them is customers don't want to do them in collaboration with the vendor since the vendor will use that to justify higher prices. 'Outcome' and 'business value' seem somewhat synonymous - so maybe need to focus on the business value more closely (and all the modelling that goes into that). I don't know if all of the billing needs to go through this, but perhaps discounts or bonuses could - at the very least helping with retention.
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
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.
Definitely digging deeper into this now. I think it becomes more and more important as models improve.
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 models, right?
And when/how is success measured? Otherwise it’s just like API billing, right?
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 changes that.
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.
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?
Thank you - would love to hear more about the gaming use case.
Not quite, because the buyer and seller would never agree to that being a real outcome. It would have to meet certain requirements/thresholds for customer satisfaction. That’s where we come in to verify that those contract terms are actually met as it happens.
There are a ton of ways to calculate cost savings depending on what it’s built for. Voice agents that handle booking and outbound calls, supplier sourcing agents that only buy the best priced items, etc. It’s then possible to translate those things into a monetary figure, relative to the business.
'gaming' as in 'game the system, take advantage of' .
Ah got it. Gaming the system in what sense?
> depend on every single customer reporting each outcome quickly and accurately.
Why would the end customer have to report this? The company should be determining this and in very specific scenarios, ask the customer to approve the outcome.
It’s very easy to game though if you’re relying on end-customers to always self report, just look at all the people getting refunds on Uber Eats because the food wasn’t the “right outcome”
Gotcha - the company can’t always determine this without needing access to their customers systems in order to. We automate that for them.
Agreed and that’s what we are working to eliminate. It’s on us to approve what a successful outcome is, based on the terms of their agreement.
Congrats on the launch guys, but is this any different from setting up usage based pricing in stripe? This kind of seems like a solution in search of a problem.
We've designed our platform to use a smaller set of primitives than Stripe Billing (no Meters + Subscriptions + Prices + Rate Cards), making it easier to configure, and more friendly for non-technical users. For outcome-based pricing, we are able to provide greater transparency than Stripe in displaying the specific outcomes achieved and the context for each of them.
I'd be very interested to hear more about how the non-for-profit agents platform went/anything else you learnt.
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?
Will you decrease the usage counter if the software is not working properly and the user is forced to use the Undo command?
I'd suggest making your developer documentation public. A huge part of understanding whether I need this or not is reading how to build in your outcome-based pricing integration into my product.
Thanks for that - on it. Would love to run you through it myself. How can I reach you?
dev@locunity.com - thanks!
400 years of litterature across the world has warned us about this impending doom, yet we are racing headlong into it.
Context?
Yes - not sure I follow. Happy to hear more about why that came to mind...
this is great, outcome based pricing is definitely a competitive advantage and more aligns you with your customer!
100%! We think pricing and biz model will become a differentiator. Being able to adapt and iterate on pricing will be really important as underlying models get better
Sounds like Pay-Per-Action in advertising.
Agreed - we think it’s similar to when Google Ads first released over two decades ago :)
Isn't this essentially the unity price model that's getting laughed out of the market?
Unfamiliar with it. Is there a link I can check out?