Usage-based Pricing is Tricky, Indeed
Indeed is backtracking after a failed attempt at usage-based pricing. But our Managing Partner, James Wilton, argues that unlike Indeed’s pricing model, the collapse was very predictable.
The Wall Street Journal published an interesting article about the fallout around Indeed’s new pricing model. It’s behind a paywall, so to give the sense of it without providing too much detail (far be it for me of all people to inhibit a business’s ability to monetize its own special sauce!) I would say the main takeaways are:
- Indeed started charging businesses “per application” (which, for the uninitiated, is a usage-based pricing model)
- This led to several small businesses getting “hammered” with large fees for unexpectedly large numbers of applications (though note that Indeed does allow you 72 hours to reject an application and not pay for it).
- Also (lesser point) Indeed uses dynamic pricing to adjust the price per applicant based on the # applications expected and other factors. While (at least IMO) this isn’t a bad thing it itself, it does add a layer of opaque pricing muddiness – which customers rarely like – to an already very muddy situation.
This has led to a large number of customer complaints, and Indeed is left trying to minimize the fallout.
I sympathize with Indeed. I don’t disagree with what they are trying to do, which presumably is trying to get more revenue growth from their pricing model through improved price differentiation, using a usage-based metric they believe reflects the value in what they do, which is drive qualified applications.
Unfortunately, it is a case of “right idea, imperfect execution.” I’d suggest that anyone with a strong pricing strategy background could have predicted this result.
What went wrong?
Indeed fell victim to the two greatest pitfalls in usage-based pricing:
1. Unpredictability. Unsurprisingly, customers like to know what they are going to be paying for what they’re purchasing. A lot of usage-based metrics are inherently unpredictable. As a customer it’s very difficult for me to know exactly how many (say) API calls, user sessions, or content downloads my team are going to need in a month or year. And so it is with applications for a job. I know how many I want, but I don’t know how many I’m going to get. And that’s a problem.
2. Tenuous Value Alignment. I would suggest that “# applications received” is sort of aligned to value but not fully. Few job posters would claim to not want more job applications. Getting more is definitely valuable, up to a point. As a poster I need to get enough applications so that I can be reasonably sure I’ll get enough good ones to fill the job with a strong candidate. But once I’ve hit that limit, getting more doesn’t really add more value. This is frequently the case with other usage-based metrics. I might agree that if the metric goes up, my value increases. But I likely won’t agree that if my usage increases by a factor of 10, my value increases at the same rate.
These two things together describe why Indeed met the reaction it did. Customers couldn’t predict the amount of applications they would get. And when they exceeded the number they wanted/needed, they didn’t get value from the extra, and so they weren’t willing to pay for them. Hence surprise. Hence outrage.
What could Indeed have done / do better?
If I worked with the team at Indeed, I would encourage them not to panic and immediately revert to what they were doing before. Clearly, they can’t keep the new pricing strategy. ButI’d suggest that there are some modifications they could make that would keep the intent of what they’re trying to achieve – more value-based, higher revenue growth potential – but remove the challenges they’ve encountered. (Some of these are combinable, but some aren’t. Read this as a list of separate ideas rather than components of a pricing strategy)
- Allow a cap: Simplest first. Just allow customers to cap the number of applications they will allow, or spend for the job posting. This means that customers have the confidence that spend will never be greater than $X. This is hardly an innovative approach – LinkedIn does this.
- Scale the “per app” price: As I mentioned earlier, your willingness-to-pay for extra applications before you hit your target is going to be a lot higher than it will be for extra applications once that threshold has been crossed. So why not align the price per application with the willingness-to-pay? Adjust the rates with the number of applications. That means Indeed will generate a bit extra if they overdeliver on applications but (hopefully) not so much that customers would complain.
- (My favorite) Use usage-based tiering: For SaaS aficionados this is the job application equivalent of “active users.” It would involve going back to charging per job posting, but tiering the price of the post by how many applications are received. For lower than X applications (lower than wanted/needed), it’s a low price. Between X and Y applications (expected range) it’s a medium price. For greater than Y applications (aspirational target) it’s a high price. This allows them to monetize application volume, but in a much more predictable and value-aligned way.
There are also options they could explore with moving away from “# applications” as a price metric entirely, and towards something more output and/or value-based:
- Charge by “# interviews. ” I suspect that “# interviews” is more value-based to customers than # applications. It’s certainly more output-based, since good applications will result in an interview. Hiring managers typically aim to do a minimum number of interviews after receiving applications for a role, but if it’s too hard to whittle down the candidates to that minimum number (i.e., several look great on paper, and we want to speak to all of them) they may run extra interviews. In this way, if Indeed truly is delivering great candidates, we would expect it to be reflected in a higher number of interviews. That said, the customer has complete control of their interviews, so it’s significantly more predictable as a metric. They would have to make sure they could audit the number of interviews. I suspect this would be achievable through withholding candidate contact details until the customer requests to interview the candidate.
- Charge per hire: The ultimate output-based model here would be to charge only when the customer makes a hire. This is risky for Indeed – there is a good chance that the customer decides not to hire an Indeed applicant – but it’s potentially lucrative, since the willingness-to-pay for a hire significantly exceeds that for an applicant. Notably, this is the model that many recruitment agencies use, and it is not unusual to see fees at 20-25% of the new hire’s first year salary. Indeed could charge significantly less than that and still be highly profitable.
I’ve no doubt there are more. What pricing models would you propose? Drop me a note at james.wilton@monevate.com.
