by Manish Grover
August 18, 2020
In today’s connected world, personalization and context drive modern customer experiences and improve both retention and acquisition rates.
In this blog I will try to outline some of the challenges that enterprises face as they strive to provide these experiences, and how they can address them with an approach that uses smart contracts.
In the most basic scenario, web developers can build on the reference Daml models outlined in this blog to execute their personalization strategies in their web applications. This use case also validates that the ROI of a smart contract based approach can be immediate.
About Daml Smart Contracts
First, just a quick overview of Daml. It is a purpose-built smart contracts platform aimed at creating multi-party workflows with strong privacy, rights, and obligations guarantees. Daml applications can run on multiple DLTs / blockchains and databases without requiring any changes (write once, run anywhere). You will use your favorite programming stack (React, .Net, Java, Python etc.) to work with the Daml smart contract layer.
As we’ll see in this blog, use of Daml allows multiple enterprise applications and business entities to mutualize their business processes, thereby minimizing reconciliations and disruptions caused due to data quality issues.
Daml uses the concept of “parties” to represent actors which can be individuals or entities. The disclosure and distribution of data is controlled by the roles these actors play. Actors can have rights (can take actions), be obligable (are accountable for the data they create), and be observers (they can see but not have any obligations or rights).
Since the workflows we define in Daml can run on databases and blockchain alike, developers and business analysts need not think about the underlying platform intricacies. They can instead focus their energies on defining the business logic, which will automatically control the distribution and disclosure of data that the workflow generates. Using a chess analogy, focus on winning the game, not on negotiating the rules and setup of the board.
With that introduction out of the way, lets see how we can enhance digital customer experiences using Daml.
A conceptual maturity model for digital customer experience
As we think about personalization and context driven experiences, we often have to tackle the deluge of data coming from all over, decide what is important, and then take meaningful action over numerous channels. It can be overwhelming to think about the abundance of interactions taking place.
It is often helpful to break down the problem into a model that can then be tackled piecemeal to drive incremental results and test them. Here is a framework that I came up with to help with my thought process. Needless to say, I’m sure you will need to tailor and customize this framework for your enterprise. Some of the concepts here are based on principles 2 and 4 of my book Connected! (reference 2 at the bottom if you’re interested).
We can see from this model that customer information and preferences can be categorized into the multiple levels on the left. At the bottom are narrow product related relationships (e.g. e-statement preference for a credit card), at the middle level they span an organization’s relationship with the organization (e.g. customer LTV across products), and finally at the top is information that is driven from the ecosystem (e.g. customer relationships and behaviors across co-brand partners).
On the right of the model we can see the inbound and outbound interactions that affect the information on the left. To manage this complexity of so many data sources, enterprises look to create customer data platforms. These platforms aim to integrate and consolidate customer experience in a single place so that it can be actionable and easily managed.
Although it seems simple in principle, maintaining customer preferences and information efficiently is a huge challenge for most enterprises given the complexity of the enterprise technology landscape, the many channels that customers can use today, and many different products & geographical locations that must be considered.
At the same time, management of customer information and preferences also poses a compliance challenge. Due to regulations such as GDPR, it is important to ensure that we know exactly what customer information and preference is captured, who updated that information, who is using that information, and whether we are complying with the data usage and disposal requirements.
An Approach Using Daml Smart Contracts
Smart contracts provide an efficient and practical way to manage this complexity and make it more streamlined for enterprises. Just as cloud computing simplified provisioning and management of infrastructure tremendously, smart contracts help with managing multi-party business processes, and ensure that the underlying data being accessed by each application or entity is consistent and auditable.
In this part of this blog series (part 1), let me show you how Daml can ensure that updates are only permitted by the designated party, how an automatic audit trail is created, and how personalization can be easily driven.
Let’s walk through this journey taking a hypothetical example of a credit card company. Every customer can have multiple preferences. These preferences can range from what can be sent by email, whether they have opted out of marketing emails, have they signed up for daily balance alerts by email, and so on. The customer will also have a name and other such profile information. For simplicity I have limited the data structures used in the sample below.
Every user has a role. So when a new customer signs up with a credit card, we send them a role invitation.
Customers have a right to accept or decline. In our case below, when they accept the terms and conditions we present to them, they confirm their role assignment.
At the same time, a separate Daml contract that contains the profile of the customer is created. This construct also allows easy integration with SSO (Single Sign On) and onboarding processes.
It’s clear that the role and profile contract cannot be created by anyone other than the customer. And there is always a ready made audit trail that is available for reference. We could make this “event” visible to others to meet business process requirements. For example, the compliance department may need to know which new customers have been onboarded. For that Daml smart contracts provide a ready-to-use construct. The users of the compliance department can simply be made “observers” (see reference 3) on a contract created during the onboarding process.
Now that we have the CustomerProfile contract, we can specify actions that customers can take to update their profile information. Every time, the profile is updated, an automatic audit trail is created because the old contract is archived, and a new one is created.
In our example, only the customer is able to update their profile information. However, in many cases, it may be required for the customer service representative to be able to do it on behalf of the customers. In that case, we could temporarily delegate the authority to the customer service representative. An appropriate audit trail is also created.
Effective Personalization & Profile Management
Since the CustomerProfile contract is unique to a customer, all web and mobile properties can retrieve this contract once they have authenticated the user. Using this profile contract, channels can create a personalized customer experience.
Due to the unique properties of Daml smart contracts, common errors with customer data getting mixed up are not possible to make. In addition, any application can be sure that the customer profile they are receiving is the latest because all applications and channels are updating the same customer profile contract. I’ll cover more on this topic (and the schematic below) in Part 2.
As you can see from the above schematic, the enterprise technology architecture guidelines can still be maintained. Use of smart contracts does not mean that we do away with messaging and collaboration architectures. It just means that we redefine the endpoints and streamline the data movement. I’ll cover this also in more detail in part 2 of this blog series.
Summary
The Daml model outlined above can be used in the short term to achieve personalization and context driven experiences on all smart contract enabled customer facing channels. This is also a very efficient way for any organization that has a need to maintain customer preferences and currently has to synchronize multiple customer preference databases. It must be noted that since Daml runs on blockchains and databases alike, using smart contracts does not imply the use of a DLT or blockchain based ledger.
Creating personalized and contextual customer experiences are a must for enterprises in an increasingly connected and digital world. Customer data platforms are a common approach taken by enterprises to manage the many dimensions of data that are coming in from different channels, both internal and external. A smart contract based approach using Daml is a great way to simplify the complexity of organizing this data so that the benefits of a customer data platform can be maximized. Daml has also a new learn section where you can begin to code online:
References:
