Custom loyalty system for one of the biggest insurance providers in Australia in just 3 months?

Our client, an insurance company in Australia and New Zealand, needed a tailor-made loyalty engine that could be quickly implemented on their on-premise servers for data protection. In this article, we discuss how we managed to build a dedicated loyalty system customized for the client’s needs in just three months. We wanted to showcase the technicalities and our approach to this exciting challenge. Let’s go!

Care to share?

Why we were approached by Open Loyalty

One of the main insurance companies in Australia and New Zealand came to Open Loyalty with a request to create their new custom loyalty solution. They knew it would be an interesting and demanding project because this company has been on the market for over 100 years and underwrites more than $10 billion of premiums yearly.  The client required a platform that would be scalable and able to provide service to numerous customers.

Looking for an on-premise and customizable loyalty solution, their main requirement was simple yet challenging: adjusting the system to their specific business and technical goals. Not many loyalty solutions could be customized to that extent. When they stumbled upon Open Loyalty, they knew it was the solution for them.

So, the Open Loyalty team approached Divante asking for assistance. We analyzed the brand’s list of needs and pains, and the conclusion was crystal clear. A high level of customization was a must. We recommended that to the client, and they agreed because they wanted the final product to be tailor-made to their assumptions. That’s why our Custom Solutions department was asked to collaborate on this project. We were able to adjust Open Loyalty to the client’s expectations and implement it as a robust, complete platform. The project began.

The beginning of the collaboration

The client required a fully customizable, scalable, and secure loyalty engine hosted within their online ecosystem. Their project scope also included many customizations that were implemented by the Divante team. The collaboration began with gathering requirements. Then, we started the “must-have phase” that lasted for three months.

Organizing the work

The team tasked with delivering customizations consisted of a front-end developer, a back-end developer, a tester, a lead developer, and a project manager. The team worked in Scrum methodology. Each two-week sprint began with product backlog refinement and sprint planning. During sprints, the team discussed progress, challenges, and other matters during stand-up meetings. Each sprint was concluded with a demonstration for the client. Because we implemented agile, the work was well planned and executed. The team was able to deliver usable functionalities from the very first sprint. It also facilitated prompt feedback from the client.

Working with the code

The development team employed the git-flow model of working with the code repository. Each task from JIRA was given a separate feature branch in it. Once the feature branch was ready, it was reviewed by other team members. After all suggestions and questions were resolved, the feature branch was merged into the develop branch. At the end of each sprint, a release branch was created from the develop branch. This approach facilitated parallel development and collaboration.

Environments

In this project, there were three environments used:

  1.  “Local” is a volatile environment set up on each developers’ computer.
  2.  “Dev” is an environment used mainly by the tester to check individual tasks. This environment was updated several times during each sprint, usually when the develop branch was updated.
  3.  “Stage” is an environment used to showcase entire releases. It was typically updated at the end of a sprint. This environment was made available to the client for hands-on experience and early integration tests.

The “local” environment was set up using Docker, and both “dev” and “stage” environments were set up in a Kubernetes cluster.

Customizations

The client needed the following customizations:

  1. Ability to register customers with either an email address or phone number as a unique identifier.
  2. Ability to specify the points for locking date and expiration date for each transaction or point transfer individually.
  3. A new type of earning rule that subtracts points from the user’s account instead of adding them.

All these modifications required significant changes in both the administrator’s interface and underlying API. Functional tests fully covered the customized code.

Customizations in detail

The first customization was fairly easy to implement since Open Loyalty internally supports both types of unique identifiers. The only thing left was modifying API endpoints related to customer registration so that it could accept any of the two identifiers and return an error if both were missing. The admin interface had to be adjusted as well to show that either an email address or phone number is required and display an appropriate error message if both are missing.

Implementing the points locking date per transaction and the points expiration date was a back-end-only change. Two additional parameters were added to the API endpoints related to adding transactions and points transfers. These parameters were made optional to maintain compatibility with unmodified Open Loyalty and allow greater flexibility in using the API. If any of these new parameters are missing, generic system-wide settings will be used instead. These two additional parameters were also added to the XML file schema used to bulk import transactions.

The biggest change in this project was implementing so-called “burning rules.” These can be, for example, earning rules that subtract points from the user’s account instead of adding them. Earning rules is a complex mechanism. There’s a lot of business logic associated with them, like for example, regarding the order in which they are executed, reversing transactions, or partial returns. All this logic had to work correctly for burning rules and maintaining compatibility with unmodified Open Loyalty. To achieve this goal, numerous API endpoints had to be modified.

Challenges and how did we conquer them

During the project, the team encountered a few difficulties mainly related to earning rules. For example, burning rules were initially designed to be a separate mechanism from earning rules. However, during implementation, it turned out that it required either duplicating large parts of code or refactoring them to enable reuse. The benefits of this approach were outweighed by the complexity and amount of work needed. Thanks to agile project management, this obstacle was quickly overcome by redesigning the initial solution. An example of this was extending earning rules with “burning” logic.

Because we were working agile, a few minor customizations were added to the initial scope. One of them was the ability to choose visible columns in tables, which improved the user experience of the admin interface.

To make sure everything was running smoothly, we recommended that the Open Loyalty engine should be installed on AWS with Kubernetes. Cloud solutions are perfect for such projects because they offer excellent scalability and convenience when it comes to access. Also, they’re great for lowering costs because the client doesn’t need an on-site data center.

We prepared dedicated architecture that made it possible to enable each of the elements of the loyalty system.

The result: A customized loyalty solution based on Open Loyalty

When the implementation took place, the insurance company had 30,000 customers introduced to the loyalty program built by the Open Loyalty and Divante teams. The client’s expectations for the upcoming years are for this number to grow significantly. The solution was released in December 2021. Key outcomes of this project are:

  • The client got a dedicated, tailor-made loyalty platform based on Open Loyalty that was integrated with their internal IT environment.
  • The Custom Solutions team from Divante created the above mentioned customizations, which made the client’s system unique and adjusted to their needs and goals.
  • We managed to prepare the whole infrastructure with customization in just three months. This was a challenging time frame but necessary for the client’s business to run smoothly.
  • Our team also provided recommendations for scalable infrastructure based on AWS with Kubernetes. 

Final thoughts

Customer loyalty is crucial for most businesses. When the competition is fierce, and it always is, brand owners wonder how to improve their services and keep every client. It doesn’t only apply to eCommerce but also to other industries, including insurance providers. Open Loyalty was implemented for such prominent players as ALDO, MSI, and Warba Bank. They appreciate its fast time to market, incredible customization possibilities, and developer-friendliness. Thanks to these features, the product became a universal solution for companies who want to provide even more value for their audience. If you want to join them, don’t hesitate and let us know what your loyalty needs are. We will gladly help you achieve them.

Published March 29, 2022