How To Make The Most of Your SaaS Integration Pages

So, you run a software company that integrates with other software products, and want to make the most of those integrations? 😄

In other words:

1. Drive usage and engagement: You want existing users to take advantage of the integrations (use them).
2. Make it easier to convert users: You want to highlight the fact that you have these integrations so that they can play their role in helping potential users decide to use your product (because it integrates with another tool that they use).
3. Act as a discovery mechanism for new users: You want people who match your ICP to come across your software product because they find an integration that you have.

Welcome to the right place to build & grow your SaaS. 🤝

So, let’s get to it…

Setting The Right Expectations For Your Integrations: You Are Not Another Zapier.

Integrations aren’t always the answer to your growth problems.

There’s a common misconception surrounding #3 from the list above. Wanting people to come across your software product because they find an integration your product offers is, in many ways, an approach pioneered by the team at Zapier.

And a lot of companies think it’s easy to replicate. The reality is that it isn’t.

Let’s break down why this approach is not as easy as people imagine:

Although Zapier is, in a sense, its own software product – it’s actually the glue that connects other software products.

So people never really found Zapier, which is a tool that happens to integrate with another product – they found the glue that connects two tools they already use.

Users who found Zapier in this way never really saw signing up for (and even paying for) Zapier as adding another tool to their stack.

It was, instead, their way of connecting two pieces of software they were already paying for. This made sense, as it allowed them to automate a part of their workflow so that those two tools they already used became even more useful.

Zapier’s role is to make the two (or more) existing apps in a user’s stack more useful.

A somewhat obvious (at least in my opinion) but fundamental difference.

Most software companies, including the one that we’ll be using as an example here, aren’t “connector” products like Zapier (i.e., not a product with the core intention of integrating other products). Instead, they’re standalone solutions that offer integrations with other products that the users they already have, or want to attract, may use.

• Think of a project management platform like Asana integrating with Google Docs:
  
  Asana knows that a lot of the teams that work in Asana use Google Docs as a part of their process (for example, us writing this very post in Google Docs, with the task for the post to be written being a ticket in Asana).
  
• Think of an email client like Missive integrating with Asana:
  
  Missive knew (since this was built based on user requests) that many of their users also use Asana, and would benefit from an easier way of creating and associating emails with tasks, and vice versa.

Choosing A Specific Example

To make this advice more practical, we’re going to pick a specific product to add context to what we’re talking about.

This will hopefully make it significantly easier for you to see how to adapt this advice to your own SaaS product.

Our chosen victim 😉is … Atarim.

What is Atarim? Overview & Introduction

Atarim is a visual collaboration platform.

It’s the internet’s collaborative layer.

Teams turn to Atarim when they want to work together without the endless email ping pong 🏓 – whether that’s a product manager creating tasks for designers/developers to ship a UI change, your marketing team designing ad creative, or anything in between.

Here’s what this means – explained in just over 60 seconds:

Where do integrations come into the picture for Atarim?

So, although a lot of teams use Atarim in isolation, a good portion of the market, particularly bigger teams, already use other tools as a part of their stack. (And it’s these bigger teams that also tend to be the ones which bring more users/seats per account.)

Some examples include Jira, Monday.com, Asana (which we use internally), and so on.

And, as you might’ve guessed, in order to improve the workflow and onboarding for users that do use these other tools – Atarim offers 🥁… integrations.

For a product like Atarim, this achieves a few core things:

1. For new users: Integrations make it easier for teams to implement Atarim because they can bolt it into their existing workflows (more seamlessly than switching over).
   
2. For existing users: Integrations drive usage. The product is more sticky if they can use it where everyone already works. Imagine, say, a software development team that already uses Jira for project management also needs a visual collaboration platform that is platform-agnostic…
   
   ..the answer is Atarim. 🎉
   
3. Before converting: People who have been researching Atarim see that we integrate with another tool they already know, which in turn makes them more likely to convert.
   
4. During discovery: They may come across Atarim as a result of a problem that a specific integration solves. As we noted earlier, since Atarim itself is not an integrator product, this is less common.

Your Main (Top-Level) Integrations Page

The main or top-level integrations page is the /integrations page on your marketing site.

It’s public-facing, and should serve as a full list of integrations.

The order of these integrations, and the direction that you take with this, will depend on both your product and the number of integrations that you have.

Once you have a good number of integrations, you should consider breaking them into categories (i.e., engineering, marketing, Git, etc.) so that it’s easier for people to explore the ones more relevant to their role.

There’s also a subtle psychological benefit of using categories, which is that it is immediately going to make people with roles in, say, engineering or marketing feel “spoken to”. 

On top of that, I’m also a big fan of highlighting or visually distinguishing the most popular and widely used integrations. This is because it’s almost always safe to assume that the integration that’s the most popular among your current user base is quite likely going to be a crowd favorite among the people browsing your site.

Call this category or section something like:

• Featured
• Popular
• Staff Picks

Don’t try to be unnecessarily creative with naming the category because this makes them less useful. The entire point here (and, in many ways, this applies to various parts of your marketing site) is that you don’t want what’s unique about your site to just be the way you structure things, and the names you give to categories.

That creates unnecessary confusion, and makes it harder for people to find things when they’re already used to buying software, looking at sites like yours, and have grown used to certain conventions.

Slack does a great job with this.

And, while we’re here… since I know you’ll appreciate these, here are a few other examples of top-level integrations pages we’re fans of:

Asana

• Simple clean design with lots of white space that makes it easy to focus on each individual card for an integration.
• Categories in the sidebar.
• Not too much going on visually.
• Could be better: Default order should be based on popularity. Perhaps they intend to push certain integrations as a part of partnerships, but it’s strange to see their Microsoft Teams integrations listed before Google Drive, Slack, etc.

Slack

Not that we expected anything less from the Slack team 🙂

• Nice animation component in the hero area immediately grabs attention, and turns what is a traditionally boring/simple directory page into one that is visually interesting – without having the “too much going on” effect.

• When logged into a workspace (or even multiple), the experience is slightly different in that you are able to install apps directly in the web app from the marketing site. This is not easy to execute well, especially if you use a CMS for your marketing site (and no, I’m not suggesting that switching to a headless setup just to be able to do things like this is going to be worthwhile, but it definitely is a nice touch).
  
• You can search integrations (or apps, as Slack calls them). This is unlikely to be a feature you’ll need if you have fewer than 20 integrations. Once you have more than 20-25, then I would consider making it searchable at that point, although with the caveat that search has to be good in order for it to be useful:

• If you’re going to implement a search feature that requires a user to hit ‘Enter’ and then wait 3-4 seconds again to see if the integration they’re looking for exists, or land on a generic “no results found” page if not, then don’t bother implementing search.
  
  Instead, I would advise sticking to categories to make drilling down easier, and making your integrations page more scannable.

Ideal Structure for Individual Integration Pages

Now, when it comes to your individual integration pages, let’s break down the general approach that applies to any integration. We’ll use Visual Composer for Atarim as an example.

For context: Visual Composer is a page builder for WordPress that integrates with Atarim – enabling VC users to access their Atarim tasks, and collaborate from directly within their WP editing experience (when using the Visual Composer editing experience).

1. Title: GitHub
2. Description: Create and manage tasks directly as you design pages on your WordPress website with Visual Composer.
3. Screenshots of the integration: A gallery similar to the approach Slack has taken is recommended. Images included should have captions explaining what is being shown (but images should also be very explicit, and not require a user to zoom in or think for more than a few seconds to figure out what is going on).
4. Overview: This will act as an extended version of the description to cover what can be done with the integration, without getting into the specific steps of how it works as that will be next.
5. How It Works: A detailed description of how the integration works, what users can expect, as well as an example use-case (or more than one) of what can be achieved or improved as a result of using the integration (tie back to jobs to be done).
6. Configure: Guidance on where to get started with the integration, integration prerequisites (do you need an account with another third-party service, etc.?), and links to documentation / help center content where you cover how to set up and use the integration in detail.

I always prefer when there is a sidebar layout similar to this one, because you can fit so much more information in without the interface becoming visually dense.

And then, we can also have specific information such as:

Built by: Atarim (or if the integration is built by their team, etc.).
Website: Link to the product we’re integrated with.
Docs: Link to help documentation on using the integration.

Should You Also Create Dedicated Landing Pages For Integrations?

Not all integrations are created equally.

For example, Missive has an integration with Grammarly (or rather ‘had’, since they’re soon deprecating API access).

But … the core concept of how that integration works is very basic. It’s the same as what you get when using Grammarly with their Chrome extension – so there isn’t really anything all that exciting about it. ✨

In other words, there is a good chance that some of the integrations you or your team have built for your software product:

• Have greater demand in search.
• Can be cross-promoted through a partnership with the company you’ve integrated with.
• Are significantly more likely to influence someone to buy.

In order to figure out what these are (if it isn’t immediately obvious to you based on conversations with users), make full use of existing data:

1. Use Google Search Console and Google Analytics.
2. Use product analytics metrics: tools such as Amplitude, Mixpanel, and PostHog are great options for this.
3. Talk to sales/support teams to get qualitative feedback.

The Visual Composer integration for Atarim was originally launched with a dedicated landing page. This is because it formed a part of the launch strategy for the integration.

Designing SaaS Integration Landing Pages

Note: These are different from integration pages,, they are not the same as the integration directory pages: https://atarim.io/integrations/asana

If you choose to build a dedicated landing page for a specific integration, then this must mean you consider that specific integration to be of particularly high value to you as a company – and to your target customer.

Note: Do not duplicate what you have in your integrations directory. This is a landing page, and it should be modeled in a completely different way. Content should not be duplicated.

As a starting point, here’s a skeleton for an integration landing page:

Hero Area

Introduce the extension very similar to how you would present a feature. Pitch the core value proposition/hook the visitor in.

Body Content

Covers the pain points that this integration helps address, as well as the jobs to be done that this integration is able to help with.

Use Cases / “Recipes” for this integration

Think of a recipe as being what the end user is going to be able to achieve with this integration.

The extent to which this can be done is going to depend on what the integration is, of course. But if you can, include “cards” in a grid on the landing page showing the different use cases, along with examples.

Call to Action

Book a demo with your team, or whatever you feel is the most suitable next step to get going with this integration.

Nailing SaaS Integrations – Some Other Advice

Don’t call your integrations native if they’re powered by Zapier (or similar connectors).

Zapier is great, but integrations powered by Zapier shouldn’t be branded as native integrations as it is misrepresentative of how your integrations actually work.

• They require a Zapier account.
• They require connecting services w/Zapier (a third-party tool).
• Configuration does not happen inside your application.

Ergo, they are fundamentally not native to your application.

That doesn’t make them bad, but don’t start by setting expectations poorly with your end users.

When possible, prioritize the integrations that you build based on real demand (or what people are looking to achieve based on data)

Don’t build integrations based on the ones that you think are going to be the easiest to market. Build what your users want.

This sounds like very obvious advice. But I often see software companies prioritize building integrations that are likely to bring in new users – as opposed to building something that is already fully validated + proven to make an impact on how people who already pay to use your service are able to get their work done (or achieve X outcome with your product).

In certain markets, you will actually face a backlash from your users if you don’t follow this advice… perhaps rightfully so. You are putting people who have already given you their vote of confidence (and money) behind the prospect of “new customers”.

After Action Report – Don’t Just Build Integrations, Give Them The Love They Deserve

I hope you’ve found this guide on integrations for software companies a great starting point for your product team’s discussions.

If you have any questions about what your product’s integration strategy should look like, or want to run something by us – please feel free to shoot an email over to [email protected].

We look forward to hearing from you.