An interview about headless loyalty software with Cezary Olejarczyk of Open Loyalty.
This might be the first time you’ve really heard about headless loyalty software. It’s a fundamental change to the industry narrative but Open Loyalty is now the first loyalty solution to market itself as being fully headless—and that is a significant development in an industry that has traditionally lagged behind areas like eCommerce and CMS with the adoption of new technologies. We spoke to Cezary Olejarczyk, CEO of Open Loyalty, about what headless loyalty software is and why it is an essential step to take right now.
Why make the switch to calling Open Loyalty headless loyalty software?
We’ve always been headless to some extent, from the very beginnings of Open Loyalty. The solution was built around an API from the very beginning, with separated front and back ends. Like some other loyalty software solutions, we took an API-first approach but it was still one step away from being truly headless. We’ve now adjusted the API to make it more flexible and open to more frontends, so that is why we decided now is the time to really commit to that narrative.
Why is now the right time for that change?
We previously spoke about being open-source and then open-code. Both of these are quite accurate and had positive attributes for customers. They told people that it’s a flexible and open solution. But they have some drawbacks; some enterprises still struggle to understand the incredible value of open-source.
Now is the right time to start talking about headless loyalty software because it has “crossed the chasm” and everyone now knows what it means. Companies like Spotify, Coca-Cola, and Amazon are using microservices architecture, so we’re speaking the language of business right now.
Is the approach to headless loyalty software different to that of monolithic loyalty program systems?
There needs to be a change. The world has changed and software development needs to reflect that.
Up to now, companies were focused on features when building an MVP of a loyalty program. They were building a system that could do half a dozen things well when it was launched but were not considering how they might need to quickly adapt and expand that system in future.
Nowadays, businesses need to move away from feature-driven development and move on to architecture-driven builds. That means focusing on building the right architecture that can adapt fast and easily to new technologies, and even external disruptive events like the pandemic. A monolith does not offer that dynamic ability to change because the whole system is interdependent. With headless builds, you can switch how you use your API, changing a sequence or using API in the other parts of the frontend. Changes can be made by switching API endpoints, not rewriting whole swathes of backend code.
Is monolithic loyalty software capable of keeping pace with the changes?
If you have enough money and resources, anything is possible. However, time is critical because client needs are changing fast and competitors are innovating at speed. With like-for-like project resources, headless loyalty software will always be exponentially faster than a comparable monolith.
It’s not only slower to build a monolith; they also struggle to keep up with the pace of technological change. They were fine a few years ago, but brands have since started to integrate technologies like AI and AR into loyalty programs, to add new user devices, and to interact with customers via multiple channels. That makes for an incredibly complex matrix, so the owners of monolith-based loyalty programs are faced with two choices:
– Retain the monolith but fail to add new functionalities and touchpoints that customers expect
– Switch to a headless system and move with the times
Is the loyalty industry too traditional or slow to adopt new technology?
Yes and no. The industry is too traditional in the sense that companies still try to win out against one another’s loyalty offerings on a feature vs feature basis, instead of thinking about the big picture.
However, the reason loyalty programs have not been built with a headless approach up to now is because there is a domino effect. First, the general eCommerce domain builds all these integrations and moves over to a headless approach en masse, then the loyalty industry follows suit because it is serving commerce, not vice versa.
However, once you’ve moved a loyalty program over to headless loyalty software, you can stop that lag. You can react to changes in eCommerce and other industries in real-time.
What are the biggest ongoing business advantages from headless loyalty software?
There are two main areas: consistent customer experiences and data-driven offers.
Firstly, you meet the customers in the space where they are shopping. With monoliths, you might only be able to offer your customers the benefit of your loyalty program if they shop in one place. But stores now offer a range of channels and on potentially dozens of devices. Customers shouldn’t only be able to gain and use rewards when buying on a desktop directly from your store. What about customers buying from a multi-vendor marketplace using a smartwatch one day and buying via mobile device on Instagram the next?
Take social commerce, for example, one in four businesses now sell directly through Facebook, so the customer is not landing on the brand’s website when they make that purchase. Building with a monolith means your loyalty program misses that touchpoint and the customer doesn’t get any reward for their loyalty. What’s more, they also feel like they get an inconsistent experience from the brand across different channels.
And let’s be clear here: a unified, consistent experience doesn’t mean exactly the same experience on all channels. Each channel is unique and the type of customers who buy through smartwatches will also be a different segment to those who use desktops. You need to adapt to what users expect on each channel. You can’t do that with a monolith but with a headless solution, you can separate the backend and create as many unique frontends as you need.
What’s more, as a brand, it’s a big miss if you are not covering all touchpoints with your loyalty program. Every purchase is data that you can use to calibrate and improve your offerings.
What makes data-driven loyalty programs better than traditional ones?
In a word: personalization. People are no longer distanced from brands. In fact, they are saying to brands “show me you know me!” They want offers that are unique to them, not a generic catalog of products that you can get by redeeming points.
Data is the difference. For example, John and Dave are both members of a petrol station loyalty scheme. John uses the car wash once a week but never buys a coffee in-store. Dave likes washing his car by hand at home but always buys a coffee when he fills up with petrol.
A great data-driven loyalty program would maybe send John a text message with a code for a free car wash (worth $10) if he puts 20L of petrol in his car, while sending Dave an offer of a free coffee (worth $5) for putting in 10L. And that is only scratching the surface. Like any system, it should learn and get better over time.
Traditional systems that are not data-driven cannot get better with time or make people feel a personal connection to the brand. They can only offer a wider range of generic rewards.
This is also why you need to be available on all channels. More touchpoints means more data… and more data means an endless calibration of your offers to clients.
Do developers prefer a headless approach to building software?
Perhaps some developers still love a monolith; after all, they are familiar and don’t require developers to think about all of the pieces of the puzzle. However, there are numerous reasons why businesses and software development teams, in general, prefer headless builds.
Speed is a factor for business. It is so much faster to get the system off the ground than building a clunky monolithic application.
And developers and businesses both value the freedom. With a monolith, you must have a team of developers that use the same language that the original application was written in. This can be limiting and expensive, as you need to hire developers with specific expertise. With a headless approach, we expose the API and the developers can use whatever language they want. Originally, Open Loyalty was written in PHP with Symfony, but the in-house developers at the customer will have their own weapon of choice, and that is great.
Are there any disadvantages to headless loyalty software?
We love headless, but it isn’t a silver bullet. As with any system, the most difficult part of building is integrating one system with another. If you don’t do it right, you can end up with spaghetti architecture and a lot of issues. However, with a headless approach, this is something that can be solved by being aware and planning your next steps in advance. You can avoid it.
Also, small companies probably don’t need to use headless architecture from day one. It requires in-house or agency development teams and some understanding of building software—so it may be out of the scope of many small businesses. However, if you plan to expand, you will need your loyalty program to promote that growth, not stop it in its tracks. In that case, you’ll probably need to switch over to microservices anyway.
How do you make the switch from a monolith to headless loyalty software?
However you want! That is really the beauty of microservices. You can use one team or many, internal or external. You can choose one company that is an expert in CMS, one that specializes in the mechanics of loyalty, and another that builds beautiful frontends. The API works with any language and with any interface, so you can choose with whom you build.
You can also choose when you make the switch and how. You don’t need to build the whole headless system in one go and then pull the plug on the monolith and turn the new one on. In fact, the best way to reduce risk and spread cost is to switch one part of the system at a time. You can change the frontend, then the CMS, then the loyalty engine, turning off each part of the monolith in turn. That way, you eventually make the complete switch one service at a time.
This is, essentially, the “Strangler Pattern” outlined by Martin Fowler in 2004, which is a tried and tested way of replacing a large system in increments. You kill the monolith slowly but you should see the benefits long before you have completed the entire system switch.