DEV Community: Kristin Ides DeMar

How to Prioritize Integrations for Your B2B SaaS Product

Kristin Ides DeMar — Tue, 21 Feb 2023 22:46:02 +0000

One of the most frequent integration questions we hear from SaaS teams is, "Which integrations should we build first?"

This question often comes up as they're getting started with our embedded integration platform (since it substantially increases how quickly they can launch new integrations), but it's relevant no matter how you build integrations to the other products your customers use.

Outside of core product development, integration development may be the most important thing you can do to define the future of your product.

You may have identified dozens of integrations you'd like to build, but which ones need to come first? Sales can give you all sorts of data about which missing integrations impact the pipeline. Your success team has a list of customer requests they would like to deliver. Engineering has a feel for the level of effort and knows which ones it would like (or not like) to build.

Similar to setting the roadmap for your core product, you need a way to determine which integrations to build first and which can wait. To help you with that decision, let's look at common strategic and tactical approaches to setting integration development priorities. But first, let's recap why integrations are so important.

Why are integrations important for SaaS?

With the average mid-market company using 137 different software tools, it's no surprise that integrations are increasingly important. Without integrations, apps turn into data silos. That, of course, is inefficient, making product integrations essential for the modern software ecosystem.

You are already familiar with SaaS (software as a service) companies like Slack and Hubspot that have leveraged integrations to make themselves indispensable to their customers while growing at phenomenal rates.

In today's market, with few exceptions, a successful B2B SaaS product needs integrations – often quite a few. Let's look at a few critical strategies for prioritizing your SaaS integrations.

Strategies for prioritizing integration development

We have found three common strategies that successful SaaS companies use – often in conjunction with one another – to determine which integrations to build first:

Which integrations are most needed by customers and prospects?
Which integrations will extend your product's functionality and SAM?
Which integrations will increase your competitive advantage?

Which integrations are most needed by customers and prospects?

Depending on your product, you may have a largely homogeneous customer base, or your customers may have substantially different integration needs based on the other software they use. That can vary greatly based on company size, industry, sophistication, and region.

Some situations are straightforward. Perhaps 40% of your customers use the same third-party accounting system, with the other 60% spread over a score of different accounting systems. Integrating your product with that first accounting system will bring needed efficiencies to a substantial portion of your customer base.

But what if the data isn't that obvious? What if only 10% of your customers use the same third-party accounting system? Is that enough reason to work on that integration first? Knowing that one of those accounting systems is gaining huge market share among your ICP or that another 10% of your customers will shift to it in the next year can give you the data you need to prioritize.

As you can see, a big part of using the customer need strategy is getting good customer data. Do you have a regular touchpoint with your customers, like a quarterly business review (QBR), where they can tell you how everything is going and share concerns and upcoming needs? If you aren't getting regular, solid customer feedback, you might be trying to make strategic decisions based on anecdotes.

Along with customer data, you also need prospect data. If some non-trivial number of your prospects are also using or planning to use the same third-party accounting system, that should factor into your decision. Do you have a mechanism for your sales team to pass this data to your product team? If you use a tool like Gong or Chorus to record sales calls, you can set specific terms (such as "integration") to be flagged in those recordings.

The bottom line is that you can only focus on the integrations that are most needed if you know what other SaaS apps your customers and prospects use and how they use them.

Which integrations will extend your product's functionality and SAM?

That is, which integrations will supply desired functionality to your product and help it do more for your customers? In many cases, integrations can expand your serviceable addressable market (SAM) by providing functionality that solves the problems of larger prospects, more sophisticated prospects, or prospects in a new industry or region.

In some situations, building that functionality directly into your product makes sense. But sometimes, adding certain functionality would take your product in a direction that detracts from your core value proposition. Or you could add that functionality but lack the resources to do it right now.

In either case, building an integration to another app that supplies that functionality can often extend your product's capabilities and SAM for substantially less work and cost than building that functionality in your product right now.

Let's say your product is an industry-specific classification system. However, your product lacks the functionality that more sophisticated customers need to automate the scheduling of classification interviews. As a result, you need to decide whether to add scheduling to your product.

In this scenario, integrating with a scheduling system (ideally one that your prospects are already using) will quickly address those scheduling needs and expand your SAM, while buying you time to determine whether there are long-term benefits to having scheduling as part of your core product.

Which integrations will increase your competitive advantage?

Maybe you've had your product on the market for a while, and it's mature, and you've built a few integrations for it but are struggling to differentiate yourself from your competitors. Or you don't have any product integrations, but you are considering an upcoming major release of your product and would like to do something to make your product stand out from the competition.

How many times have you seen "integrates with X" as a value proposition on a SaaS homepage? If you don't have the integrations your prospects want/need, then they'll go with someone who does. To keep this from happening, find out what integrations your competitors have that you don't, and then focus on closing those gaps as quickly as possible.

But beyond matching what your competitors offer, build integrations to outpace the competition. Each SaaS company that builds an integration can choose (within limits) what that integration does, so integrations with the same third-party app can vary immensely. Are there integration categories where you could offer more, better, broader, or deeper integrations than are available from your competitors? If so, building those integrations, and detailing how/why they offer greater value than your competitors’ integrations with the same systems may be the edge you need.

To make some noise in the market, you might also consider launching an integration hub or marketplace or releasing several integrations in an entirely new category all at once. Doing so lets everyone know that you are making a significant investment in integrations as part of your long-term strategy and signals the market that your product is the one that integrates with everything else they use.

Tactics for prioritizing integration development

These strategies are essential for big-picture, long-term planning. Most SaaS companies use a combination of them and ultimately look at the overlap to choose which integrations to build first.

Your planning should also include flexibility for handling integration needs that pop up periodically, often more frequently than you might want them to. Let's look at some common scenarios where a tactical approach is necessary.

You need an integration to win an in-flight deal

Sometimes, saying yes to adding a prospect's integration requirement makes the difference between winning and losing the deal.

The key here is to agree to those integrations that are also needed by other prospects and customers, add value to your product, or help your competitive position.

Sometimes, you may also say yes to an integration to win an important customer, knowing that it will be a custom or one-off integration but that you can pass along the costs to the customer.

In other cases, you may need to tell the customer "No" if the request doesn't fit with the direction of your product or what you can charge the customer won't cover your costs. Or you may need to tell the customer that you will build the integration, but it will be a few months until you can deliver it.

Whatever you agree to, make sure it's something you can execute in the promised time frame to get the new customer relationship off to a good start.

You need an integration to keep a customer

Sometimes, a missing integration causes enough pain or inefficiency to a customer that the customer considers churning – especially if a competitor has or agrees to build that integration.

Leaving aside the question of whether you want to keep that customer, you should ask questions about the integration. Is it a current gap in your lineup? Does it make sense for your overall product plan? Will it add value to only this customer, or will it be valuable for other customers or prospects? Can you fit it into the short-term schedule, or is it better to revisit it in a quarter or two?

Delaying other priorities to build an integration to keep a customer may or may not be the right decision. But if you decide to do it, your decision should be backed up by as much good data as possible.

You need to replace an existing integration

Sometimes, an existing integration no longer meets customer needs. Ideally, you've planned for integration replacements and worked them into a long-term strategy. However, there will be times when new industry regulations or third-party changes (whether to languages, libraries, or APIs) can break something that worked fine yesterday.

Sometimes you won't need to replace an integration. But in many cases, you may only know once your devs investigate whether a small code change will do the trick or if a complete rewrite is required.

Communication is key. Let your customers know what's happening, how you plan to address it, and when and why they'll need to migrate to the new integration.

Change the plan as you need to

Planning product integrations is challenging, in no small part, because systems and technology are constantly changing. Setting up a strategy for prioritizing integrations doesn't tend to get any easier if you wait, but you also need the flexibility to change that strategy over time.

Integration usage and churn provide essential data for adjusting that strategy to account for changes to the market and your customers. And yes, regular communication with your customers is the key to staying current with how they use your product and its integrations.

Whatever strategic approach you put in place for prioritizing integrations is a starting point. You'll need to periodically revisit your strategy to ensure it isn't stale and that you are not missing market opportunities.

Contact us or request a demo to see how Prismatic's embedded integration platform can help you deliver on your prioritized list of B2B SaaS integrations more quickly and respond immediately when more urgent situations arise.

White Label iPaaS for B2B SaaS Companies

Kristin Ides DeMar — Wed, 08 Feb 2023 19:05:10 +0000

As the number of SaaS apps increases and your customers keep trying to do more without greatly expanding their employee numbers, it’s more important than ever that you have the right tools to support native integrations between your product and the other apps your customers use.

A white label iPaaS is one of those tools and is much more than an iPaaS you can brand as part of your product. A white label iPaaS takes the idea of a traditional (enterprise) iPaaS and builds on it with a framework focused on your customers and how they do business.

What is white label iPaaS?

A white label iPaaS is a set of tools that enables software companies to build reusable, configurable, native integrations and deliver them to your customers as features of your application. It’s called “white label” because critical elements of the platform can be branded and configured to match your core app, ensuring that your customers don’t know where your app stops and the white label iPaaS, with all your native integrations, begins.

The important thing to remember about a white label iPaaS is that it is a purpose-built platform software companies use to create native product integrations for their customers.

This distinguishes it from a traditional or enterprise iPaaS, a general-purpose platform businesses use to create integrations for internal use.

A white label iPaaS, in addition to the features of an enterprise iPaaS (integration designer, connectors, and infrastructure), includes integration deployment and customer support tools, customer management, and an embedded integration marketplace. As a result, it is often called an embedded iPaaS or embedded integration platform.

How white label iPaaS benefits SaaS companies

A white label iPaaS can help you build integrations for customers faster. Development teams used to take weeks or months to build a single integration using the traditional from-scratch approach have reported that, with a white label iPaaS, non-developers can build and deploy native integrations to their customers in days.

As a result, you could realize substantial cost savings, not just from the original build time shrinking dramatically but also because non-devs can build a single integration and deploy it dozens or hundreds of times to different customers with their own configurations. Meanwhile, your devs are freed up to work primarily on your core app.

In addition, a white label iPaaS allows you to provide an excellent integration experience for your customers. No longer is an integration a black box, addressable only by engineering if there is a problem. Integrations are available for customers from the integration marketplace and can be searched, selected, enabled, and configured directly by your customers.

You and your customers can rely on the purpose-built infrastructure of the white label iPaaS to handle security and scalability concerns. Best of all, everything from the integration designer to support and troubleshooting tools is embedded seamlessly in your product.

How to choose a white label iPaaS provider

When it comes to choosing a white label iPaaS provider, here are a couple helpful steps:

Identify your integration needs
Evaluate white label iPaaS providers

1. Identify your integration needs

Before you can determine what tool would be best, you should first determine the integration requirements you will likely be working with. Here are some important questions you’ll want to answer:

What apps do your customers need to integrate with your product?
Will they all need the same integration with your product (differing only in configuration), or will they need many different integrations (different apps)?
What API do you have in place for integrations, or do you have another approach, such as daily file exports to an FTP?
Are your integrations going to be straightforward (data from A to B), or will they be more complex (data from A to B, but with data manipulation between A and B)?
How much control over integrations do your customers need (for example, will customers need to interact with integrations as individual users and not systems)?

2. Evaluate white label iPaaS providers

Once you've determined your integration needs, you'll need to evaluate the capabilities and commitment of each white label iPaaS vendor in addition to seeing if they can meet your integration needs. Here are a few essential questions for that evaluation:

Does the white label iPaaS support low-code only, or does it allow devs to code whatever is not available through built-in connectors and components?
Does the platform fit in with your existing dev environment (code repository, deployment cycles, etc.), or will you need to run the integrations development space in parallel with your current software development?
Is the provider dedicated to providing a white label iPaaS solution, or is this simply one of its many products?
Will the white label iPaaS platform scale from where you are now to where you are planning to be in a year, two years, or five years?
Is the provider using a sensible approach to pricing, where you can pass along the costs to your customers by tying your pricing to the value you are providing?

Prismatic’s white label iPaaS solution

White label iPaaS has gained much traction in the last few years among software companies serving all verticals and organization sizes. Prismatic is proud to be a leader in this space.

Our sole focus has always been to create and support a market-leading embedded integration platform that enables software companies to integrate with their customers’ other critical business apps. To do this, our white label iPaaS solution:

Empowers companies to build and maintain integrations easily, regardless of market vertical. CRM or niche, it makes no difference.
Abstracts the complexities of integration deployment to varied customers. We leverage the power of configuration to make integrations work for every one of your customers without making you create unique integrations for every customer.
Provides a best-integration-class integration UX to your customers’ customers. Customers show up for functionality but stick around for the user experience.

If you want to see precisely how our white label iPaaS could help you jumpstart your integration project, request a demo, and we’ll be glad to get into the details.

What Is an API Integration Example?

Kristin Ides DeMar — Wed, 08 Feb 2023 17:56:21 +0000

An API integration is the code that allows one system to transfer data to or from another system while using an API (application programming interface) to securely access the system. Some API integrations may only an API on one side of the integration, while others might use two or more APIs.

Devs build API integrations for different reasons, but those integrations generally fall into one of two categories: they are either intended to run inside a company to automate internal business workflows, or they are meant to connect systems from different companies for external data sharing.

Since we work with software companies that need to create native integrations connecting their products to the other systems their customers use, our example will cover an external data sharing scenario – but the concepts apply to internal integrations as well.

We’ll lay out this example as follows:

Integration business needs (the why)
Integration technical requirements (the what)
Integration details for execution (the how)

Integration business needs

For this API integration example, your company provides a SaaS product for monitoring building security. Among other things, your app regularly records temperature and humidity levels from sensors installed at critical points in each of your customers' buildings. Your customer needs an integration to export these temperature and humidity values from your product daily to its building maintenance app (StructManager). The customer will then determine if there are correlations between temperature and humidity levels and unplanned maintenance tickets.

Integration technical requirements

When building an integration, you’ll want to start with the technical requirements. These are the basic questions you’ll need to answer before you begin:

What data will be transferred? (Data)
Is this a one-way or two-way integration? (Direction)
How often will the integration run? (Frequency)
What APIs will be used? (API)
What transfer protocols will be used? (Protocol)
What transport languages will be used? (Language)
How will auth be handled? (Auth)

Let’s fill out all of these for our API integration example:

Data. Humidity and temperature records per building for the prior day (24-hr-period).
Direction. One-way export from your product to StructManager.
Frequency. Once per day at 7 AM building local time.
API. Your product uses a SOAP API. StructManager uses a REST API.
Protocol. Both APIs support HTTP.
Language. Your product outputs SOAP XML. StructManager accepts JSON as input.
Auth. Both the SOAP API and REST API use OAuth.

In addition, while the humidity data is provided as percentage points of relative humidity (and is the same in both apps), the temperature data coming from your product uses Celsius, while StructManager is set up to use Fahrenheit. Finally, the temperature and humidity data is collected once per minute by your product, but StructManager only needs to know the values every 15 minutes.

So, for this API integration example, we have two APIs, two data formats, two scales for temperature values, and way more data than required. Sounds like we’ll need to do more than just grab the data from one API and hand it to the other.

Integration details for execution

At 7 AM local time, the integration trigger causes the integration to send a query to your product’s SOAP API requesting the records for the specified customer per building for the last 24 hours. Thankfully, your SOAP API supports OAuth, which is built into the connection string. Once the SOAP API receives the request, it sends back XML via HTTP with all the matching records.

A single record sent from your SaaS product looks something like this:

<environmental>
    <customer_id>AA8312</customer_id>
    <building_id>H265<building_id/>
    <sensor_id>1323</sensor_id>
    <sensor_loc>5W2NAB</sensor_loc>
    <timestamp>10:30</timestamp>
    <temperature>27.3</temperature>
    <humidity>55</humidity>
</environmental>

The integration first performs a data format conversion to translate everything from XML to JSON, giving us the following pattern for a single record.

{
"environmental": {
    "customer_id": "AA8312",
    "building_id": "H265",
    "sensor_id": 1323,
    "sensor_loc": "5W2NAB",
    "timestamp": "10:30",
    "temperature": 27.3,
    "humidity": 55
    }
}

For the sample customer, who has 30 sensors distributed over a single building, the daily export from your SOAP API will include 43,200 records, but the integration only needs to send 2,880 of them to StructManager. As a result, we'll need the integration to filter the 43,200 records and strip out every record that doesn't have timestamp values that match the following patterns: hh:00, hh:15, hh:30, and hh:45. And yes, we could figure out a way to request only these records from the SOAP API in the first place, but it’s cleaner in this case to get the superset of data and go from there.

Once the reduced dataset contains only the records we want to keep, the integration will need to loop over the data once more to convert the temperature values from Celsius to Fahrenheit using a bit of simple math. Our sample data now matches the format StructManager needs to import.

{
"environmental": {
    "customer_id": "AA8312",
    "building_id": "H265",
    "sensor_id": 1323,
    "sensor_loc": "5W2NAB",
    "timestamp": "10:30",
    "temperature": 81.1,
    "humidity": 55
    }
}

At this point, all 2,880 records, encoded in JSON, are wrapped up in an HTTP request for the StructManager REST API. Once again, the integration uses OAuth to connect with the API before submitting the data.

Our API integration example has run successfully and will wait until tomorrow at 7 AM for its next run.

Additional API integration resources

Of course, one example can hardly do justice to a topic as complex as API integrations. With that in mind, here are some resources to help further your understanding of API integration concepts:

APIs by technology (REST, XML-RPC, SOAP, and GraphQL)
APIs by access type (private, partner, public, and open)
Integration transfer protocols and transport languages
Integration media types (formerly called mime types)
What goes on in the middle of an integration

It’s all about the tools

APIs are hugely helpful in building data integrations between SaaS products. But having the right tools to work with those APIs is critical. As a software company providing in-app integrations, those tools can be the difference between implementing the bare minimum integrations that meet your customers' needs, and implementing integrations that are so much a part of your SaaS product, that your customers can't tell where your product stops and the integration starts. One of those tools is an embedded integration platform.

Request a demo if you'd like to see how an embedded integration platform can help you build API integrations – or integrations where there's not an API in sight.