Loyalty is important for all businesses. The propensity for repeat purchases is driven by many factors. These could be emotional, like brand affinity or premium status, or tangible benefits, such as discounts based on purchase behavior.

In this blog, we will examine how to extend a typical loyalty program to multiple parties so that a business ecosystem may be created. Multi-partner loyalty programs increase customer engagement and spending. We will also see how to reduce the technology and operational complexities of running such a loyalty program by using Daml smart contracts. As you will see in this post, Daml is a powerful platform to create these multi-party workflows while being extremely simple to read and understand. 

The multi-party loyalty use case

Let’s consider a simplistic loyalty program comprising two businesses: a fitness center and a grocery store. Each business offers customers discounts against purchases.

In our use case, each business also has the power to have those points redeemed at the other business. This kind of collaboration is logical—a fitness center will want to incentivize customers to buy healthy foods, and a grocery store may want to help customers meet their aspirations, thereby altering their grocery lists in a win-win for both parties. 

Moreover, this arrangement also creates a customer experience that typical loyalty programs do not provide today (with the exception, perhaps, of airline miles programs, to some extent).

The problem

As may already be obvious, creating this kind of collaboration between two entities is not trivial (creating a bridge to exchange data reliably and in a timely manner being one of the challenges). We also have the issue of data privacy: traditional technology creates data silos (at either business), and over time, keeping these silos in sync becomes a program of its own. 

In addition to data and privacy, we also need to keep the business rules in sync. When the parameters change, they must be made available to the software programs at either business, and must go through elaborate change management depending on how they are deployed.

Finally, we run into one of the most challenging problems of all: managing customer identity. Customers at either businesses must always be kept in sync, using some kind of an identifier. Even if it is something like a phone number or email address, these can easily be changed, potentially leading to reconciliation issues.

Typically, the concept of a multi-party collaborative model looks like this: two infrastructures kept in sync through data transfers, separate business process implementations, and constant reconciliations, causing a disjointed customer experience.

A Daml-based architecture for multi-party loyalty programs

To solve these problems of data and process islands in legacy architectures, Daml emerges as a good choice to integrate the customer experience across enterprise and department boundaries. 

1. Daml solves the problem of data silos because each transaction is automatically made visible to each party that needs to have access. No data transfers are required.
2. Transaction privacy between each business is automatically applied, because Daml allows sub-transactions to be shared—specifically suited for sharing between businesses and thereby alleviating regulatory concerns.The changing regulations and customer preferences are necessitating a focus on first and zero party data, which require privacy and reporting to be facilitated more easily.
3. The business logic is maintained inside Daml smart contracts. This ensures that any change to the rules can be applied in a single location and made available to both businesses. This solves the problem of the common business logic being distributed across multiple entities and creating a complex, change-management dependency.
4. Finally, the Daml smart contracts engine exposes APIs based on the business logic. No API management complexity needs to be handled, leading to simpler technology architectures.

It must be noted that deployment complexities and the need for physical separation of data is addressed because multiple businesses can either share a cloud deployment with logical segregation of data (same cloud DB), or have completely independent databases on two different clouds. However, the two datastores are automatically synced by Daml, thus eliminating reconciliation needs and pushing the complexity under the hood.

Here’s what a Daml-based architecture that provides a golden source across enterprise boundaries looks like.

We’ll demonstrate the overall business process as represented below.

1. When a customer is onboarded, the participating business partners are also onboarded to the same customer contract. (In this case, when the fitness center gets a new customer, they can get the grocery store on board.)
2. When a customer transaction occurs, the business where the transaction occurs can issue the loyalty points. They can also choose to send a subset of the details to the loyalty partner. This ensures the privacy of both the customer and of the business transactions.
1. For example: The customer signs up for a Fitness360 plan for $49.99 a month, with an annual contract. The fitness center can send the following details to the grocery store: Fitness360 plan. No explicit data sharing is needed, privacy is ensured, and compliance needs are easy to meet.
3. Customer transactions can occur at either business, and either business can issue loyalty points that are visible to the customer in a central place—no need to collate multiple data sources for this unified customer view.
4. Privacy of loyalty points is also maintained. The customer has access to all of them, and each business only knows which points they issued to the customer.

How customer onboarding occurs

When a customer signs up at either the fitness center (business1) or the grocery store (business2), they are created within that business per their current process. 

In addition, they are also created using the provided Daml APIs in the new, multi-party loyalty platform. A shared Daml customer contract is automatically created, which has only the data elements that both businesses should be allowed to see, per the agreement with the customer. That way, the privacy of the customer is preserved. 

This is what Daml looks like when the customer requests to open an account:

A Daml contract called OnboardingRequest is created. The customer is the signatory—the Daml way of saying that the customer has an obligation to honor the contract. On this contract, the business can accept and create the customer contract. They can also notify the right business partners for everyone to have access.

To do that, we add a right called ProcessApplication on the OnboardingRequest. Daml controls who can access this right with the keyword controller. In this case, the business to which the customer requested to be onboarded has the right to complete the onboarding.

As you can see, the network partner is also notified, so they have access to the resulting contact called CustomerContract.

All three parties now have access to this contract; the customer and the original business are the signatories. We could also create an approval process for business2, but for the sake of simplicity, we’ll not show it here.

The customer has the right to SpendMoney, which triggers the issuance of LoyaltyPoints and also a PartnerNotification by the business where the spending happens.  

Since actions (choice) in Daml have what are called controllers, only the specific parties can take a specific action. So, a choice that allows the fitness center to update the fitness routine of the customer cannot be executed by the grocery store. This leads to tremendous efficiencies in the way rights amd obligations are managed. The complexity is abstracted away from the developers and baked into the Daml smart contract layer.

Here’s how onboarding and subsequent actions take place conceptually in a Daml-based architecture. As you can see, the smart contracts layer simplifies maintenance of a golden source. No more reconciliations are needed.

Conclusion

Loyalty is an important driver of customer engagement. As the demand for new digital customer experiences increases, collaboration between businesses favored by the customers promises to be an important driver of growth and engagement. With Daml, multiparty collaboration is simple and flexible—and enterprise grade. Read more here to see how Daml promotes this while maintaining privacy and interoperability.

Have you checked out  our new Wallet Sample App?