Comment by abxyz
3 days ago
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!