TL;DR

• Your B2B SaaS will have to integrate with your customer's business in some way.
• Depending on the type of product this can range from shallow integrations with auxiliary systems (e.g. identity management), to very deep integrations with core systems (e.g. ERP).
• If you can at all avoid some of this, do so. Even if this means fundamentally changing your product.
• Design and develop your external facing API with the integration domain in mind, not your application's domain.
• Determine the value of each component in the integration landscape by assessing the contract value that it unlocks and the scalability that it brings.

Prelude

Imagine venturing in B2B SaaS. This is one of the hottest spaces right now. Retention is amazing due to heavy lock in opportunities, customers are prepared to pay, and your prospects are cash heavy businesses (well, until the virus thing happened, but people tell me — important people — that there will be a vaccine shortly and then it will all be over).

A successful B2B SaaS product needs some level of integration with the customer's business. For your convenience, here is a handy table of different product categories and the minimal set of integrations they require to be a viable B2B product.

As soon as your tool crosses the line from auxiliary process (analytics, collaboration) to a core business process (sales, accounting), you have to integrate against core business systems. We will call these three-letter-acronym-systems, or TLA systems for short. For non-TLA systems, life is relatively easy and there are even standards that work most of the time. For example, OAuth2 and OpenID Connect can be used without much customisation. For integrating something like calendars you need to worry about two, perhaps three standards, and that's it.

For TLA systems on the other hand, all bets are off. There is no such thing as a standard ERP system, a standard CRM system, a standard CMS system, a standard PIM system, a standard HRM system, or standard SCM system (that last one is Supply Chain Management, in case you wonder). It is your API against theirs. There is one constant: all integrations will be custom.

At the time of this writing, Miro lists 455 employees on LinkedIn, none of whom have "integration" in their job title. At the same time, NuOrder lists 151 employees on LinkedIn, almost 10 of whom have "integration" in their job title. And those are all engineers or engineering managers; totalling at least 20% of all engineering capacity.

So, how do you as a SaaS startup deal with the prospect of spending 20% or more of your engineering capacity on integration projects?

The Strategy

Integration projects are highly volatile. There is uncertainty in all corners. Data models are messy. Documentation is outdated. Lots of processes that look automated are actually manual. Standards are nowhere to be found. There is a strong incentive to avoid them, but can we?

Our strategy for attacking the integration challenge involves trying the following four tactics, in order of preference:

1. Try to repackage the product as a personal productivity tool.
2. Reduce the number of integration points and "fill in the blanks with magic".
3. Set up an integration capability as part of onboarding.

Let us look into this.

Try To Repackage The Product As a Personal Productivity Tool

Can you take the essence of your product and repackage it targeted at individual users, not entire businesses? Is your product idea an all encompassing online sales suite? Can you turn it into a online sales presentation tool for individual users who just upload the data they need for their calls?

Do you really need all CRM data, or will you just allow your users to upload their address book and figure out the relevant contact details from there?

A single user will upload a spreadsheet. An IT department will never do this. If you can activate individual users to bring their own data, bypass the IT department and the integration project until you delivered value through your product. Look for self-service options.

Reduce The Number of Integration Points and "Fill In The Blanks With Magic"

Because we all love magic. These days, magic typically means some flavour of machine learning. But we call it AI now. Never pass on an opportunity to add AI to your product and advertise this at great length…

Looking beyond the hype, there is value to be gained from a lot of commoditised or off the shelf machine learning methods when it comes to data integration. Do you rely on product information coming in through an integration? Could you perhaps suffice with just product images and use computer vision to detect the product categories and properties? There is a big difference between uploading a bunch of images or integrating with a product information management system.

Set Up an Integration Capability As Part Of Onboarding

If none of the above strategies are viable for your go to market, you will unfortunately have to support custom integrations as part of your customer onboarding. You could naively think that all you need to do is publish an API with proper documentation, but that is only that start of the pain. It is rare to encounter customers with a reasonable understanding of how their own systems work nor what their data models look like; let alone how to map those onto your API. Often customers do not have internal development or integration development capacity in the first place, and instead rely on third parties to develop these integrations. An API integration is not a ticket in a work queue somewhere, it is a project. It will have many meetings, many people involved, and several budget owners getting nervous. It can take weeks before you even meet the person who can do the actual work.

A Closer Look at the Landscape?

The embedded Miro board below shows the high level integration landscape for a typical SaaS solution.

(Click here for a PDF version.)

Your Integration API

This is your starting point. Whatever you are going to offer in terms of integration options (even if it is only a flat file based option), define the integration API. It is very important to model this API after a domain that is easy to integrate with, not the domain that makes most sense for your application.

The Integration Landscape

Here we find the components that make up your actual integrations. For each component there are two important aspects: ownership and leverage. The first one simply describes who owns this particular piece of integration; you, a customer, a third party supporting your integrations? It is very important that there absolutely no ambiguity when it comes to ownership of integration. When it stops working, does your customer understand that they have to create a fix? The leverage of a component is about how much scalability you gain from having a component. Self service components have more leverage than custom integrations.

Defining the Roadmap

A mature integration landscape for a B2B SaaS business will have everything in the above diagram and more. The hard part is deciding which components to invest in first.

Every type of integration has manual interventions in the process. Self service will require customer support effort and FAQs to be maintained. Custom integrations require project management, design and development capacity, as well as support. These manual interventions incur a cost, both in terms of hours spent as well as opportunity cost for not doing something else with those hours. For each component in the integration landscape, you ask the following questions:

1. What is the combined contract value of the customers who will use this component?
2. Can we bring those customers on without this component?
3. How much additional cost in manual work do we incur when this component is not there?

You start with those components that have the largest answer to the first question. Then you prioritise the ones where the answer to the second question is "No". After that you prioritise the ones that save the most cost as answered to the third question.

Conclusion

We can all dream about how our perfect API will allow everyone to effortlessly integrate with our SaaS offering. In reality this is just the starting point. As it turns out, your corporate or enterprise customers don't speak API. And they don't care about your time. Failing to properly address integration on your roadmap and in your customer acquisition cost projections can be a true deal breaker for your business. If you can not avoid it by changing the product, you have to deal with it from day one and have a roadmap for it. Do not make this an afterthought.