🎥 Video: Gamification Reducing Healthcare Costs by 5,3%.
Watch now
Welcome to the Loyalty Program Builders webinar. In this first episode, we're diving deep into a crucial aspect of loyalty software implementation: integrations.
Our topic is "Loyalty Software Integrations: Moving Past Out-of-the-Box Solutions" and we'll explore the challenges enterprises face with standard integrations and discuss why a more flexible, composable approach might be the answer.
Let's introduce our experts:
Karol Wieteska, oversees strategic marketing and sales projects for the OEX Group, which provides technology and services in customer experience, merchandising, logistics, and e-fulfillment. With over 15 years of experience in marketing and sales, Karol has held key positions at T-Mobile and Group R22. Most recently, he spent a decade at Comarch, leading global market expansion and managing the Comarch Loyalty Marketing Platform.
Maciej Tyczyński is the CTO at Omnivy, where he spearheads the technological implementation of loyalty programs. With a distinguished career in leadership roles across data science, artificial intelligence, machine learning, and loyalty management systems, he has mastered navigating complex system architectures and demanding integrations.
In this episode, we're pulling back the curtain on software integrations, with a special focus on loyalty programs.
We'll dive deep into:
Do not rely solely on out-of-the-box integrations, as they often fall short of addressing complex integration needs. While they may offer a basic start, they usually aren't sufficient for comprehensive project requirements.
Opt for a composable loyalty management solution to achieve flexibility and agility. These platforms allow for rapid adjustments and seamless integration with various tools and systems, catering to evolving business strategies and needs.
Engage loyalty integrators with expertise in martech. They can navigate the complexities of integration and ensure a smooth implementation process.
Consider using IPaaS to streamline integrations. While IPaaS solutions can simplify and expedite the integration process, it is essential to ensure they are compatible with your specific business requirements and can handle the necessary data flows effectively.
Prioritize speed and agility in both business and technological aspects. Quickly implementing and iterating on solutions can significantly impact profitability.
The ability to rapidly adapt and replace tools ensures that your tech stack remains aligned with your evolving business goals and market demands.
While implementing a loyalty program, be cautious about taking any shortcuts and silver bullets; they rarely cover unique business needs and thus rarely provide real acceleration. Instead, take time to embrace flexible architectures, and leverage specialized knowledge to set up your customized loyalty program integration to get real business value.
Don't rely solely on out-of-the-box integrations. Evaluate your specific use cases and complex requirements that may go beyond basic data flows. Be prepared to invest in custom integration work or specialized solutions.
Look into adopting a composable loyalty platform that offers flexibility and agility. This allows for faster implementation, easier iteration, and the ability to quickly swap out components as your needs evolve.
Partner with loyalty integrators who have deep knowledge of martech and composable architectures. Their expertise can help navigate complex integrations and ensure your loyalty program aligns with both your business strategy and technological capabilities.
From my perspective, the most important question is how quickly you will be able to use a new solution able to address your new need. If you're in control of your IT architecture, if you're using the composable components, you can do it quickly. And this is what makes a real difference.
Karol Wieteska, Group Sales and Marketing Director @ OEX
My perfect world when it comes to loyalty integration would be to go with the composable out-of-the-box solution. It will allow you to quickly run the data flowing between the systems, and have your business team set up.
Maciej Tyczyński, CTO @ Omnivy
Irek: Hi everyone! Thank you so much for registering and joining us today for this webinar. Our goal is to address integration challenges for companies with complex tech stacks and, as you know, we're very practical, so we'll also try to provide you with a less painful solution.
Without further ado, let's jump into the discussion. This conversation is particularly interesting because, Karol, you triggered this whole webinar with your article on the Customer Strategy Network. Let me quote:
"Most of the out-of-the-box integrations offered by pure SaaS vendors are either a marketing hoax (they literally do not exist) or offer functionality limited to a single, simple process that is just not enough in most cases. If you want more, you need to pay."
Can you elaborate on that and explain what you mean?
Karol: You're right, it is quite controversial, and I'm prepared to defend my stance.
Before I do that, I'd like to point out that vendors investing in these out-of-the-box integrations prove that this is a central topic in building marketing and loyalty tech stacks, and a huge challenge.
For brands, it sounds like a dream solution. There's seemingly no risk with the project, and during the RFP phase when selecting a loyalty vendor, you can easily tick off the integration issue. You see they have an out-of-the-box integration, so you assume that part is covered.
Vendors also face a problem. Their main challenge is customers delaying the onboarding of new products due to integration issues. This is quite evident, and there are even reports from the infrastructure platform-as-a-service world stating that the primary objective of building out-of-the-box integrations is to speed up the decision-making process on the customer side. Thus, these integrations look brilliant from the vendor's perspective.
At first, everyone seems happy, though brands might have some questions along the way. If they see a list of 20, 40, or 50 integrations on the vendor's website, but when they log into the tool's panel, they only see two or three, that might raise a red flag. However, the appeal of the solution is often so strong that they proceed anyway, and the real problem becomes visible when the project starts.
It's extremely challenging to use these out-of-the-box integrations to complete a project, especially when you have a robust loyalty mechanic combining point of sale systems, an e-commerce platform, a loyalty platform, and a marketing automation platform.
I believe Maciej would be the best person to provide some insights here, as he has firsthand experience with this process.
Irek: As you said, it looks like a perfect solution for everyone, but somehow it's not working. Maciej, could you give us your perspective? How do companies actually glue things together, and why might such out-of-the-box solutions not be working for everyone?
Maciej: Karol mentioned one major consideration: integrations in loyalty implementation projects are often not a big concern during the selection process, but they become the biggest issue during implementation. It's easy to fall into the trap of seeing 50 different logos and thinking, "Oh, they have it figured out, so I won't need to worry about that." However, it's not as straightforward as it may seem.
From the vendor perspective, there are two main reasons why they market 50 different integrations but in reality have only two or three basic ones:
Control: It's much easier to develop a feature that you fully own and control. As a loyalty vendor, you can add a functional enhancement to your promo engine, like a new type of coupon, and have end-to-end control. You can make a nice video about it, put it on a slide; it's easy to explain and showcase. With integration use cases, it's much more difficult to do that.
Maintenance: Maintaining integrations is far more expensive. No matter who you integrate with, you need to keep up with their API, deprecation policies, and backward compatibilities. Whenever they change something, you usually need to adjust, so it's not as simple as just doing another functional enhancement.
There are also objective reasons why these product-to-product or native integrations don't solve most complex use cases:
Flexibility of modern SaaS platforms: Almost every SaaS platform now offers some kind of rule engine or no-code/low-code flexible engine that allows a high degree of configurability, and it's really difficult to predict every single use case a client will come up with.
Reusability: SaaS platforms count on feature reusability. When they build out-of-the-box integrations, they're usually very high-level, allowing for basic data flows like moving objects from one platform to another. But when you drill down into specific, real use cases, they're usually just a good start and won't solve your entire problem.
I can give you an example, but perhaps Karol or Irek, you want to add something or comment on that?
Irek: I think you've explained the problem in details, and I'm definitely interested in the use case you're about to show us.
Maciej: Right, so the example is based on a project I was involved in where we were integrating a loyalty platform with Shopify. I don't think I need to introduce Shopify.
In theory, integrating with Shopify is easy; it's a modern, cloud-based SaaS platform with rich exposed APIs, webhooks, and multiple integration methods.
But when you dig deeper, you quickly realize that every platform has its niche, the way of naming objects and doing certain things. In this particular case, we had an issue integrating the product catalog, where Shopify forces a specific product catalog structure. This can work well out-of-the-box in the apparel or fashion industry, but if you try to reuse it for different industries, such as B2B, you quickly realize it's not that easy.
You need to adjust your product catalog, and the way you store it in your promo platform doesn't necessarily mean you'll be able to migrate the same structure in a one-to-one fashion. So that's the first challenge.
The second is that almost every platform you later integrate will have some limitations. In Shopify Plus loyalty's case, they heavily protect their checkout process. They don't allow much checkout customization. This does change as the platform evolves, allowing more customizations, but they try to lock it because this is essentially where their business comes from.
They earn money by taking a percentage of the transactions processed through the platform, so allowing easy integration or customizability of this particular element could harm their business model.
The third issue is the lingo or wording that every platform uses. Figuring this out isn't even about development or technicalities, but about how you store or name your core customer identifier in your platform, and how you store different custom attributes across different platforms. There's no common standard.
Reaching out for the out-of-the-box integration, you quickly realize that you'll end up with at least these three issues.
To sum it up, these product-to-product integrations are great to start with, to get some basic data flows going. But when you delve deeper into how all this different data will need to flow between your platforms and more business and customer journey-style use cases, they won't be enough.
Karol: This essentially means that: you started, checked out a platform, and your basic data is flowing. However, if you're building a loyalty program, you need to have robust campaigns that will impact ROI. Simply moving one object from platform A to platform B does not provide the opportunity to generate real value for your business. This means you need to stop using the out-of-the-box integration and build something that allows you to create those robust campaigns.
Ultimately, you find yourself in a situation where you have to build the integration. That's the whole point. What happens next?
It depends on your general approach to managing your IT architecture. It's different if you're a large legacy enterprise relying on "heavy" vendors such as Oracle, SAP, or Salesforce, and it different when you lean more towards a "composable" approach, where you take control of your IT tech stack. Then, you likely have some internal resources or leverage the advantages provided by the SaaS world.
Maciej: Today, you would probably implement some kind of custom integration either through a third party or your internal technology team. Typically, this is what happens in such projects: the customer falls into the trap of thinking that out-of-the-box integration will suffice and won't require further attention. However, when they reach the implementation phase, they realize this assumption was incorrect.
Ultimately, they either have to start from scratch or create a hybrid solution where they use native or out-of-the-box integration for basic scenarios and build a custom layer for more specific use cases.
The problem with this approach is that it leads to the same trap these vendors aim to avoid by not building their product for extensive integration. Maintaining such custom integration layers becomes increasingly difficult over time.
It's ironic because, initially, the CTOs of Fortune 100 or 500 companies are aware of which software to avoid. They examine APIs and solutions, recognizing potential maintenance challenges. But then, they purchase the sleekest, most composable solution and push the integration work to their internal tech team, which might not be familiar with the software or the system integrator might lack expertise in a specific business area. This often results in a very messy integration.
So, despite spending months selecting a great product, they end up with an integration that is messy, hard to maintain, and very costly. In some cases, maintaining the integration can be more expensive than the product itself.
This is likely the path most enterprises will take. However, there is another approach using integration platforms-as-a-service (IPaaS), which isn't as new as it may seem. In the past, these were known as enterprise service bus solutions or API gateway management platforms, such as MuleSoft and Informatica. These serve as middleware layers to orchestrate data flows between platforms.
IPaaS significantly speeds up integration between different platforms. Using such a platform, instead of building a custom solution, can maintain a level of sanity and simplify adding new elements to your tech stack in the long run.
Karol: That would be ideal, but unfortunately, an IPaaS solution specifically for loyalty programs isn't available on the market yet. Building your own marketing tech stack following composable principles makes it easier to solve the integration challenge.
Maciej: I wouldn't say it instantly solves all the problems that you may have. Also I would argue that you don't necessarily need an iPaaS dedicated for loyalty solutions because these platforms as a general rule of thumb, they should integrate with as many platforms as possible. Although loyalty is a pretty specific area, and you need to know what you're doing.
So even with IPaaSs of today and composable solutions, it still requires some figuring out how to do not falling into some traps.
I would say my perfect world when it comes to loyalty integration would be to go with the composable out-of-the-box solution. It will allow you to quickly run the data flowing between the systems, and have your business team set up.
Karol: Yes, but does this really generate significant value? You can address it in two main ways:
Both approaches aim to tackle the integration issue, but the choice depends on your organization's specific needs and resources.
Maciej: Well, I would argue that the quicker option is always better. Sometimes, working with an external partner speeds things up on paper, but when you look at timelines, there are often many requirements that turn your initial plan of going live within a few months into six months, eight months, ten months, or even a year, due to unforeseen issues.
In my opinion, it is better to move quickly, deploy as soon as possible, and start tackling integration issues immediately. You might not have the full scope of your program initially, but you'll be live in two or three months instead of ten or twelve.
That’s the key consideration for every marketing CMO, CTO, and loyalty manager: what's more important to them—launching quickly and iterating, or relying on a partner to handle it for you? If speed and agility are priorities, a composable solution combined with a smart integration layer may be the best approach.
Karol: Yeah, imagine there's a new solution on the market or you have a new need. From my perspective, the most important question is how quickly you will be able to use a new solution able to address your new need. If you're in control of your IT architecture, if you're using the composable components, you can do it quickly. And this is what makes a real difference.
Irek: Okay, so as I understand it, speed is the key here. On the business side, it’s about speed to profitability—how quickly we can make changes and start showing a profit, right?
On the technological side, speed involves several factors: how fast we can implement a solution, how quickly we can iterate on it, and how rapidly we can replace it if we decide it’s not the right tool for us.
Maciej: Exactly. I think a new top question when selecting technology will be how quickly we can swap it for something else. The answer "within years" will not be a green flag. The solutions that will stand out are those that can be quickly turned on or off, switched, replaced, and adjusted to accommodate changes in business requirements.
Irek: I guess this also highlights how choosing a vendor and the sales process have evolved over the years. Nowadays, it's more about figuring out the proof of concept, as you mentioned. It’s not just a guess; it's a data-informed decision. And the composable approach allows you to test the proof of concept and determine whether the technology effectively serves your business needs.
Maciej: Correct. I would add to that: don’t forget about integration during the selection phase. The fact that a technology has a nice API or an out-of-the-box connector might not be sufficient if you have a complex ecosystem.
Irek: Okay, we are slowly wrapping up. But before we finish, I’d like to revisit our community's perspective. Let's see what James has to say:
Have you seen something similar in your experience?
Karol: Absolutely, nothing to add. Is there a solution? Probably, effective communication and double-checking can help, but the problem often escalates with larger organizations. However, I believe that the more informed you are and the more aware you are of these hidden traps, especially in loyalty projects involving integrations, the better prepared you'll be. The more we discuss these issues and share knowledge, the better informed people will become
Maciej: I would also add that the common scenario is the company hires an external consultant who come up with a loyalty strategy…
Karol: … but when they are not loyalty experts you can end up doubling your problem.
Maciej: Sure, that's true, but I had something else in mind. Even if a real pro in loyalty creates a brilliant strategy for you, it still needs to be implemented in reality. Sometimes, the clash between grand business strategy and execution becomes quite challenging.
So, the takeaway, I would say, is that in the niche of loyalty, it's probably best to choose a company that not only has deep expertise in the loyalty business but also knows how to execute the strategy effectively and takes responsibility for it
Irek: That is also aligned with a composable approach, which is flexible enough to adapt to the strategy regardless of its specifics.
Karol: The overall conclusions are that:
At the end of the day, you might get a shortcut if you find an iPaaS that will make the integrations a bit easier.
Irek: I also believe that it shows the value of a composable approach, as it provides the flexibility we need, depending on how the strategy looks and what it implies.
If you feel restricted by your current tech capabilities, it might be time to look at composable architecture, build a proof of concept, and determine if it is profitable.
And that would be it. Thank you so much for joining, and see you soon at the next webinar!
API-first loyalty and gamification engine
Get a weekly dose of actionable tips on how to build and grow gamified successful loyalty programs!
