Monetizing Product Integrations: Strategy and Execution

No software team builds a product integration for the fun of it. Integration is a crucial, often difficult, part of an overall product strategy that aims to deliver value to an end customer in exchange for revenue (ultimately profit).

If building integrations for your product isn't contributing to profitability, it's taking away from it.

Treating integrations as monetizeable features helps to ensure they contribute to your bottom line in a positive way. This post will cover approaches for monetizing integrations, including different revenue-increasing and cost-reducing strategies you can use.

Monetizing = Strategy + Execution

Monetizing your product integration program requires that have the right startegy. It also requires that you have the discipline to execute that strategy.

An ideal monetization strategy should align financial incentives between the partner software team, the end customers who will use the integration, and your team. Integrations have the potential to unlock a great deal of value for all three of those parties. This alignment around value delivery is where you'll find dollars.

The "strategy" part of this equation means finding the optimal way for each integration to hit your bottom line. It's likely that any given integration will implement multiple strategies, and that your integration program as a whole (all of your integrations) will implement similar strategies.

But, landing on the best approach is only part of the work. If you can't execute on that approach, you will not experience the positive financial impact.

To successfully monetize your integration program, you must implement a discipline for building and maintaining integrations cost-effectively and time-efficiently. Otherwise they add too much cost to your business to reap the financial benefits.

The rest of this post will cover some common ways companies monetize integrations. It'll also cover the basics of successful execution.

Integration Monetization Strategies

How do you make money with product integrations? This is the fundamental question.

There are three ways product integrations can impact your bottom line:

• Direct revenue strategies monetize an integration by treating it as a feature responsible for generating revenue without any other dependencies
• Indirect revenue strategies look at how the existence of an integration contributes to revenue generated elsewhere
• Cost reduction strategies consider how an integration helps you spend less money in service of your customers

All of these are valid approaches to monetizing an integration, and it's likely that a given integration actually impacts your bottom line in more than one way. Let's dive into some examples of each.

Direct Revenue Strategies

Direct strategies tend to be simplest to understand and implement, but they aren't necessarily optimal for improving financial outcomes. Put simply, direct revenue strategies mean charging for integrations, and many companies will struggle to remain competitive doing this.

But, there are multiple ways to directly charge for integration capabilities and they make sense in certain circumstances.

Charging for API Access

One way to monetize integration is to charge for API access.

Reminder: A product integration consists of two things--an API to allow data into and out of your product and some software somewhere that moves the data. That software could be proprietary code written into your product. It can be an embedded integration framework (our recommended approach for most companies), or it can be a third party iPaaS.

Whether the integration tech being used is something you own/control or something a third party does, you can charge for access to data through your API. Some common ways this is done include:

• Charging a very small amount for every individual request made to the API
• Charging for API calls on a tiered system, usually to reduce the "per call" amount as volume grows
• Selling prepaid batches of API calls
• Charging for elevated features like certain API endpoints or higher call limits

Regardless of approach, you receive dollars specifically based on someone using your integration. The more they use it, the more dollars you make. In this case, the math to decide what dollars are to be charged is based around the API itself.

Charging for Integration Features

Alternatively, you can charge for using the integration features. (The software that moves the data, not necessarily the API.)

This is what a third party iPaaS does: they charge your customer to use their software that moves data between your API and another. It doesn't have to be a third party charging those dollars to your customer. You can do it as well.

Consider these approaches:

• Charging for access to use an integration as a "premium" or "add-on" feature
• Charging for advanced configuration options on an integration
• Charging for additional capacity or faster data movement (e.g. once an hour for free, real-time for a fee)

Again, you are receiving dollars directly related to an integration being used. In this case, the math that calculates those dollars is not based on the API calls, but whether or how the integration is used.

Charging Integration Partner Fees

Another direct way to generate revenue based on integration capability is to charge partners for access to your integration program.

This is kind of like charging for API access, except you monetize via the partner and not the end customer. Access to APIs and/or integration features (to build their integration to you) are options. You can also charge fees to enroll in a program that allows them to be listed as an integration or for certification.

How "direct" you consider this varies, depending on the partner arrangement (including fees) and who actually owns and operates the integration tech. But, in simple terms, this is another top-line approach to monetizing.

Indirect Revenue Strategies

Integrations have a positive impact on revenue in indirect, often overlooked ways as well. Often times, this is where the biggest bang for the buck, in terms of ROI, can come from.

Attributed Sales Opportunity

For B2B and enterprise software companies, integration almost always comes up during the sales process. That's because your potential customer also uses a bunch of other software products to get their jobs done. The extent to which yours plays nicely with the rest of their stack is an important consideration.

That means the existence of (or lack of) a given integration can impact whether or not you're able to close a deal with that potential customer.

If you build a discipline of tracking what integrations are "must have" and "nice to have" requirements for customers, you can attribute some amount of the revenue those close customers generate for you to the "R" in the ROI for that integration. Likewise, you can calculate what the potential revenue opportunity is for a new integration by looking at how much of your sales pipeline it'll help you close.

This is not perfect science or GAAP accounting. It's modeling, based on imperfect information. But, if you aren't considering the revenue that an integration partially or completely enables, you aren't looking at the whole picture.

Attributed Referral Opportunity

For partners with whom you have an appropriate referral fee arrangement (often these are mutual), the existence of an integration can help you generate more of that referral revenue.

In this case, your customers effectively become leads for the partner. Your integration gives them a bridge to that customer. Haven't you ever browsed the marketplace for a foundational software application, like your CRM, to see what else they integrate to? This is classic lead generation.

It's maybe splitting hairs a bit, but this is different than charging your partner directly. In this case, you've enabled their growth as well and arrange to take a deserved cut of that success.

Referral revenue may seem like a small opportunity, but consider what it can be at scale. Take Shopify, for instance, which takes a 20-30% cut on integrated apps installed via it's App Store (effectively referrals via integrations) times over 2400 apps in the store.

Retained Revenue via Churn Reduction

An integration doesn't have to increase your revenue to have a positive impact on revenue. It can also prevent lost revenue.

For subscription based businesses, like SaaS, managed services, or retainer-based services businesses, it's especially important to retain customers. Your ability to retain customers, while adding more give you  economies of scale and an annuity-like revenue stream. For venture-backed companies, this is really important for valuation.

Every company loses customers--they go out of business, they no longer need you, etc. Your goal is to minimize this "churn" to protect as much revenue as possible. Assuming you've got new customers coming, your recurring revenue grows overall.

When you have integrations that your customers use, it makes them stickier. It makes it harder for them to rip your product out of their stack. People don't replace a working integration without a really good reason. Additionally, if you offer integrations to many of the possible solutions they may switch to for other reasons, you make it easier for them to stay with you.

This is somewhat a risk mitigation strategy, but you may actually have customers leaving you "because you lack x integration" in a measurable way. This positive impact on revenue, while protective instead of generative, should be considered part of your monetization strategy as well.

Cost Reducing Strategies

Your bottom line is about revenue generation and cost reduction. Integrations can help you with the latter as well.

We'll talk about two ways to do this: shortening time to value and creating operational efficiency.

Shorten Time to Value

For software products that require a heavy implementation, very common in enterprise and B2B software, "time to value" is an important metric. It represents how long it takes between the time a customer signs up for your product/service and when they begin to experience the value of it.

In simpler terms, this usually means measuring how long the implementation process takes.

Of all the requirements that can be part of an implementation, integration requirements tend to run the risk of doubling or tripling your implementation time. This creates a bad experience for your customer, potentially causing early churn. It also probably costs you money. Factor in both the added expense of dealing with overrun implementations and the lost revenue for those that churn, and you can see what time to value is important.

Having integrations available to the systems your customers need to integrate to speeds up the process, compared having to deal with integration requirements as one-offs. Making sure those integrations work well and provide adequate configuration options does as well.

Improve Operational Efficiency

Not all product integrations have to be customer facing (though most will be). You can also build integrations to/from your product to create operational efficiency within your company.

Automating cumbersome, repetitive, and error-prone tasks reduces the overhead for the business. Do you really want to export your sign-ups into your CRM manually all the time? Do you want to real a database report to bill a customer based on their usage?

How you achieve operational efficiencies with integration really depends on your business, but this cost reduction opportunity is probably there.

Executing a Product Integration Program

Good strategy without execution is nothing more than a "good idea". In order to wield that strategy for financial benefit, you must have a discipline around execution. You have to put boots on the ground.

There is a lot that goes into a successful integration program. Start here.

The goal with execution is achieving the following, all in service of minimizing the cost and risk that go into your integration program while maximizing its revenue potential.

Build integrations faster.

Faster means two things that generally correlate: fewer hours and fewer calendar days. Building integrations faster increases your engineering capacity so that you can either get more integrations into the market or you can use that engineering capacity elsewhere.

The best ways to increase your integration velocity are:

• Leverage technology that requires less work to get "up and running", usually compared to writing custom code
• Standardize your design and specification approach so engineers get clear, consistent instructions about what to build
• Align key requirements stakeholders in your requirements gathering process to make sure there is minimal rework or misunderstandings

Faster integration development (without sacrificing quality) has a huge impact on the bottom line, especially in subscription businesses, because the revenue benefit compounds.

Build integrations more easily.

Without help, building software integrations is difficult work. It's a highly technical engineering challenge, because you have to know how to architect a system that can move large amounts of critical data securely, reliably, and quickly. It's also a business challenge, because you have to map between business outcomes and esoteric technology deliverables.

Difficult, technical work requires senior people...usually senior level software engineers. And, those are the folks on your team who have the most work on their plate, the most recruiters hounding them about other jobs, some of the highest paid, and who (if your company builds software) are the most critical to achieving your goals.

The easier you make the process of defining and building integrations, the less you need to rely on high experience techincal people on your team. Moving to lower cost resources reduces the labor cost factored into the integration and frees up that high value resource for bigger, ideally revenue-generating projects.

Build the correct integrations.

If you deploy an integration that nobody uses, does anyone hear it?

If few people take advantage of an integration you've built, it makes it very difficult to achieve the ROI to consider it a success. You need that "R" (return) to exceed the "I" (investment) times 5 or 10. Otherwise, why bother?

Some common traps teams fall into include:

• Building a bespoke integration that serves exactly one customer
• Building an integration that many customers want, but with basic functionality that doesn't get them all the way there
• Building integrations independent of market demand, hoping that if you build it they will come

Your product integration program should build discipline around finding strategically beneficial integration opportunities and triaging them. Then it should help you work with product managers, the partner company, and your engineering team to understand what an integration will provide a customer that is valuable,

Build reliable integrations.

Moving a small amount of data from one API to another isn't really that hard. Doing it at scale is.

Let's do some quick math. Let's say you offer 12 integrations in your product. Each of those 12 integrations has 2 data flows (one with data coming in, one with data going out)--the details aren't important. Each integration has 100 users and each user uses that integration to facilitate 100 records in/out per day.

That's 240,000 instances of your integration moving data to or from your API every day. And, these are hardly "at scale" numbers.

What happens when a customer calls you to ask why their record didn't sync through the integration? Can you find which of those 240,000 transactions is the failed one that they asked you about? If you do find it, do you have visibility about what happened? Now, imagine if you had 10x, 100x, or 1,000x the volume.

This highlights how important it is to build integrations that:

• Minimize negative outcomes like failures or errors; zero is not possible, so...
• Reliably notify your team about failures so they be proactively addressed
• Provide mechanisms to address issues; when you find one, you need a way out
• Scale intelligently to meet demand needs without burdening you financially

This is a huge topic. Not building reliable integrations can explode the labor cost you put into simply maintaining those integrations. Technical debt is expensive.

Build aligned integrations.

When you build an integration to another product, like it or not, you now have some amount of a relationship with that product's company.

It doesn't have to be a close one. Your relationship may be through their API documentation and publicly accessible developer accounts. But, it's there and usually worth pursuing further.

The most successful integration projects are ones built within a collaborative relationship between two partners. Those partners identify market opportunity by providing a cross-product experience that is more valuable than the sum of its parts. These integrations are aligned.

This why the partnership team's involvement in integrations is so important. Remember, integration is not just an engineering task. The partner team acting as "voice of the partner", contributing to the design and development of an integration increases its odds for success--usually in terms of hitting revenue goals.

And, at the end of the day, that's what we all want.

Bonus Video

Check out our CEO Ryan's presentation to the Cloud Software Association covering all of this and more.