As the number of SaaS companies has continued to skyrocket, integrations have become increasingly important to the user experience. A study of the 1000 fastest growing SaaS companies revealed such companies have a median of 15 integrations, and an average of 98 integrations.

As companies build more integrations and seek to attract partners who will build integrations into their product, technology partner programs have continued to proliferate and mature.

If you look at the 10 largest SaaS companies and the 5 leading cloud providers, 14 out of the 15 have mature technology partnership programs and an active ecosystem of hundreds or thousands of integrated products.

These integrations are listed in integration marketplaces that drive revenue for both the platform and their partners. Forrester predicts that by 2023, 17 percent
of B2B purchasing will go through online marketplaces. This is a trend that has only been accelerated by COVID-19, as it has forced businesses to move more of their operations to the cloud, and reduced the role of in-person sales.

Creating a ton of integrations in itself is not a strategy for growing a business (trust us, we’ve seen it). So how do these technology partnerships result in revenue? Monetization strategies for technology partnerships are not as clear cut and established as the monetization practices around channel partnerships such as resellers, system integrators, or referral partners.

After meticulously documenting the monetization terms of 50 leading SaaS and cloud platforms and talking to hundreds of smaller SasS companies, we discovered there are eight main tactics to monetizing tech partnerships:

1. Revenue sharing
2. Charging partners a flat fee
3. Charging partners for API usage
   
4. Requiring the partner provide referrals
5. Requiring the partner purchase services
6. Selling the partner related services or referrals
   
7. Requiring the partner engage in activities that have a clear monetary value
8. Charging customers to use the integrations
   

Not all tactics will work for every company, and generally as a company shifts from a smaller, more specialized company to a larger platform company, they will change the way they monetize their tech partnerships.

In this article, we will cover the benefits and drawbacks of each approach, and explain what it looks like. In addition, we will identify which elements affect what you can charge your partners, and the typical monetization model for larger, pillar companies and for smaller ones.

What to Assess When Monetizing Technology Partnerships

Technology partnerships are unique in how they create revenue for an organization. Like other partnerships, they can drive direct revenue, influence deals, and underpin co-marketing and co-selling activities. But they can also enhance the product and improve the user experience.

Ultimately, a better product experience should drive revenue through retention, upsells, and increased brand equity, but those are not immediately evident and can be tougher to track.

The structure of monetization for a technology program will vary depending on how much an organization sees technology partnerships as a vehicle to drive revenue in the short-term and how much they see them as a vehicle to improve the product.

After an organization prioritizes their own objectives, it has to evaluate its own role in the tech ecosystem to understand how partners will calculate the value of a partnership.

How many companies want to build integrations into your product? How eager are companies to form a partnership? What resources are you providing to make it easier for them to integrate and to sell the integration?

While inbound demand for tech partnerships can be a strong indicator of interest (and partners building integrations into your product even stronger), there are five key factors to examine in assessing how much value partners will perceive in forming a tech partnership with you.

1. How many customers do you have and how large are the customers? One hundred Fortune 500 customers are worth significantly more than 100 small business customers.
   
   
2. Given your product and customer, how big is the universe of companies who might want to integrate with your product? What is the average deal size for these companies? The number of companies who want to integrate with a NoSQL database company, for example, will be fewer than the number of companies who want to integrate with a CRM, even if their customer bases, at the account level, are identical.
   
   Your partners’ potential deal sizes matter, too, because if it is small, they might have a diminished motivation to build and support an integration. Answer this question by account mapping with a tool like Crossbeam, and then assessing your potential use cases. You might be a small company, for example, but if you have a truly innovative solution that enhances many other companies’ products in a distinct way, you will have more partners looking to integrate with you.
   
   
3. Is your product a “hub” or a “spoke”? A hub is a piece of software that plays a central role in the users’ tech stack. For a sales person, for example, this would be a CRM. Products might be both with respect to different sets of companies. A survey tool, for example, would tend to be a spoke as users seek to have the results go into their CRM, marketing automation, or marketing research platform. However, for digital gift giving companies or video or animation tools, the survey tool might be a hub. And a real estate CRM might have relatively few customers, but it might be the hub for companies who sell software to real estate agents.
   
   
4. How much brand equity do you have? If your brand is popular and attracts fervent followers, partners will be more eager to form a relationship with you. In particular, how many potential partner companies are drawn to your brand and align with your messaging?
   
   
5. What are you offering to support third party developers and the marketing, sales, and support of integrations? If you have great API docs, responsive tech support, and active developer forums, it is going to be much easier for partners to build with you. Clear program policies, strong marketing and sales assets, and good customer, technical, and partner support will also make your company more desirable to partners. Business support is relevant for all partner programs, but technology partnerships are distinct in that technical support and technological infrastructure play a key role.

The larger and more valuable your customer base, the more companies who would be interested in integrating with you, the more you are a hub, the more brand equity you have, and the better developer and partner experience you have to offer, the more you are going to be able to extract revenue from your technology partnerships.

The 8 Different Ways to Monetize

When most companies start out, they do not directly monetize their technology partnerships. Usually, they build integrations into larger companies and pay the larger company fees or a revenue share to do so.

As companies grow along the five criteria of desirability (from above) and mature their programs, they begin to monetize. Most companies deploy more than one tactic, depending on their business objectives and goals. In the beginning, many stick to custom agreements as they try to get a better sense of their role in the ecosystem and experiment with pricing.

Some product-focused companies like Slack and Hubspot choose not to monetize their technology partner programs, even when they could easily do so.

This reflects a long-term strategy to improve the product and user experience, and increase customer retention by attracting more third party developers to build into the platform. Slack found, for example, that 95 percent
of their users believe that integrations make for a better user experience.

A key part of Slack’s strategy in trying to win market share against its competitor Microsoft Teams is to develop a robust ecosystem around its platform. Not only does Slack invest in supporting third party developers through good API docs and free technical support, it created an 80 million dollar fund to invest in technology partners.

Slack and Hubspot are both unusual in the strength of their product-driven approach. The vast majority of large, robust ecosystems do monetize their technology partnerships, and find ways to continue to incentivize third party developers while still extracting revenue from the relationship.

Here are the 8 tactics companies use.

Tactic #1: Revenue Sharing

A common way for mature technology partnership programs to monetize their partnerships is by charging a revenue share of any deals the partner closes through their marketplace.

Some companies take a revenue share of the integration itself, while others charge for the subscription to the app being integrated to.

For example, Atlassian requires all partners with public cloud apps to list their integration app in their marketplace and have Atlassian process the purchase of the app. Atlassian then remits the partner’s share of these sales (85 percent) to their bank account through an electronic bank transfer at monthly intervals.

Similarly, app partners in the Shopify App Store must use the Shopify Billing API to charge customers for their app. The partner then receives 80 percent of any sales.

Of 36 leading platform companies, 50 percent of them require a revenue share. An additional 9 percent indicated it is on their product roadmap to implement one. Six of those companies offered entirely custom terms, and the rest offered the partner a standard rate of between 70 and 90 percent of the revenue.

Source: Pandium

The most common revenue share these leading companies offered partners is 80 percent.

When tiered revenue share was offered, companies took different approaches. Atlassian gives a better revenue share, for example – and a first year rate of 95 percent – to cloud apps as they want to incentivize the build of those types of apps.

Similarly, Salesforce improves the partner’s revenue share from 80 to 90 percent after the first 1 million in revenue the partner drives to Salesforce. This encourages partners to invest in maintaining and marketing their integration.

Volusion takes the opposite approach, and offers their highest tier partners 70 percent, while it offers lower tier partners 80 percent. Presumably the higher rate is a reflection of the greater investment Volusion puts into their premier partners.

PrestaShop offers a standard rate of 70 percent, but for bundled apps or those that are featured inside their app, it offers partners 50 percent. This model is essentially charging for the additional leads that being featured in their app drives.

When companies are smaller and extract a revenue share, they tend to let the partner continue to process payments for subscriptions acquired through a company’s marketplace. This approach can be more labor intensive and prone to errors. As a result, it does not scale well.

Usually, this would be done through link tracking that identifies when new customers came from the platform’s marketplace or from the partner’s integration landing page, and, depending on the terms of the agreement, deal registration or account mapping.

Among 13 leading platform companies that disclose their standard revenue shares and payment processing, only one still leaves it entirely to partners to process payment.

Zendesk tracks and simplifies payments by requiring partners to integrate their own Stripe account with Zendesk’s Stripe account. This gives Zendesk and the partner control and visibility into all the payments, and would be a good way for smaller companies to track revenue.

The vast majority of mature partner programs, like AWS, Shopify, Atlassian, and Genesys, that have a revenue share process the payments from their marketplaces themselves. They then remit the agreed upon revenues to the tech partner, minus any fees, taxes, and payment processing.

At scale, payment processing fees can themselves be a notable, additional source of revenue if the company is not simply passing on a third party processor’s fees.

Benefits and Drawbacks

A big benefit of a revenue share is the partner only pays money if they are seeing new business through your marketplace. Smaller companies might be turned off by high initial fees and they might be more willing to build an integration if they only have to pay after they are seeing sales.

A revenue share is standardized, and it is more predictable and easier for partners to build into financial projections than some other methods of monetization.

If the revenue share is executed by the platform company processing payment, it can also improve the customer experience. In that case, the customer can avoid juggling multiple bills. A Shopify merchant, for example, who wants to use loyalty app Yotpo to market their store can simply add it to their Shopify bill. From an accounting and operations perspective, this makes the customer’s life easier.

In other cases, like AWS, customers often have credits they need to use in a certain time period, and it is a bonus for them to be able to use them on third-party software if they do not need them for the main service, like AWS, in the relevant time period.

The downside of a revenue share is it can cut into a partner’s profits, and create resentment or turn off developers if they aren’t perceiving enough value from the relationship. Apple has notoriously seen backlash and negative PR over its 70 percent revenue share, with some developers feeling Apple’s 30 percent cut is too high.

Being realistic about how much partners need to be integrated and how many new deals they will derive from your marketplace will help to determine whether a revenue share will strike the right balance between generating direct revenue and continuing to attract a wide variety of partners who are eager to build on your platform.

Tactic #2: Charging Partners a Flat Fee

Of 46 leading platform companies, 41 percent charge some flat annual fee.

In 78 percent of programs, a potential partner can build an integration and even be a member of the technology partner program without paying any fee. However, with programs that do have fees, if the partner wants to see real technical and business benefits from the program, they need to pay the fee.

In some cases, joining without a fee only gives the partner minimal benefits or support. While Adobe allows potential partners to build an integration without paying a fee, for example, if a company declines to pay their entry level fee of $10,000
annually, it loses access to a developer sandbox and the ability to use Adobe marks for marketing purposes.

A notable exception to allowing partners to enter the program with no fee is Salesforce, which charges a $2,700
security fee (and an annual fee of $150) to list an integration and join the program.

The most common model of technology partnership program is to have three tiers of partners, and to charge higher fees to higher partner tiers. The highest tiers tend to hover around $15,000-30,000
annually. Shopify, for example, charges $15,000, Box charges $25,000, and VMWare charges $30,000
annually to their highest tier partners. Adobe is an outlier in charging $75,000
annually to its mid tier partners (its highest tier fee is not disclosed).

See VMWare and Box’s details below (click to enlarge).

Many fees, like Twilio, who charges $2,000, and Optimizely and Thycotic, who charge $5,000
annually, are much lower.

Most companies create policies around what happens if the program fee is not paid, including if there are late fees and how long the partner has as a grace period before they are removed from the program. In addition, as program fees are generally recurring on an annual basis, the platform must implement a partner renewal process.

Benefits and Drawbacks

The benefit of charging a program fee is it can cover costs related to managing and supporting the technology program. It can also create revenue even if the partner ends up dropping out of the program, or the integration does not gain as much traction as anticipated.

Usually a program fee is more designed to show a sign of commitment and investment from the potential partner. Program fees, especially at the entry level, are not a significant source of revenue for companies, but they do weed out some potential partners who are not committed to building, supporting, and marketing their integrations.

A drawback to a program fee is it can turn off smaller companies, which might serve an important function in your ecosystem. Most programs try to counteract this by offering a free tier with minimal benefits and access.

Tactic #3: Charging Partners for API usage

When partners build an integration and customers use it, the customer will be calling the API, usually regularly. One model is to charge the partner for this API usage. This is not a common approach.

Mindbody is a software for gyms and spas to manage their businesses, and they currently charge their partners via API usage. They charge their partners a rate of $11 per client, which includes 1,000
API calls per day. Any call after that is one-third of a cent.

An API call in this case allows the partner application to retrieve class lists, class schedules, client names, class descriptions, schedules, and more. An email automation platform, for example, might want to get all the client names for certain classes so it can send out reminder emails or special offers.

How many calls the application needs will depend on how frequently the information is needed and updated, and how many different types of information are needed. A studio who only sends out weekly emails to five different classes likely will not need to make many calls.

But a studio that sends out thousands of emails a day that are sent to members of different studio classes, people who have missed classes, people who purchased a class, employees who missed work, employees who had full classes, and more, will be calling the API much more frequently to get the information.

The charging for API usage model might be more common when a product is going to be embedded in partners’ products. Twilio, for example, charges based on API usage.

Benefits and Drawbacks

The benefit of this model is, like a revenue share, partners only pay if they have customers using their integration.

However, unlike a revenue share, API usage does not necessarily connect linearly to a company’s revenue. A company selling a free app, for example, would pay nothing on a revenue share model, but would still have to pay on an API usage model.

Depending on your product, your partners’ products, and your API design, it can be difficult to set appropriate rates. It requires thinking carefully about different use cases, and considering if some are going to be excluded by how the rates are set.

If a particular use case requires a high number of API calls and those calls are expensive, integration around that use case might never be built and the platform will lose those potential technology partners.

From the partner perspective, the total cost of API usage can be tougher to project and calculate. For example, Mindbody’s charging one-third of a cent for each additional call above 1,000 a day requires partners to map out how many calls their customers, on average, would make in a day. And this might vary widely amongst customers.

On this model, a partner will be incentivized to design the integration with the minimal calls necessary. It depends on the product and API as to whether this incentive will compromise the user experience.

In addition, partners will be charged more for higher usage of the integration. Which, depending on the use case, can feel like a perverse incentive for partners. However, if the rates align well with the use case, the costs can be proportional to the revenue the partner is deriving from subscriptions.

Tactic #4: Requiring referrals

A relatively common requirement for companies to ascend in a technology partnership program is to provide a minimum number of referrals. In addition, the platform might require that the partner pay a fee for any deals referred to them by the platform.

Box, for example, requires that its highest tier partners send three referrals annually; in addition, it sends referrals back to the partner. Box counts referrals as leads that close, and the rate of compensation is 10 percent
of the first year contract.

Mixpanel also has a mutual referral program with its technology partners, compensated at 10 percent of closed deals. And iCIMS offers between 10 and 25 percent, depending on how much revenue the partner drives annually.

For its three (out of four) highest partner tiers, Xero requires minimum growth in the number of new app installs and that 20 percent of an integration’s new users are tracked referrals to Xero. So, for the highest tier partner, for example, Xero requires a minimum of 300 tracked referrals to Xero annually.

Requiring partners to register deals is one way to track referrals. This can be folded into an existing referral program, and it works well for sales-referred leads. The more enterprise-level the product, the more likely this will capture the bulk of the referrals coming from the technology partner.

However, referrals might be coming from marketing, and those can be tracked through URLs. Requiring that a partner put in a unique URL to identify any leads that come from a partner’s landing page or social media or other promotions of the partnership can identify customers that came from your partner’s marketing endeavors.

In order to track referrals from the platform to the partner, the same methods can be utilized, including adding tracking to the in-app marketplace.

Neither deal registration or tracking are perfect ways to capture referrals, and both require establishing the terms and conditions around what counts as a referral. Specifically, how long a referral is good for, and what happens if the referred prospect is already in talks with the platform or a different channel partner. In addition, the platform must establish what revenue it will receive and pay for the referrals.

One large e-commerce platform, for example, specifies the referral must be an existing customer of the partner, the referral is good for six months following registration, and the partner will receive 20 percent of the revenue. Dropbox, on the other hand, offers 10 percent for partner referrals.

Some companies, like iCIMS, give a greater revenue share the more business the partner refers.

Benefits and Drawbacks

The biggest benefit of requiring referrals from technology partners is that it is another direct source of revenue.

Especially if partners are compensated directly for referrals in addition to the other benefits they receive as a technology partner, requiring referrals can motivate the partner to spend more resources maintaining, supporting, and marketing the integration.

Similarly, requiring the partner to compensate you for referrals you send to them adds another direct source of revenue.

The drawback of this approach is that it can exclude some smaller partners who might add significant value from a product perspective. Companies usually counteract this by only imposing partner-sent referral requirements on higher tier partners.

In addition, tracking and managing referrals can become time-consuming and potentially create channel conflicts. However, these processes and policies might already be in place at the company for other partner types. In such cases, technology partners can be folded into existing agreements.

Technology partners only add the potential complication of tracking referrals that come directly from the platform or the partner’s in-app marketplaces, and, if marketing leads are not already part of the program design, leads that come from the partner or platform’s public app marketplace. This requires putting technology infrastructure and processes in place to track these leads.

Tactic #5: Requiring partners to purchase services

Technology partner programs often require partners, especially at higher tiers, to purchase services from the platform. These services can be either marketing related or technical.

One of the more common requirements is sponsorship of the platform’s events. VMware, Box, and Palo Alto Networks, for example, all require higher tier partners sponsor one or more of their events.

On the technical side, companies can require the partner to get paid certifications and classes on the platform. SAS, Zuora, and Thycotic, for example, all require paid certifications on their platform.

Atlassian requires higher tier partners participate in their Bug Bounty program, which requires payment to identify any bugs in the apps. And Genesys requires partners to pay for a lab environment.

Though it is not part of standard technology partnership program terms, technology partnerships can also involve requirements that the partner purchase your product. For example, the recent partnership between Slack and AWS not only involved greater product integration, it involved AWS agreeing to have its 850,000 employees use Slack, and Slack extend its use of AWS.

[Related: What is a strategic alliance?]

Benefits and Drawbacks

The benefit of this approach is it can cover some of the costs of program management, and provides another source of revenue.

Like program fees, these types of fees demonstrate partner commitment, and furthers partners’ investment in making the relationship and integration successful.

Partners might also feel like they are getting a better deal when they are paying for particular services than if they are paying a generic program fee.

It can also be a good way to involve more teams, like marketing, engineering, sales, in the partnership, and ensure that the items that are being charged for are taken more seriously. In addition, technical and sales certifications can ensure that the platform is being presented well and utilized properly.

A potential drawback, depending on the size and structure of your partner companies, is that these types of fees can be more challenging for internal budgeting. For example, a company might prefer event sponsorships or technical training expenses come out of the marketing and engineering budgets. This, however, depends on how the company is structured, and how large their technology partnerships team is.

In addition, managing classes and certifications, and offering marketing and sales service can require the platform to expend additional operational resources. Partner-required purchases that fold into a pre-existing process – like sponsoring an event – pose less of an operational cost. But spinning up and maintaining new certifications or tech support programs can be costly.

Like with any additional partner charges, this can turn away smaller partners or partners who are on the fence and who think the fees are disproportionate to their value.

Tactic #6: Selling related good and services

Similar to requiring partners to purchase services, platforms can sell related services to partners. These optional services cover both marketing and technical support.

Salesforce and Shopify, for example, both sell ads in their app marketplaces to tech partners. As Shopify’s App Store gets 250,000
views a week, an ad has clear monetary value. Salesforce, additionally, sells a more comprehensive marketing package designed to promote partner integrations.

VMware offers a customer case study for $3,000-$4,000.

Docker Enterprise, at least before it was recently acquired, sold marketplace leads to partners.

On the technical side, Adobe sells tech support packs for $750 and $1,600, and a $50,000
integration support package that helps partners build their integration and get it verified. MongoDB also sells services to help partners build integrations. VMware offers technical support and certifications for anywhere from $5,000
to $75,000
annually.

Benefits and Drawbacks

The benefit of this tactic is that you can create another source of direct revenue. And certain items, like marketplace ads or marketplace leads, require upfront technical infrastructure but very little ongoing costs so will quickly have high profit margins.

Unlike required paid services, optional services ensure that the partner feels like the cost is justified. However, considering that many companies offer technical support for free, especially to higher tier partners, requiring payment may seem out of line with expectations.

As not everyone needs increased technical support, offering it for purchase can provide an ideal balance between a good partner experience and program costs: partners that do not need it can go without it, and those that do, can sign up. And the burden on the platform’s tech support team remains reasonable.

The drawbacks of this approach might be partner resentment that they have to pay for tech support or co-marketing, and any frustrations with the billing system. Companies can mitigate possible resentment by providing good technical knowledge bases, developer community, and standardized marketing materials for free.

Tactic #7: Requiring partner provide services that have a clear monetary value

This tactic is hardest to connect to revenue, especially if the results are not tracked. But it can be a way to drive revenue and influence deals, and mature tech partnership programs all require that their partners engage in marketing and sales activities related to the partnership.

Sometimes this entails requiring specific activities, such as building a landing page, putting out a press release, providing a demo account to the platform, and training the partner’s sales reps on the integration.

Box, for example, requires its highest tier partners, in addition to building a landing page, hold an annual webinar, create and promote a customer case study, and identify a go-to-market lead within the organization. Higher level partners of Looker must create a co-branded solution sheet.

Most programs require a business plan and regular meetings with the platform to discuss marketing and sales. Palo Alto Networks, SAS, Hewlett Packard Enterprise, Twilio, and AWS, for example, all require ownership and meetings to plan and assess marketing and sales endeavors.

Partner programs can also require a minimum marketing spend that is dedicated to promoting the integration. AWS Marketplace, for example, requires the marketing spend for its higher tier GTM technology partners to be $20,000 to $300,000
annually, depending on the particular tier.

In order for this to be most effective in driving revenue, you should establish a process for tracking that partner endeavors were completed and what the results were.

Mature partner programs have partner portals where partners can submit the marketing content of the integration marketplace landing page. This portal can be a good place to approve the marketing content, and for partners to submit any marketing activities or content.

Larger partners will have a partner manager and this manager can implement a process for tracking marketing and sales activities, and their results. On the marketing side, it is key to see what traffic or leads marketing campaigns are driving to the platform.

Benefits and Drawbacks

This benefit of this approach is that it can drive real leads, influence deals, and increase a company’s brand equity, without charging the partner additional fees.

As the partner is marketing themselves as well as the platform, the partner will also be deriving results from the campaigns. This can foster a sense of collaboration that can lead to further investment in the relationship.

Even if results are not tracked, listing out required marketing and sales activities in the program policies can provide structure for accountability and increase the chances that the partner will engage in those activities.

Minimum marketing spends also ensures the integration does not get overlooked by marketing.

A drawback of this tactic is that some organizations may lose some agility in their marketing and sales approach, or waste time on projects that won’t actually drive leads. Some partnership programs, like Zapier, reward partners for integrations with more usage and popularity, but they leave it to the partner to figure out how to drive more users.

Tactic #8: Charging customers for integrations

The last tactic for monetizing technology partnerships is to charge customers for using integrations.

The dominant model for this is to only allow customers on higher priced plans to access all the integrations. Slack, for example, allows users on their free plan to access 10 integrations. If they want to use more, they have to upgrade to a paid plan.

Though it is unusual, companies will charge customers to use specific integrations. Shopify, for example, charges additional fees to customers who choose to use integrated payment providers on their Shopify store. SurveyMonkey charges customers who wish to use their Salesforce, Eloqua, Marketo, or Tableau integrations a separate add-on fee.

In addition, companies like Atlassian and PrestaShop allow partners to set a charge for customers to use an integration (rather than the app subscription), and they take a revenue cut of this bill.

Benefits and Drawbacks

The benefit of charging customers for integrations is it can create another source of revenue. The downside is integrations can be tough to price properly, and many companies do not charge customers to use them so you may be battling expectations that they should be free.

It is relatively common to see integrations on higher paid plans, though, and thus it is unlikely customers will balk at this structure. Putting an “Upgrade” button in-app next to integrations and tracking purchases that originate with integration landing pages on your public marketplace can demonstrate that upsell revenue is coming directly from your tech partnerships.

Like with any product features, you should assess your different users and see how important integrations are to their user experience, and price accordingly. If an integration is vital to most of your users – say, an email marketing platform integrating with a CRM or marketing automation platform – you should be wary of putting that integration on a plan that is priced above what the average user is willing to pay for your software.

Charging for integrations directly is not a common model, and as result, customers might feel ripped off if you attempt to do this. However, charging separately can help you assess how much integrations are worth to your customers, and create an additional source of revenue.

—

Typical Monetization Journey

Companies usually deploy a combination of these eight monetization tactics based on their organizational objectives, and, ultimately, as an organization, you have to think through which model will optimize both your short and long term goals.

The two main objectives of a technology partnership program are to enhance the product and drive revenue. Most companies see their programs as accomplishing both, but different companies will focus on one goal more than the other.

In the beginning…

To talk in averages, the typical program starts out by building integrations into larger partners on the larger partners’ terms, and creating custom agreements with partners who wish to build into them. Initially, the only monetization might be mutual referrals that aren’t tracked.

As a company’s program matures, it will create broad program guidelines and create a form where partners can apply. Revenue shares where the deals are tracked by the partner, who also processes the payment, might be established at this stage. In addition, a company might formalize their referral structure with partners.

Once a company is confident in many of their integrations’ reliability and support, they might start upselling customers by putting integrations on higher paid plans.

As you grow…

As the program grows larger, it will introduce tiers, and require specific marketing and sales activities from partners, as well as minimum referrals or revenue shares annually. It might take over payment processing in its marketplace, and standardize the revenue shares across tiers.

Strongly product-focused companies will likely skip the revenue share, and instead focus on required co-marketing and co-selling activities, as well as rewarding referrals with referrals back and other sales support.

In order to cover program management expenses and vet for partner commitment, many programs will issue program fees, which go up the higher the partner tier. In addition, they might start selling additional marketing and technical services, including in-app marketplace ads and marketplace leads.

Ultimately, like pricing strategy more generally, a company has to look closely at their objectives and their place in the ecosystem to establish the tactics that will work most effectively for them as they grow and mature their program.

_

Monetizing tech partnership programs can not only cover the cost of running them, but bring in significant additional revenue that fuels the program’s expansion and improves the company’s bottom line.

Marketplaces and the platforms they run on are only continuing to process a larger share of purchases. Investing in the right monetization strategy can ensure your tech partnership program continues to mature, and that you are fully leveraging the value of your investment in your tech partners.

To learn more about how technology partnership programs are structured, you can check out our analysis of 50 top technology partner programs.