Digital Customer Experiences Using Smart Contracts

Digital Customer Experiences Using Smart Contracts - Part 2

by Manish Grover November 11, 2020

In my last blog on Enhancing Digital Customer Experiences Using Smart Contracts, we looked at how customer preferences management can be dramatically simplified using smart contracts. A smart contracts based approach avoids customer preferences management to be treated as an add-on or external database (even if it physically is). This avoids costly reconciliations and process breaks due to data mismatches.

Today I’m going to build on that premise and discuss how we can streamline the management of customer preferences across multiple companies. This will lead to creation of cross-industry and cross-company customer experiences, while improving operational efficiency and promoting customer privacy. This is different from a business process such as supply chain or trade finance being executed across companies. Our focus here will be on digital and personalized customer experiences.

The motivation for this post is quite simple. Customers are demanding extreme personalization, the digital revolution is causing tough competition on pricing so differentiating and delivering value through engagement is paramount, and time to market for innovation is becoming a critical enabler of business success or even survival. The collaboration model using DAML outlined in this post can help meet all these goals.

This post is relevant for those who are presenting a business partnership to customers (e.g. co-branded credit cards, airline loyalty programs). This post is also relevant to those who would like to present such a face to their customers but have been unable to do so because of the associated technological and business process complexity (e.g. multiple complementary retailers as in the ill fated Amex Plenti program).

Examining the problem

In the previous blog post, we considered the example of a credit card company managing customer preferences across its card products and business divisions.

This time let’s take the example of a fitness center and an insurer who would like to create mutual business benefits:

Less insurance claims ( insurer)
More and longer fitness subscriptions (for fitness center)

At the same time, this partnership benefits the customers in multiple ways:

Discounts on insurance
Personalized fitness goals
Discounts on fitness subscriptions.
Seamless subscriptions to 3rd party services such as supermarkets, nutritionists etc

I’ve written about this actual business partnership before if you are interested to learn more. These kinds of customer experience ecosystems will become a norm of the future, so in this post I’m describing how we could accomplish this more simply using DAML, remove reconciliations, and also make this a scalable ecosystem whose membership can grow or shrink on demand.

The first couple of problems you encounter when thinking about such an ecosystem can almost cause you to give up on this ambition. So far there hasn’t been a way to do this using technology that is specifically meant to solve exactly these problems.

Inviting independent participants to an ecosystem
Allowing customers to receive uniform experiences as they engage across this ecosystem
Maintaining privacy of customer data between participants
Eliminating back and forth data transfer and reconciliation between participants

But lets see how a DAML enabled ecosystem can make this a breeze while maintaining privacy and confidentiality of each party without having to do anything more like the below. The overall business process view looks like the below:

representative customer experience flow (enables a single golden source of data while maintaining privacy - eliminating data reconciliation and mismatch, allowing a common view of the business process, making compliance and audit easy) — Representative customer experience flow (enables a single golden source of data while maintaining privacy - eliminating data reconciliation and mismatch, allowing a common view of the business process, making compliance and audit easy)

Onboarding Participants

We have 3 types of participants at least but of course we can make this solution extensible if it is intended to be a platform.

Customers can be registered from a campaign by creating a customer registration record that they can accept. That allows us to assign other parameters on the underlying customer record. I’ve assumed a single insurer and a single fitness center at this time. I’ve assumed that someone has been designated with maintaining the ecosystem and deciding who should be onboarded. In a closed network, this role can be assumed by either a consortium or one of the participants. The model can also be made more generic to handle different types of entities.

Note on enterprise adoption: The DAML smart contracts based workflow outlined below is exposed through standard REST APIs. Current web, mobile and other applications can continue to function in the usual way with the underlying workflow and a golden source of data being managed by DAML as per the modeled privacy requirements.

	template Ecosystem
	with
	operator: Party
	where
	signatory operator
	controller operator can
	nonconsuming InviteParticipant : ContractId ParticipantInvite
	with
	participant : Party
	do
	create ParticipantInvite with ..

	template ParticipantInvite
	with
	operator: Party
	participant: Party
	where
	signatory operator

	controller participant can
	AcceptInvitation: ContractId ParticipantRole
	do create ParticipantRole with ..

	template ParticipantRole
	with
	operator: Party
	participant: Party
	where
	signatory operator, participant

	controller participant can
	nonconsuming InitiateCustomerRegistration : ContractId CustomerRegistration
	with
	customer: Party
	insurer : Party
	uniqueId : Text -- e.g. email address
	do create CustomerRegistration with participant, customer, insurer, uniqueId

	template CustomerRegistration
	with
	customer: Party
	participant: Party
	insurer : Party
	uniqueId: Text
	where
	signatory participant

	controller customer can
	AcceptTerms : ContractId CustomerRecord
	do create CustomerRecord with ..
	template CustomerRecord
	with
	customer: Party
	participant: Party
	insurer: Party
	uniqueId : Text
	where
	signatory customer, participant

view raw ecosystem_1.hs hosted with ❤ by GitHub

One of the goals of this partnership is to share healthy practices adopted by the customer with the insurer. This will allow the insurer to do things such as reducing premiums, reimbursing fitness center fees in part or full, and compute the business value of such a partnership. On the other hand the fitness center can do the same.

We do this by allowing the fitness center to send the information on customer visits to the insurer. This is done with customer consent of course. This consent can also be revoked at any time (not shown).

A single underlying customer record allows both insurers and fitness centers to do so.

	template CustomerRecord
	with
	customer: Party
	participant: Party
	insurer: Party
	uniqueId : Text
	where
	signatory customer, participant

	controller customer can
	nonconsuming VisitCenter : ContractId CustomerVisit
	with
	fitnessData: FitnessData
	do
	create CustomerVisit with customer, fitnessData, participant, insurer
	template CustomerVisit
	with
	customer: Party
	fitnessData: FitnessData
	participant : Party
	insurer: Party
	where
	signatory customer

	controller participant can
	Verify: ContractId CustomerFitnessRecord
	with
	participantId : Party
	do
	-- store this visit against the month/year combination
	-- Send the data to insurer
	create CustomerFitnessRecord with insurer, fitnessData, participant, customer

	template CustomerFitnessRecord
	with
	fitnessData: FitnessData
	insurer: Party
	participant: Party
	customer: Party
	where
	signatory participant

	-- controller insurer can
	-- DoSomething : ContractId Something
	-- do
	-- create Something with ..

view raw customerrecord_2.hs hosted with ❤ by GitHub

Personalizing the Fitness Experience

Being part of an ecosystem, it is expected that the insurer may want to personalize the fitness goals that the customer should act upon. These goals could be preventative based on the customer’s risk profile, or required to achieve full recovery from something that has already occurred. In the past this has been laden with privacy risks, and data storage compliance issues. With DAML all that is simplified.

The customer will simply allow the insurer to attach already existing health goals. These goals can then be viewed by the trainer at the fitness center and deliver truly personalized fitness. Such a model can also evolve into an accountability model for each party - customer, trainer, fitness center and insurer.

	template CustomerRecord
	with
	customer: Party
	participant: Party
	insurer: Party
	uniqueId : Text
	where
	signatory customer, participant

	controller insurer can
	nonconsuming ProvideHealthGoals : ContractId CustomerHealthGoals
	with
	healthGoals : HealthGoals
	do
	create CustomerHealthGoals with customer, healthGoals, participant, insurer

	template CustomerHealthGoals
	with
	healthGoals: HealthGoals
	customer: Party
	insurer: Party
	participant: Party
	where
	signatory insurer

	-- controller participant can
	-- nonconsuming DefinePersonalizedFitness : PersonalizedFitness
	-- do

	-- controller customer can
	-- EditFitnessGoals : CustomerHealthGoals
	-- do

view raw customerrecord_3.hs hosted with ❤ by GitHub

Expanding the ecosystem

As you may have guessed we can extend this ecosystem to other parties as well. For example, we may want to onboard nutritionists to help develop the health goals, or a supermarket to offer discounts on the right food etc. We may also onboard local marathons and other sports apparel retailers to further personalize this experience.

In the end, not only does the customer win, but so does every party who is part of the ecosystem. We can say goodbye to blind mass campaigns, and truly personalize the experience through cross-industry customer journeys.

DAML has also a new learn section where you can begin to code online:

Learn DAML online