In Output Versus Outcome Model, we described the difference between output-based model and outcome-based model.
In this post, we’ll look at a few attributes of the outcome-based model.
To recap:
Output: I deliver ERP, you use it to reduce your DSO.
Outcome: I deliver a reduction in your DSO by using ERP.
where:
- “I” means vendor
- “You” means customer
- ERP means Enterprise Resource Planning software, which supports invoicing, AR, collections, dunning, among other features, and tight integration between them
- DSO means Days of Sales Outstanding i.e. the average time to collect payments from customers. In B2B technology business, DSO is typically in the 0-45 days range
Output is the vendor’s product whereas outcome is related to the customer’s business process.
We then saw a few examples of vendors for each model:
- Output model: Microsoft, Oracle, Salesforce.
- Outcome model: Google (Play Store), Swiggy, Uber, Visa.
There are three intrinsic attributes of the outcome-based model.
- Outcome risk
- Higher capital requirements
- Winner takes all
1. Outcome risk
As a vendor, when I supply an ERP with invoicing, AR, collections, dunning, and tight integration between these business processes, I can claim that my software has the functionality required to reduce Days of Sales Outstanding (DSO).
However, mere features don’t deliver the outcome. It’s down to the customer to use those features to achieve the reduction in DSO. Therefore, if I commit the outcome – reduction of DSO – I’m betting on the customer carrying out the required activities to convert my features into his outcome. Since these activities are beyond my control, I’m taking a risk by making this commitment. We’ll call this outcome risk. Logically, I’ll need to price this risk by charging a higher price for offering outcome model compared to output model where I don’t face a similar risk.
Now, looking at this from the customer point-of-view, when my customer buys my ERP to reduce ERP, he cannot be sure that the features in the ERP related to reduction of DSO will work. This creates an outcome risk for him. He can significantly mitigate this risk by seeing a demo of my ERP, doing a deep dive PoC into DSO-related features, and talking to a few of my reference customers.
As you can see, the customer has more data to price outcome risk than me, so he ascribes a lower cost to his outcome risk than I do to mine.
Due to this asymmetry in the pricing of outcome risk, most customers eventually choose output-based model (even if they demand outcome-based model earlier in the sales cycle).
(Another factor is manifold returns we discussed in the earlier post here.)
2. Higher capital requirements
In the output-based model, I collect my money upfront as soon as I deliver my ERP software.
In the outcome-based model, there are many more steps before I can raise my invoice: I supply my software; it needs to be implemented; once it goes live, the customer’s bill collectors need to get familiar with the new DSO-related features, start using them to achieve the reduction in DSO. (This is equally true even if I deploy my team to collect bills on behalf of my customers because I still need the customer’s AR data). As a result, it takes me way more time to get my payment.
This means that I need to provision higher working capital to sustain my operations until I can collect my fees in the case of outcome-based model. (Alternatively, I can sell my receivables to a receivables financing firm but I’d have to pay a fees for the service.)
3. Winner takes all
In the spirit of “no one bats a thousand”, outcome will not be achieved in 100% of cases, so I will not get paid anything for some engagements. This is somewhat similar to the VC Investment Model where not all investments yield returns. (Typically, one-third of investments go to zero, one-third merely return the capital and one-third deliver multibaggers.)
Not surprisingly, like the VC model, outcome-based model tends to drive “Winner Takes All”. This is readily reflected in the nature of companies that operate on this model: Google (Play Store), Swiggy, Uber, Visa.
On the face of it, outcome-based model seems more attractive to customers but, if you scratch the surface, you’ll find that
Customers want outcome-based model but only until they get it.