How to Determine ROI for B2B SaaS Integrations

When you consider adding functionality to your SaaS product, you probably ask questions such as "What's our ROI if we develop this feature?" or "How soon can I realize a positive ROI from these changes?"

And that makes sense. ROI (return on investment) is a metric that allows you to determine whether making certain investments in your SaaS product is a wise financial decision. There are many ways that investments in your product may yield a positive ROI, including increased sales, new upsell opportunities, improved customer retention, lower costs, or a combination of these.

If you run the numbers and it takes 10 or 20 years to get back your initial investment in adding new functionality, the project isn't going to happen. But if your calculations say the work will pay for itself in the next 3 months, the rest is working out the details.

The good news is that B2B SaaS integrations can provide a substantial ROI while giving you a competitive advantage. At the same time, numerous factors will impact the ultimate ROI of your integration strategy, not the least of which is whether you are using an integration platform or building integrations in the traditional way.

But before discussing the details of B2B SaaS integration ROI, let's examine up-front and ongoing integration costs and revenue drivers.

Cost of building, deploying, and supporting SaaS integrations

Actual integration costs will vary based on many factors, but we can get a pretty good idea of the general cost categories and what goes into each. And these costs are a key driver of your ultimate ROI. Here they are:

• Dev costs – In many cases, development will be the most significant contributor to your integration costs. Most of these come early in the process, from the point where devs are working with customers and tech partners to define requirements, through initial development and testing to get to an MVP, and then continue with revisions (keeping up with API changes, adding new functionality, addressing tech debt, etc.) over the life of the integration.
• Sales/Marketing costs – These costs often come from building and publishing content on your website, via ads (Google, Bing, LinkedIn, etc.), and events such as webinars and trade shows. In addition, some of the costs of building an integration marketplace (or other means of showcasing your integration products) could fall under sales/marketing.
• Onboarding costs – These are borne mainly by your onboarding/implementation team. They are in addition to the onboarding required by your core product. Depending on how technical the onboarding process is, your devs may also contribute to integration onboarding costs.
• Support costs – Integration support costs will be tied to your support team. As with onboarding costs, the specific roles that drive these costs may be support team members or others (such as devs) who need to handle the more technical support aspects.
• Third-party costs – The range of third-party costs can be broad. They may include development and testing tools, API subscription fees, cloud hosting fees, and integration platform fees. They could also include paying consultants to help with integrations, from planning to development to deployment and support.
• Opportunity costs – Though indirect, opportunity costs are a factor. In particular, opportunity costs can quickly accrue for devs who spend much of their time building, deploying, and supporting integrations instead of building core product functionality.

Revenue from B2B SaaS integrations

Depending on your market position, you may not be able to charge customers directly for your B2B SaaS integrations. We've written a post on pricing integrations that explains why that is often the case and addresses situations where charging for integrations does make sense.

Whether you directly charge for integrations or charge more for your core product, having SaaS integrations for your customers drives greater recurring revenue. An existing library of integrations allows your product to solve more customer use cases and captures market share from competitors who do not provide integrations to their customers.

When you can answer more prospect questions with existing integrations (or demonstrate that you can provide future integrations), this tends to shrink the time prospects spend in the sales cycle and increase win rates (as fewer prospects will disqualify you for failing to meet their unique use case), driving more ARR growth in less time than if you didn't have integrations.

In addition, providing integrations along with your product (allowing your customers to connect your product to the other apps they use) will help your gross revenue retention (GRR) and net revenue retention (NRR). This comes about because your integration becomes embedded in your customer's ecosystem, leading to less friction in using your product and a better user experience for your customers. It ultimately makes it harder for your customer to move off your product as it feeds many parts of your customer's ecosystem.

See how Sisu increased revenue per subscription by 5x by implementing our embedded iPaaS for integrations.

B2B SaaS integration ROI context

We mentioned up front that the context in which you are building, deploying, and supporting your B2B SaaS integrations greatly impacts the ROI of your integration strategy.

In general, B2B SaaS integrations can be built in one of two ways: either from scratch by having your dev team write custom code (the traditional way) or by leveraging an integration platform.

Integration platforms can be grouped as follows:

• Workflow automation
• Enterprise iPaaS
• Unified API
• Embedded iPaaS

Since we are an embedded iPaaS vendor, we are not going into the details here of using workflow automation, an enterprise iPaaS, or a unified API to build B2B SaaS integrations for your customers. Follow the above links to see how an embedded iPaaS compares to those platforms.

However, we will compare and contrast the ROI of building, deploying, and supporting integrations using the traditional approach vs an embedded iPaaS.

ROI for SaaS integrations built the traditional way

With traditional integration development, developers need to build the integrations and the infrastructure to run them. Our post on building an integration isn't the hard part has more info on the pieces of the integration puzzle.

Devs need to do most of the work

In general, you'll be looking at a large upfront investment for your integrations, often 3 to 6 months of dev time for a single integration, and even longer if the integration needs to be copied and customized for multiple customers. At a current average dev salary of $140K/year plus benefits, it'll be several years, if ever, before you realize a positive ROI unless your customers pay a substantial premium for the integration.

At the same time, since the devs are spending months working on integrations, you'll need to hire more devs to work on your core product, or drastically simplify your core product roadmap to account for the loss of dev resources. While not captured in a simple ROI calculation, the opportunity cost of deferring core product development can be monumental in the fast-changing world of B2B SaaS, especially when your competitors are not forced to make the same trade-off.

Customer experience is not a priority

Having integrations available for your product will make it more attractive to prospects, but the relatively long integration development cycle won't shorten your onboarding time for new integrations. If a prospect needs a new integration with your product, they'll have to wait months after initial onboarding before the integration is ready. This will negatively affect ROI. Or even worse, the prospect may opt for another solution rather than wait months for an integration they expect to exist upfront.

Given the dev costs of building integrations the traditional way, most integrations will not have a user-facing UI, a customer dashboard for statuses, or even an integration marketplace.

Unfortunately, leaving these types of features out of integrations means that almost all integration onboarding and support must be handled by devs since they'll be the only ones with access to the integration. Your ROI moves even farther away as you add onboarding and support time to the original development time.

Requires third-party resources

Even if you do everything you can to build integrations in-house, it's nearly impossible these days to avoid using third-party resources. These can include hosting, infrastructure, tools, and anything else needed from outside your company to make the integrations work.

In short, building integrations the traditional way uses much more time, ties up some of your most valuable team members (devs), and leaves you with something requiring substantial ongoing dev involvement. As a result, this approach has relatively high costs if done in the manner necessary to drive increased recurring revenue, meaning that a positive ROI using this approach often takes far longer to achieve, and the ultimate ROI is much smaller than anticipated.

ROI for SaaS integrations built with embedded iPaaS

Bringing an embedded iPaaS in to build, deploy, and support your integrations will yield a much better ROI than building them the traditional way.

Substantially reduce dev effort

As noted above, your devs are usually the most significant resource for building integrations. However, using an embedded iPaaS can reduce dev effort by 80%.

The time saved includes the time the devs don't need to spend building and maintaining the infrastructure for the integrations and how much faster they can develop using our code-native integration SDK. If your use case supports it, you can even move traditional integration building tasks to non-devs who can use our low-code designer.

The bottom line is that you'll be able to build and deploy integrations in a fraction of the time it previously took to do everything by hand. This allows you to reach a positive integration ROI that much faster.

Third-party costs go up, but infrastructure is handled

Yes, you'll have the third-party cost of the embedded iPaaS to factor in, but that is a fraction of the cost of a full-time developer. Since you won't need to hire more devs but will instead use your devs and non-devs more efficiently, future integration cost projections will become simpler. Given that you'll be spending a consistently lower amount of cash on integrations, that'll positively impact your operating cash flow.

Having an embedded iPaaS facilitate integrations for your product means that your embedded iPaaS vendor handles the infrastructure, reducing the integration burden on your support team. This should also help your gross margin and help you achieve your ROI faster.

We discussed how heavily devs are involved in integrations built in the traditional way. That dynamic changes a lot with an embedded iPaaS because onboarding and support can be handled by non-devs in most cases, leaving only the most technical issues for devs. In general, your non-devs costs are substantially less per employee, leading to less outlay for integration onboarding and support when using an embedded iPaaS. And there's less support burden overall since an embedded integration platform is inherently more stable than a custom-built one. Fewer ongoing integration expenses lead to a better ROI.

To see how much time you can save for your devs, check out our ROI calculator.

Customer experience improves for product and integrations

While you may still have developers involved with your integration process, they'll have more time than would otherwise be available to work on your core product. As a result, you'll be able to keep your core product roadmap moving ahead instead of delaying or canceling functionality to keep up with your integration backlog. This is not a direct integration ROI, but it can boost your product's overall ROI.

As with building integrations the traditional way, using an embedded iPaaS allows you to have integrations available for prospects and prove that you can create the additional integrations they need. This leads to faster sales cycles and less sales friction.

There is also the common benefit of having customers use your integrations. This means they use your product more, which means they get more value from it. The product becomes more entrenched in their workflows. This results in increased customer retention since the more value they receive, the less likely they are to pull up stakes and leave for another product.

Another benefit of an embedded iPaaS is its integration marketplace, which lets you list all available integrations for prospects and customers. Your customers can sort, select, activate, and even troubleshoot their own integrations via the marketplace. Again, less load on your support team leads to lower ongoing expenses, which helps your ROI.

The sooner you build…

The sooner you can realize the ROI your SaaS integrations can provide.

While the above data suggests that simply adding integrations to your SaaS product can provide value, it also clearly shows that using an embedded iPaaS results in a faster, more consistent, and greater ROI than building, deploying, and supporting integrations using entirely home-grown custom code.

Without wanting to sound trite, using the traditional approach to building your SaaS integrations when we now have powerful embedded integration platforms such as Prismatic looks like reinventing the wheel. You can do it, but should you?

Schedule a demo if you'd like to see how our embedded iPaaS can help you and your team supercharge your integration ROI. We'll be happy to show you how you can grow your ARR and NRR and reduce customer churn while staying ahead of the competition.