Best Practices in B2B SaaS Tech Partnership Monetization Models - Part 3

Best Practices in B2B SaaS Tech Partnership Monetization Models - Part 3

Dylan Charles 5 min

This is the third article in the series that focuses on best practice tech partnership monetization models we’ve observed in marketing. Here is part 1 and part 2.


The goal of this series is to look more deeply into the topic of tech partnerships, building on a series of conversations Allan Adler had with Avanish Sahai on Tidemark’s The Platform Journey podcast: Part 2 - Monetizing Technology Partner Ecosystems.




The models

In this article, we take a quick look at the three primary tech partnership monetization models and explore the importance of NRR, ARR, and stickiness. 


We think about monetization in terms of 3 primary models:




  1. Revenue Share. At Salesforce, they have a whole bunch of customers and companies that have built on their platform, and the agreement is, “I’ll set up a marketplace, and I’ll essentially charge a tax.” They take 20% of a partner’s ARR in exchange for accessing their customer base. This model is pervasive in SaaS companies. But there are a lot of questions right now on what the value is of that rev share, and how it can truly be aligned with the value that’s being delivered (or not).
  2. Reciprocity. This is a simple exchange based on the agreement that “I’ll give you some of my customer leads if you give me some of yours.” This drives a reciprocity flywheel, focused on stimulating outbound and inbound referral processes.
  3. “Mutuality” - This is a priority for companies like Snowflake or Databricks. It’s driven by an implicit agreement that says, “If we can get you to consume data on our platform, we will have our sales reps bring you into our customers.”
  4. This approach doesn’t rely on rev share directly, but rather a consumption model that drives sales reps to relieve quota based on consumption. This is what the hyperscalers do. The approach also depends on a marketplace and in some instances, particularly with the hyperscalers, a customer can offset 25% of their total spend on the ISV solutions that are sold through them.


Each of these has pros and cons—it all depends on how you execute them.


All these different commercial models are figuring out how to add value to the customer and how to grow the pie. They also depend on the core economic model of the platform provider.


Let’s again use Salesforce or even ServiceNow as an example. They usually sell based on user, a different approach from selling infrastructure based on capacity or consumption. Understanding the root framework or model is pretty critical to understanding how to engage.  


It’s also interesting to see, too, that some folks who start with a rev share model abandon it. For a while, the hyperscalers followed the same script as Salesforce and others by charging 20% for referrals.


They eventually figured out that if they could get an ISV to drive consumption of their pipe, they didn’t want to charge a rev share, but instead to actually give all the money back and only keep something like a 3% administrative fee, and instead 97% back to the tech partner, because the tech partner is driving a lot of consumption. This then drives their own NRR or net retained revenue.




The role of NRR and ARR

Most technology companies, whether they’re infrastructure as a service or software as a service, typically focus on some variation of ARR and NRR. ARR represents net new revenue, and NRR (net retained revenue), and these two variables typically drive almost all their business decision-making.


But the monetization model is quite different from this focus, either based on the number of users or in other cases, on data or CPU capacity. At the end of the day, the CRO and the CFO are trying to find the magic multiplier, the variable that drives the business model.


This is the magic — companies can make that multiplier significantly bigger or better by rewarding their tech partners and the ecosystem for participating in the dance. That’s really what monetization of tech partnerships is all about.




The “stickiness” factor

There’s no better financial justification for attempting to monetize tech partnerships than the stickiness factor. In fact, data shows consistently doubling and tripling retention rates when the number of integration partners goes north of three, four, five. This makes sense, because as soon as the customer has connected four or five technologies to a company’s offering, they become an embedded stack.


They aren’t dispensable anymore. To rip them out means screwing up five or six different data flows, five or six different work processes. That just isn’t going to happen. 


Another data point that is really interesting, is a study ProfitWell did a couple of years back showing that not only do you get more stickiness, but you actually get growth in NRR, because the integrations produce a need for greater utilization of your product, additional features, more consumption, more users, whatever variable it is. Not only is there a magic lowering of churn, but also the magic of growing NRR. 


Putting those two together is a moment when a CFO has to ask, “How come we’re not doing that at scale?” Strangely, CFOs are very, very resistant to it in the beginning, because they see it as a long-term investment.


There are a lot of costs involved. But when it starts happening, the switch flips, and everyone asks, “Why are we not doing more?”




Next time: Some examples

There are some great examples for each of these monetization models and each comes with its own opportunities and challenges. We’ll explore these in our next article in the series.


Prefer to listen? Subscribe to our PartnerHacker Audio Articles Podcast. Text-to-speech provided by our partner Voicemaker.in.

Dylan Charles 5 min

Best Practices in B2B SaaS Tech Partnership Monetization Models - Part 3


We take a quick look at the three primary tech partnership monetization models and explore the importance of NRR, ARR, and stickiness.


You Might Also Like

X

This is a test comment.

X

This is a longer test comment to see how this looks if the person decides to ramble a bit. So they're rambling and rambling and then they even lorem ipsum.