If you’re a SaaS company, it is impossible not to tackle the topic of integration. Whether you’re a small software business or a large, established tech enterprise with several SaaS products, every commercial conversation is highly likely to include the question like “Will I be able to sync data from your application with my CRM / ERP / Finance / Marketing … business applications?”
So, the need for SaaS connectivity is a given; it’s not something that is “nice-to-have”, it’s a “must-have” in order to attract new customers, enter new markets and, in general, to scale a SaaS business.
But when it comes to actually enabling SaaS connectivity – in other words, to SaaS integration strategy –, there are many ways to do so, as there are many things to be aware of, to consider, and to plan upfront. Hence, let’s go through the four common approaches that are available to SaaS companies, their benefits and challenges, and also what steps can make SaaS integration an easier and less costly process.
What is SaaS integration and why do we need to address it specifically?
Let’s start by briefly establishing the baseline of our discourse on SaaS application integration. Generally speaking, the definition of SaaS integration corresponds to that of application integration, only that in the case of the former we specify that we’re talking indeed about cloud based – the very premise of the “as a service” concept – applications. So, SaaS integration means connecting one SaaS application to another cloud based software app or, in some cases, even an enterprise on-premises system, with the purpose of enabling a consistent data exchange between them.
Jumping ahead of the topic, the very concept of “SaaS” implies that there are APIs that facilitate data exchange between a SaaS solution and other applications. And so, particularly in the early phase, SaaS businesses often assume that APIs they provide will handle all connectivity requests and their customers’ data integration needs.
While it is perfectly fine to put SaaS APIs in the center of a SaaS integration strategy, there are many factors that can make the approach “Here’s my Application Programming Interface, use it as you need” hard or even impossible to follow. As a SaaS vendor, are you sure that your documentation is complete and fully up-to-date? Does your API possess all the necessary characteristics that make it an easy fit for integration? Do your customers have enough development resources to study your API-endpoints and build integrations with them?
Even if only one of these questions is answered with “no” – it will mean that a SaaS application is not easily integratable, which will have a negative impact on its adoption rate. SaaS APIs are paramount to enabling efficient data exchange but they are certainly not synonymous with “integration.”
Why is integration important in the world of SaaS?
Three years ago I wrote an article titled “People Don’t Want Software Products Anymore – They Want Software Ecosystems”. The title seemed very bold to me back then – though I went with it anyway. And nowadays, it’s increasingly reflecting the current state of affairs.
What’s even more interesting, SaaS businesses started placing more strategic focus on providing integrations to their customers very early on. While I have no official statistics on my hands, I’m encountering an increasing amount of young SaaS products that pro-actively offer integrations at least with a few core systems their customers use.
This is understandable. Once a SaaS company has the core functionalities of their product up and running, so to speak, and gains solid market traction, the next steps are expanding the product’s reach, addressing new user groups, verticals and markets, and surely retaining the existing customers.
Here, SaaS integration plays a pivotal role because ultimately, it all comes down to data availability. As a SaaS customer, I’m happier if I can combine data from your cloud based application with my other data; I’m less happy if I can’t do that. If my specific integration need is critical to my job performance, productivity and / or success, I’ll look for a better solution elsewhere.
So, when we pose the question “Why SaaS integration is important?”, we should pose it not only from the perspective of a SaaS customer, but it is equally important to pose it from the perspective of a SaaS vendor.
Providing integrations to your SaaS solution can become critical for the success of your SaaS business as this will most likely result in higher product adoption rates as well as upsell rates, lower customer churn, deeper customer satisfaction and loyalty, and higher chances to enter new markets.
Key approaches in SaaS integration strategy
Generally speaking, there are multiple ways to provide SaaS connectivity, all of which can be summed up as follows: Either a SaaS business opts for outsourcing this in one way or another, be it through a SaaS reseller, a technical partner or their own customers, or it decides to keep it all in-house.
Below are not all, but the most common approaches that the overwhelming majority of SaaS companies we’ve talked to employ.
Providing APIs for SaaS product integration
This one has already been mentioned above. A SaaS company builds a product and opens its various API-endpoints to the third-parties to use them for connecting the said product with other applications and systems. These third-parties can include: VARs (value added resellers), MSPs (Managed Service Providers), direct customers, professional services providers, independent developers, and so on.
For the SaaS business itself, this approach has a huge advantage of off-loading the integration effort somewhere else, so that the SaaS vendor can focus on its core product.
The major drawback of this approach is that the SaaS company has no control over the quality of integrations, and rest assured – if users aren’t satisfied with an integration because it breaks a lot, is limited or worse, doesn’t work at all, they will subconsciously put the blame on the product first, and only then on the service provider.
In the specific case of leaving it up to direct customers to build SaaS integrations, this approach also undermines the very concept of customer care.
Building new integrations is expensive and time consuming, but it doesn’t stop with just “building”. If you have updated your API, your customers might need to update their integrations too, so maintenance often becomes an issue, as well.
All in all, the approach of providing SaaS APIs and then washing your hands of integration will probably help a SaaS business save its own resources big time but it is the opposite of being customer-friendly, to put it mildly. There are certainly exceptions to the rule, no doubt, especially if APIs are remarkably well-documented, but they are just that – exceptions.
Coding own native integrations manually either on-demand or preemptively
A SaaS business knows their customers best, – after all, an entire SaaS product was built to serve their specific needs. And so it stands to reason that integrations built internally to be natively served within the product will likely satisfy the exact requirements set by the customers.
And this is largely true. We talk to many SaaS companies who have either been connecting third-party applications with their own SaaS platform in a point-to-point manner or have even built an internal system to facilitate and speed up SaaS integration development. All of them argued that due to this, they have full control over the quality and security of integrations, as well as over the customer experience and satisfaction.
Yet the common lament that these SaaS businesses voice is that at some point, this approach became unsustainable. Those with largely point-to-point integrations find it increasingly harder to maintain integrations as the number of connected systems grows. Those with home-grown integration systems grapple with maintaining and further improving the system itself so that it effectively accommodates more complex use cases such as condition-based data routing or data transformation.
Common to both cases is that integrations – their development and maintenance – consume increasingly more time and resources, to the point where the dev teams have to decide what they need to prioritize – core product development or integrations development. Scalability of integrations, or rather the lack thereof, becomes the key issue.
So, while coding SaaS integration manually has its many advantages, it is also the most time- and resource consuming approach. One that can last for only so long, until a SaaS business will be faced with the question – do I have enough dev resources to continue improving and expanding on my core product functionalities AND serve SaaS integrations my customers are asking for? Or do I have to choose either / or?
Directing customers to an integration service such as Zapier or IFTTT
The next wide-spread approach is to use already existing integration tools such as Zapier or IFTTT to build one’s own integration and publish it there.
This offers a tremendous advantage, since these services provide connectivity to already hundreds of software applications and systems. By publishing one’s own SaaS software on such a platform will allow a SaaS company to instantly cover a huge variety of integration use cases.
In addition to that, since a SaaS business is the one who’d develop and publish the integration, they have full control over the quality and maintenance, while saving up on their own resources by leaving it up to the end-customers to configure SaaS integration flows on their own.
It’s a win-win scenario for your SaaS integration strategy. Or rather, it seems to be one.
Up until the moment when you realize that the integration use cases are becoming far more complex for such tools to handle or you’re dealing with such a high data volume that it becomes too expensive to provide any ROI.
To add to that, having to deal with at least three parties – two SaaS businesses and the independent integration tool provider, – the end customers might find themselves confused as to whom they should approach if they experience technical issues or need additional triggers and actions. Let’s agree, being redirected from one service to another in the search for support doesn’t quite constitute good customer care.
Building and offering native integrations through an embedded iPaaS tool
Last but not least, there is a relatively new breed of iPaaS (integration platform as a service) offering that provides SaaS companies with configuration-based, customizable integrations and tools that can be white-labeled right into their own SaaS solution.
Such embedded iPaaS has different forms, and the embedding functionality can differ, too. Some solutions offer it as a full-featured integration hub that a SaaS business can serve to its end-users under its own brand.
Other solutions allow embedding certain modules, for example an integration flow builder, as an iframe, while yet other solutions enable the so-called “deep” embedding through their own integration management APIs. This way, a SaaS company can pre-build specific integration flows and publish them through this API-endpoints straight in their own SaaS product.
Regardless of the implementation, this approach to SaaS integration strategy has its advantages and disadvantages. The main drawback is probably that learning how to build connectors and integrations on an iPaaS can be a steep learning curve. Such tools come with a wide range of data transformation, routing and logic functionalities, and so it will take time to become proficient in such a complex tool. And yes – sometimes, it will be easier and cheaper to manually code integrations as opposed to deploying an iPaaS, especially if the number of integrations is fairly small and the use cases are pretty straightforward.
On the other hand, deploying an embedded integration platform often allows SaaS companies to find this fine balance between keeping control of the depth, complexity, quality and security of the customer-facing integrations, while largely standardizing and streamlining development effort to free up own dev resources. Just like with Zapier, you would build a connector for your SaaS solution only once, and then you can re-use it as often as you need to, only with iPaaS, you have the flexibility to address use cases of just about any level of complexity.
If scaling SaaS business through more integrations – faster – is your topic, we invite you to explore more about what our embedded integration platform can do for you in this case.
Preparing a SaaS integration strategy
While SaaS integration use cases are generally very different, there are still some key elements to a SaaS integration strategy that any SaaS business can and even should follow.
Gain a deep understanding of the use case upfront
First and foremost, before you start with any development process, get a crystal clear picture of the use case at hand. This involves not only understanding what business processes need to be automated and hence, what data objects need to be synchronized between the applications, but also learning the specifics and limitations of each one of involved SaaS APIs.
No two APIs are the same, and you must take enough time to make sense out of each one. For example, some APIs will have an extra level of security by regularly refreshing access tokens, so you’ll have to figure out upfront how you’ll build the logic of getting a new token into your integration flows. It’s often easier to implement ‘countermeasures’ from the start than troubleshoot later when all is set and done.
So, any SaaS integration strategy should start with a clear and deep use case understanding. And this leads us to the second point:
Involve external dev support for your SaaS integration early on
Ok, here is what I mean by that. There is no one who better knows SaaS APIs than the companies that built them, right? Considering this, your dev team might really benefit from consulting with the support team of the SaaS application they need to integrate with as part of your overall SaaS integration strategy, and here’s why.
In particular, if you’re about to build a deep and complex integration, there might be many intricacies of which you won’t be aware of until you start actually building this integration. For example, many established SaaS applications provide several ways to sync the same data objects, each of these serving its specific purpose. The respective dev team can suggest, for example, how you can sync them in the way that is most economical for you, with as few API-calls as possible.
Proactively consulting the support teams of the SaaS software applications you want to connect to early on in the process might very well spare your own development team several hours or even days of research and work.
The importance of and the need for SaaS integration are undeniable. As a SaaS business, there is simply no way you will be able to avoid it. The more interesting question is – how do you tackle this matter? Will you stick to in-house development? Or use the likes of Zapier? Or go for a full-fledged embedded integration via iPaaS?
And here is a challenging closing thought: I believe that many, many SaaS businesses go through all of these “cycles”, some faster some slower. Now the question is – in which ‘cycle’ are you now and wouldn’t it save time, money and resources to skip a step or two altogether?
