Loyalty technology for the API economy
‘Digital transformation’ has been the buzzword for the last decade in enterprise strategy. The phrase is pleasing to shareholders and may sound exciting to employees, but delivering on it takes time and resources. So, to demonstrate some progress, many organizations have pursued initiatives that are only cosmetic in nature while not truly taking advantage of what digital transformation enables: namely that customer journeys, partnerships, trading ecosystems, etc. can be reinvented to improve the customer experience, while also streamlining operations.
Such ‘digital washing’ (like greenwashing in the context of environmental protection) is also taking place in loyalty, where various vendors claim to be true SaaS platforms or API-centric. However, in reality, many have only started operating their monolithic applications on virtual servers, or exposed a basic API.
Such solutions remain inadequate for enabling the customer experiences that will soon become the competitive standard.
The shift to API-first software is the biggest business opportunity of the digital era, since it allows enterprises to serve customers in a smooth and consistent manner via multiple digital and physical channels, and allows customers to choose how they engage with a brand.
Behind the scenes, ‘API-enabled’ (or ideally ‘API-first’) implies a technical architecture that allows computer systems to interact with each other – allowing each to perform those tasks for which it was optimized – and that most of the systems are relatively independent in how they operate. This means that a system can be added, replaced, or modified without creating a massive project.
Today, companies adopting an API-first technical architecture are outpacing those constrained by legacy systems.
Many companies have flourished over the past two decades because they were not held back by monolithic legacy systems. The next decade will see even more accelerated innovation around the API economy, and those companies that can adapt to constant change will outpace their competitors.
To help businesses on this path, we have decided to share our experience in building an API-centric loyalty platform over the years. We explain how the technology differs from legacy solutions, and how an API-first approach solves the specific business challenges and enables the marketing goals that it was built to achieve.
Hopefully these insights are helpful to other teams pursuing the ability for their systems to be sufficiently open that they can interoperate with most/all other systems in the martech stack.
Features of an API-first loyalty platform
With our latest API version, we set out a challenge to be able to address every use case in loyalty commerce. Thus far, Version 3.0 of our API has been able to support every use case presented by a client or prospect. It took seven years and nearly 30,000 hours of development and iteration to reach this degree of flexibility and comprehensiveness, and we would not wish that painful learning curve on anyone.
Our first- and second-generation APIs were powerful, but not sufficiently flexible to work in any industry or support every use case. Absorbing this complexity was necessary to enable the full range of capability demanded by loyalty teams. As a true API-centric loyalty platform, we strive for services to be utilized in the most efficient manner. Using our API enables clients to maintain full control over the customer experience while allowing the complex loyalty mechanics between systems to be handled seamlessly in the backend.
Along our journey, we discovered that a truly API-centric software platform, which enables this degree of functionality, needs to have the following traits – which are common traits of the best API-centric technology platforms.
The first four of these traits are platform features which relate to how data is shared between interconnecting software. The last two are possibilities enabled by such a platform, which would be significantly more difficult with legacy technology.
1. Simplicity: endpoints optimized for each use case
We designed optimized endpoints for an extensive list of use cases in the loyalty industry.
Where APIs feature in legacy software, they often depend on generic endpoints – which do many things with many fields/variables. This means much more processing logic needs to exist in the applications, and it also forces a lot of unnecessary data to be exchanged in a transaction, which is out of step with increasing data privacy requirements.
So, instead of having a few generic endpoints, Currency Alliance’s API features many endpoints optimized for different use cases. Most of our endpoints require only 3-5 mandatory fields, which enables quick and easy implementation, smoother operation and greater data security.
2. Flexibility: sector agnostic
Various loyalty systems have been built over the years specializing and catering to clients in one sector. When such systems provide an API to connect, they inherently force the requirements of the sector onto any other client. For example, SKU details may be important for a supermarket or a retail chain, but they hold less significance to a telco, a utility, or a gaming company.
‘Normalization’ – a systems design concept that means you break a process or data structure down to its most basic components – is one part of solving such a problem, since unnecessary data can be excluded from such transactions. The result can be great flexibility in adapting to known (or unknowable) future requirements.
But to truly make software sector-agnostic, each company needs control over which data they do want to associate with the transaction. This is particularly important in loyalty, where partners may wish to share specific pieces of data in order to build certain insights. Our API endpoints only require 3-5 mandatory fields to complete a loyalty transaction. However, most endpoints have an additional 3-6 optional fields where additional data about the customer, the transaction, or the partner can be added to enable richer profiling or reporting.
While working with clients in various sectors we observed best practices and standardized our API to be sector-agnostic. Given the pace of change, we highly recommend industry-agnostic design because you never know what new lines of business your company may launch, or what complementary services from partners you may need to embrace.
3. Device agnostic
Customers interact with brands in various environments. Our API provides a means for clients to implement their use case on any device, whether it is their website, payments terminal, mobile wallet, card-linking, POS terminals, middleware, webhooks, via live shopping, social media, third-party marketplaces, etc. The customer truly gets a consistent experience in an omnichannel environment, while operating costs remain minimal.
This is important because the information flow could change from one type of device to another. For example, a website checkout or live TV process could be a single-click, but will often be multiple steps, while POS terminals would like to complete the operation in a single step for operational efficiency. Hence, the API should be designed to allow various devices to achieve the purpose with their preferred information flow.
4. Adaptability: data sharing between partners
Loyalty programs are supposed to enable tailored and targeted forms of customer engagement, via the ability to learn more about the customer in each interaction. As I explain below, in the near future, we anticipate channel partners will recognize the superiority of sharing more customer information with partners so all stakeholders can, together, build more loyalty with common customers.
Some of the mechanisms we designed in our API were to enable partners to share any amount of data about a customer’s transaction. They have total flexibility and control over which information to share. It could be nothing more than the amount spent, or it could be all the SKU detail from a grocery purchase or travel itinerary. The degree of data shared between partners today remains minimal, but we believe this will change as the value of zero party and first party data is increasing so quickly. The benefit of a highly-flexible API is extreme adaptability, allowing the same API to be used for a growing number of use cases with any partner, without the need to build a new integration for each one.
We believe data hoarding is short-sighted. Sharing data will increase significantly over the coming years, as zero-party and first-party data becomes more important, and as partnering brands create real strategic partnerships to better serve customers.
We would also suggest that the data that leads to conversion is the most valuable asset in the ecosystem. If partners share the benefits from effectively servicing clients, they will also be motivated to share customer insight to keep customers from defecting to competitive marketplaces or ecosystems.
Standards have become remarkably important in the past 40 years to enable our increasingly digital world to interoperate. Standards exist in most industries and at every level of the software stack.
This often improves the customer experience. A good example is the ability to connect to the internet and interact with millions of websites developed by others; a better one is the dominance of Apple & Android mobile operating systems which enable really high-quality, interoperable customer experiences to be created economically by brands who want a presence in these ecosystems. Some of that is in software (apps) but there’s also a massive market in devices – cars which use Android Automotive, and smart devices for your home from countless manufacturers which integrate with Android & iOS.
Loyalty systems, however, remain an outlier in how difficult it is for loyalty systems to interact with each other. There is not even an effort in the loyalty sector to set standards. One of the unusual characteristics of the loyalty industry is that over 20 years, tens of thousands of unique loyalty program management systems have been deployed. Some of the vendors have long-since gone bankrupt, but most of those still around have not upgraded the architecture to embrace modern design principles. Unfortunately, this highly fragmented and heterogenous environment will continue.
Of course, Currency Alliance cannot set standards on behalf of the industry, but we are helping standardize how systems can communicate with each other.
Since Currency Alliance believes hybrid environments will exist throughout this decade, we have designed a single API for most loyalty use cases that ‘abstracts’ or shields each partner from the complexities of those other systems deployed among partners. When a partner integrates any loyalty system with our standard API, we adapt to the system’s connectivity mechanisms so that the brand can collaborate with every other partner to issue, exchange, or redeem the loyalty currencies of every partner. We are effectively a ‘switch’ that adapts to any protocol of partner systems.
6. Web 3.0-ready
Currency Alliance has been working with blockchain since 2016. Our platform is not built on blockchain, but we have deployed some blockchain solutions – for example, with IATA, to facilitate the reconciliation and settlement of loyalty transactions between airlines, hotel groups, and rental car companies.
We are also already working with ‘oracle’ services – which enable the flow of data in and out of blockchains. Currency Alliance also makes all our endpoints available through the API3 Foundation Oracle services so we can further extend collaboration opportunities for our partners that want to experiment in Web 3.0. This may include reconciling and settling via stablecoin cryptocurrencies, trading in NFTs, or offering points/miles incentives in the metaverse.
Loyalty software for the future of customer experience
To see why these technology traits are so important, you need only to reflect on the significant changes that are currently happening in loyalty. These include greater freedoms in redemptions and in exchanging points between loyalty programs, or the ability to engage with the loyalty program on more devices and in more channels.
These changes are reflected in our recent article where we describe how traditional redemption catalogs will become obsolete and will give way to redemption ecosystems. This major evolution reminds me of how History.com puts it –
‘Before there was Amazon.com, there was the Sears catalog.’
…both of which are natural evolutions towards marketplaces which enable greater customer convenience. The most popular loyalty programs in the future will be those that are present across many commercial ecosystems, but rather than the loyalty mechanics operating as additional steps for the customer, they will be embedded in natural customer journeys.
Over the past century, most brands controlled their sales channels with their customers. Today, that may still be 60% true. By the end of this decade, I doubt 20% of total sales will be via channels controlled by the company providing the inventory to the customer.
Furthermore, because brands historically engaged directly with their own customers,
they avoided collaboration with complementary brands serving the same customer. That scenario is changing rapidly. Today, sellers rarely are the entity shipping the inventory, so greater collaboration is required.
Our redemption endpoints are already being used by banks and other loyalty programs to allow their members to spend points with various redemption option providers in a more dynamic marketplace. The optimized endpoints allow for a simplified and secured method of processing transactions irrespective of the redemption provider. Additionally, the flexibility of being sector agnostic means that loyalty programs can partner with providers across various sectors to provide broader redemption options to members. Loyalty programs remain in complete control of their partnerships, product categories, etc. without needing to spend resources on customization and maintenance of different versions of ‘connectors’ to enable collaboration with new partners.
If we look out 10 years in the future, we can say with certainty that important transformations will have taken place – including how we treat the environment, the relevance of the metaverse, and that digital and physical worlds will be much more integrated. More organizations will have virtual workforces, made up of freelancers, but with many more subcontractors/companies in their supply or delivery chain. Strong brands will continue to thrive, enterprise security will be paramount in protecting assets, customers will have infinite choice and low switching cost, and people will do little searching for things since artificial intelligence-based assistants will present us with a few well-considered choices. All we’ll have to do is select what we want.
We don’t yet know whether these evolutions will be largely in place in 2, 5, 7, or 10 years – but what’s clear is that the design of underlying systems will be forced to support more open APIs in order to deliver consistent customer experiences. The importance of the API economy cannot be overstated.
Manish Jindal, our VP of Product and Operations recently said
“I’d like to make an analogy with traditional cars vs electric cars. One approach to designing an electric car is to try to take out the gas engine and fit an electric motor with a battery pack. But the controls of the car remain the same. Another approach is to design the car with the most optimized placement of the battery and electric motor with the updated controls to better utilize the resources. In both scenarios, you will end up with an electric car. But either you’ll end up with a Tesla or a Chevrolet Bolt.”
Consumers are rapidly becoming accustomed to ever greater freedoms and conveniences. In fact, the best experience a customer receives from any supplier often becomes the experience they expect from every supplier. You can see this in the rise of marketplaces such as Amazon and Rakuten, super apps such as WeChat, and in how many other brands are evolving their ecommerce sites into multi-vendor marketplaces.
Development times for innovations around new customer experiences, in new channels, on new devices, and in the marketplaces where customers spend more of their time, need to be days or hours – not months – and to cost as little as possible.
True API-first, SaaS solutions are built for this future. The providers of legacy solutions know this – so it’s no surprise to see them using the same language and making cosmetic changes to their systems which they can pass off as API-first SaaS.
As you choose the components of your technology stack, be sure you evaluate the comprehensiveness and flexibility of the APIs. They will end up being more important than the fancy features shown in a demo.
As the loyalty industry moves through this transition to an API-first architecture, it is important that the buyer beware of what they are really getting.
This article was first published by Currency Alliance. Permission to use has been granted by the publisher.