Integration Pricing Strategies - Levers for Growth

Whether it’s through unlocking new product functionality or improving feature adoption and reducing friction around product usage, integrations have become a central part of how SaaS applications deliver value in the current product-led environment. 

What’s evidently unclear to most companies is how to price those integrations appropriately. Do you gate all the enterprise integrations in one single tier that’s geared towards your largest customers, or provide them to all users out of the box? Do you provide a progressively larger number of integrations each time your customer upgrades to a new pricing tier? Or do you allow companies to purchase individual integrations a la carte to match their unique use cases?

Getting integration pricing right will have enormous downstream impact on your monthly recurring revenue (MRR), across net new customer acquisition and your ability to upsell existing customers.

In this article, we’ll share with you the framework and best practices for building the optimal integration pricing model for your SaaS.

TL;DR

• Too many businesses see integrations as optional add-ons, and price them as such - it’s crucial to approach integrations the same way as you do core product features. 

• Value-based pricing is key - you’ll need to determine the value of your integrations to your user base, and price on that basis. These insights will also give you insights about the ROI of your integrations and where you can upsell integrations.

• There are 3 levels of tier-based pricing for integrations - from integration volume per tier to tiering down to the integration feature/workflow level

• A-la-carte pricing can be incorporated across both tier and usage based pricing models - this can sometimes be helpful in cases where customers are unwilling to upgrade just for one integration

Why do you need a robust integration pricing strategy?

Building an integration pricing strategy is valuable first and foremost because integrations are themselves valuable. We’ve written many times before about why more SaaS companies should prioritize integrations, but here’s a quick recap:

• Integrations are one of the top requirements for SaaS buyers - the more integrations you offer, the easier it will become for new customers to adopt your product and the more likely you will be to winning deals against to competitors

• For existing customers, integrations reduce churn due to higher product stickiness from delivering constant value across their day to day workflows

• The more tightly integrated your product is with the rest of your customers’ tech stack, the more efficient their workflows will be - this could amount to days saved per week from manually processing and importing/exporting data between platforms

• Integrations can unlock net new value, use cases, and insights from your product that would not be possible with any application in isolation

Pricing is the gateway for enabling you to capture the value these integrations create - but how do you determine how to price/tier out your integrations?

There are two sides to a good deal: the price paid by the customer, and the amount of value your integrations provide, aka the benefit-cost ratio.

Price/tier your integrations too high and your customer will try to live without it or worse, churn from frustration.

But price/tier them too low, and you’ll be wasting the perfect customer expansion lever.

Given how essential integrations are to the SaaS business model, there are few pricing decisions that will matter more to your business.

Integration pricing model considerations

Despite the importance of integrations, there are many companies that aren’t doing a good job of incorporating integrations into their pricing. Given that we’re in the embedded iPaaS space, we’ve talked to lots of SaaS teams that see integrations as optional add-ons, as opposed to a core part of their product, and this shows in the way they approach pricing. 

Before we get into the pricing models themselves, here are some considerations to keep in mind:

1. Not all integrations are equally valuable - the amount of value (whether it be time saved, insights gained, or functionality enabled) that they derive from various integrations can be very different

2. One integration can have multiple integration features/functionality - similar to how a product line can have multiple features within it

3. The customers that demand different integrations within the same product category can have very different firmographics - for example, while they are both accounting platforms, Netsuite is used by enterprises while QuickBooks is used by small businesses

4. Especially in Product led growth (PLG) models, if an integration makes your product significantly stickier, don’t gatekeep it from users.

Now that you have those in mind, we’ll dive into the various pricing models, from common practices that we recommend against, to best practices that we rarely see.

The 4 levels of tier-based pricing

If your product offers tier-based pricing, you would have to align your integrations with specific product tiers/packages in one of the 4 methods below.

Pay special attention to the third one, which is the least common but the one we highly recommend.

Level 1: Tier by Number of Integrations

The most straightforward way to price out your integrations is to allow a set number of integrations per tier.

The more the customer is willing to pay, the more integrations they get access to.

For example, your cheapest package might come with no integrations, your middle tier with 5 integrations, and your enterprise offer with 15. 

We see this approach used a lot because of its simplicity, but we do not recommend it.

After all, not all integrations deliver equal value.

A Slack integration that provides a simple notification should not be interchangeable (pricing wise) with bi-directional syncs between your app and your customers’ systems of record, be it a CRM or an accounting platform. 

Level 2: Tier by Integration User’s Purchasing Power

Integrations can serve as a proxy for the segment that specific customers are in.

Here are a few examples:

Accounting:

• SMBs use QuickBooks

• Enterprise companies use Netsuite

CRM:

• SMBs use Pipedrive

• Mid-market/Enterprise companies use Salesforce

Marketing Automation

• SMBs use MailChimp

• Mid-market Enterprise companies use Marketo

With this second model, you would place integrations that are more likely to be used by larger companies into higher pricing tiers. However, unless you have a truly widespread customer base, with very different customer segments from an ability to pay perspective, this does not work well.

Using the CRM example, despite the perception of Salesforce being focused on the enterprise segment, they have a significant customer base on their non-enterprise plans that are similar in price to HubSpot. Yet HubSpot integrations are often seen in lower pricing tiers. Here are 2 examples of this in action:

Source: calendly.com

Source: hopin.com

While this is the most common pricing strategy we’ve seen, it is suboptimal because:

• There is generally overlap between the customer segments that want the different integrations within that category. This model drives away prospects that cannot afford paying for the higher tier just for the integration

• It will frustrate and potentially be a turn off for prospects as they know the 2 integrations have the same functionality and provide the same value, but you are forcing them into the higher package

Level 3: Tier by integration category value

Now we’re getting closer to value-based integration pricing.

Generally, categories of integrations naturally fall into buckets based on usefulness.

For example, in general CRM, accounting/ERP, or HRIS integrations that provide end-users bi-directional syncs would be considered as much more valuable than a Slack integration that sends a notification.

As such, you could group categories of integrations into tiers based on the value they add.

In this example with Productboard, they’ve grouped communications integrations into their Pro tier, and product analytics integrations into the Enterprise tier. This is because the product analytics integrations provide immensely valuable insight that no other product in their category provides, whereas the communications integrations offer relatively simple functionality.

There are just 2 downsides here:

1. You may have multiple features within one integration, and this model does not allow you to split out those features into separate tiers

2. If you know a specific integration feature has measurable impact on your users’ retention, excluding that integration from lower tiers means you lose out on a product stickiness lever

This is where Level 4 comes in.

Level 4: Tier by integration feature/usage

This is our recommended strategy, and can be used in combination with Level 3 for integrations that only have one use case, or a set of extremely simple use cases.

In this approach, instead of looking at integrations as a singular feature, you would create multiple tiers of value within each integration, whether that be via integration usage or via multiple integration features (or workflows as we call it).

Usage based tiering within an integration

Usage based tiering enables you to provide all your customers the benefits of an integration, regardless of the tier they are on.

However, because usage volume generally correlates closely with the scale of your customers’ companies, you can leverage that as a way to upsell customers within an integration.

For example, let’s say all your customers need a Salesforce bi-directional sync integration out of the gate, as it is a crucial feature that enables your customers to get value of your core product (and inherently makes your product stickier). 

You could offer that bi-directional feature to all your customers, but set limits within each tier on usage.

This could look like:

• The startup plan could provide up to 1000 synced contacts/10,000 API calls per month

• The enterprise plan could provide up to 100,000 synced contacts/1 million API calls per month.

This not only aligns much more with the value that is being provided within a single integration, it gives all your customers access to the feature but scales appropriately as they grow.

Integration workflow/feature based tiering

If you offer multiple features/workflows within a single integration, you could split them out into various tiers based on the complexity/value of that integration feature.

Continuing with the Salesforce integration example:

• The startup plan could provide standard bi-directional syncing capabilities

• The enterprise plan could provide automated lead routing functionality, which is often not a necessity for companies until they reach a certain scale

With this final level, customers will not only be able to get the features they need for their given stage within an integration, it makes upselling for additional features and value much more seamless and justifiable. This means you will be able to capture revenue at every stage of your customers’ growth, instead of leaving money on the table by over/undervaluing the significance of your own integrations.

This is value-based pricing par excellence. Having an ‘integrations as product’ mindset is required for this final approach, which is why it’s not a coincidence that this type of pricing looks very similar to how many you should price the features of your core product.

Thankfully, more and more companies are finally seeing integrations as a core part of their offering, not as an optional add-on - this simply applies that mindset towards pricing.

One of the few times we’ve seen this being used in practice happens to be Productboard. In Level 3, we highlighted how they split out most of their integrations by category. Well, they also apply Level 4 thinking to 2 of their integrations, Jira & Azure DevOps.

‍

A-la-carte pricing

Now, sometimes you may find that customers wants to use an integration from a higher pricing tier, but can never justify upgrading their subscription as a whole, since that particular integration feature is the only feature from the higher tier that they actually want to use.

If you are unable to sell them on the rest of the package (similar to how Intercom’s pricing jumps 2x between tiers), it may make sense to provide the option of a-la-carte integration pricing.

Since we rarely see this in practice, to make it more tangible, here’s a personal example where A la carte pricing would’ve benefited Salesforce.

The Missed Opportunity

So we currently use Calendly for our demo form, because we want to make it easy for you to find time with us to see how Paragon can accelerate your integration roadmap.

Once you book, we would add you to our Salesforce CRM. However, to get the native Calendly x Salesforce integration feature, we would need to upgrade our Salesforce package to the next tier, which costs more than double what we are currently paying.

So instead of upgrading, I had no choice but to go over to Zapier so I can pay for, set up, and maintain my own Calendly and Salesforce integration (which has been the bain of my existence).

If Salesforce had provided an a la carte price for the Calendly integration that was as much as half the price increase to the next tier,, I would’ve gladly bought the native integration to save myself the pain of using Zapier.

So to bring this back to your product - it is likely that you have customers who would be willing to pay hundreds of dollars more every month for a native integration, but don’t have the option to. That’s money left on the table that’s up for grabs.

Implementing these integration pricing strategies

So where do you go from here if you want to roll out a revenue-maximizing integration pricing for your SaaS business?

You’ll need to get insight into the perceived value of your integration features, and your customers’ willingness to pay for those features.

This can be achieved by talking to your customers directly, by leveraging data that your customer-facing teams are collecting from their touchpoints with your customers, and most importantly, by experimenting with different pricing implementations.

Considerations to keep in mind:

1. Is an integration sufficient to get a customer to upgrade their plan?

2. What value do customers see in the integration, and what would they be willing to pay to get that feature back if you were to remove it?

3. What are the different ways you can upsell within a single integration?

4. What are proxy measures that correlate to the value add that an integration feature delivers to a customer?

5. What ROI does each integration feature have on customer retention or core metrics such as DAU? The higher the impact on your core growth metrics, the more incentive there is for you to lower the entry point.

By doing this research thoroughly, you’ll start to discover the levers where you can upsell customers on new integration features, or alternatively, where it makes sense to give an integration feature to every user.

Conclusion

There are many ways to price your integrations, with some being significantly more effective than others. It’s important to determine the unique value of your integrations to your customers and strategically leverage that insight to create pricing levers.

Treat pricing integrations with the same level of thoughtfulness as you do for your core product lines, be it tier based, usage based, or feature based, and you’ll be much closer to maximizing your ability to monetize the value of those integrations that you’ve spent months of engineering on. 

If you’re looking to create more upsell levers, unlock new product value, and improve customer retention, accelerating your integration roadmap is key.

But building integrations in-house is not only distracting, it is not the best use of your engineering team’s time. To see how you can help them offload 70% of engineering effort surround every integration with Paragon’s embedded iPaaS solution, book a demo here.