Guest post, November 2, 2022 6 min read
This post was sponsored by Cyclr
Integration and connectivity are valuable assets to offer your customers, providing substantial benefits such as saving time, reducing human error and increasing transparency. Each of which improves customer and employee experience. Ultimately, in-app integrations and connectivity help make your business processes scalable.
So, how do you go about tackling in-app integrations?
At Cyclr, we believe there are three viable ways to solve your customers’ integration needs and we’d argue that you should adopt at least two of them.
One way of tackling in-app integrations is offloading integrations. These are deployed via a ring-fenced solution that achieves the customer’s integration request outside of your platform. They tend to be referred to as iSaaS (integration Software as a Service) platforms such as Zapier or IFTTT.
Those who use this method tend to be smaller businesses that want to automate tasks between different software applications but don’t necessarily have the resources to self-build or use a connectivity component. They also want anyone to be able to create integrations between separate apps and build workflows without having to be directly involved in the process.
You would use this method if you require system-to-system integration which is defined as the process of connecting separate computer systems into a larger single system that allows solutions to work functionally together.
This method would not be favourable if you need to integrate system-to-user, where the iSaaS solution is communicating to a user via one-way communication. If the user needs to perform an action from that communication it isn’t handled by the iSaaS solution as there is no way to orchestrate it.
For example, a smaller organisation may offload their integrations because they want to offer integration functionality but don’t have the resources to do it itself. Offloaded integrations handle the system-to-system integration one business function at a time. This could be adding a new email address for a customer from a form fill and adding it into a CRM. This is a 1:1 relationship, from one system to another.
Point-to-point can quickly become unmanageable when a greater number of connections are used.
One of the main benefits of offloading your integrations to a third-party, off-platform iSaaS solution is that it is incredibly scalable and agile without disrupting your UI.
The downside of offloading your integrations is that you are not necessarily addressing your customer’s integration requirements at their point of need. The burden or load stays with your customer and relies on them leaving your application to resolve their integration issues with the offloaded iSaaS provider.
A second way to handle in-app integrations is by building them in-house with your own development team. Essentially you are starting from scratch and writing the necessary code to achieve each integration.
Those who self-build integrations tend to have similar characteristics, such as the resources to develop and run them, a need to maintain close control and the desire to have support and agility close by.
This method would be used because the organisation has the resources on hand and doesn’t require too many in-app integrations. Self-built integrations for small businesses aren’t very scalable and can eventually drain in-house resources. They may also choose this method because they want to reduce any security risks or breaches and maintain control of important business data.
The huge benefit of building your own in-app integrations is that you own 100% of the code and you directly address a precise solution for your end customers. By self-building, you are meeting their needs in a bespoke handcrafted manner.
The downside of self-building in-app integrations is that they can be fragile and the cost of human resources to maintain the integrations is high. They are also a challenge to scale and not particularly agile.
Finally, you could use a connectivity component to achieve in-app integrations. These tend to be an iPaaS (integration Platform as a Service) or embedded iPaaS solution, such as Cyclr. A connectivity component like this is embedded within your SaaS platform. They provide a scalable connectivity framework with easy-to-use low-code tools to design and build integrations rapidly.
Connectivity components are used by organisations that don’t have the in-house resources to self-build all integrations, as they have too many other key resource dependencies; there might only be one individual who has the necessary skill set. They would also use this method if they are shifting to more of a cloud-based strategy.
They would use this method so they don’t have to deal with tasking internal resources with complex integration problems, it is instead outsourced and handled by a managed solution who is an integration expert. This method ensures you have the expertise to leverage protocol, format, develop and deploy integrations and ensure ecosystem connectivity.
Another reason why an organisation would choose to use a connectivity component is that they are shifting to a cloud strategy. Cloud platforms are becoming increasingly popular due to their pricing models of only paying for what you actually use and how they help an organisation’s digital transformation.
As well as this, a key part of a managed integration solution is the uptime SLA, the amount of time that a service is online available and operational. Users get the reliability they need and the integration expertise all in one place. They are able to successfully develop their connectivity and ecosystem.
A connectivity component provides numerous benefits to users, but mainly they help return an organisation’s focus to designing the core features of their platform and the customer solution. By using a connectivity component with low code tools, pre-built API connectors and simple deployment methods mean that the complex work has been done for you.
An embedded iPaaS solution is also both agile and scalable whilst also resolving the customer’s need at the point of requirement.
When speaking to customers or prospects we tend to advise that they should use at least two of the previously mentioned integration options.
For example, an email marketing partner of ours self-built their integrations to remove siloed data from their customer’s CRMs to create a unified picture of a customer. This meant the most relevant messaging and appropriate timings can be considered when contacting customers.
However, as their service grew in demand they began receiving requirements to integrate with a wider range of software; taking up more development resources to self-build each and causing customer onboarding times to take longer and longer. Self building each integration was no longer a sustainable model.
So, in order to expand their connectivity reach and integration capabilities they started to use a connectivity component, Cyclr, to dramatically increase their integration options. As well as improving their integration creation time, the use of low-code tools meant it was no longer solely the development team’s responsibility to create and deploy customer integrations.
Alongside their 25 self-built integrations, an extra 35 integrations became available through the connectivity component. As a result, they were able to integrate with a considerably higher number of different systems with a much lower overhead. They also improved their customer onboarding speed.
The connectivity component helps the partner present and enhance their customer’s CRM data through important and dynamic two-way integrations. For instance, if they send out an email and all of a sudden preferences have been changed. If a customer prefers Mars Bars to Milkways then the partner uses the connectivity component to ensure that all that information is passed back to their CRM.
Why do we do this? Well, we believe that you should resolve the key integrations natively, whether that is self-built or via a connectivity component. Then offload for long-tail integrations.
Using multiple integration techniques can help scale your operation and processes effectively.
Combination considerations:
Depending on the number of integrations you need, you cannot always resolve every single client integration requirement at the point of need. This is because it would be too complex to present an option for every single possible integration within your native UI.
There is however a simple rule of thumb on which choices we would make, the 80:20 rule. Own the integration solution for 80% of your client’s integration needs and outsource for 20% of your client’s integration needs. It is all about efficiency and managing complexity.
A connectivity component like an embedded iPaaS offers an intelligent way to scale your in-app integrations and by no means underpins the entity of your integration ecosystem.
Ideally, you should natively deliver 20% of integrations that solve 80% of your client’s integration needs. Then outsource 80% of integrations that resolve 20% of your client’s needs. This approach can help with efficiency and manage complexity.
For instance, see the table below for how you could combine the integration methods.
It can be tricky picking the right integration combination for your SaaS so, here are 5 key questions to help you consider what solution is right for you.
With these questions in mind, you can assess what combination is best for you. The table below gives you an indication as to what combination of integration solutions would work for each use case.
Ultimately, we believe that connectivity components such as an embedded iPaaS are an intelligent integration solution that helps you scale fast. At the same time, we also believe it is not necessarily the entirety of your integration ecosystem. As we said before, consider the 80:20 rule to help with efficiency and manage complexity.
3 min read
