How to: update a template

Learn how to transform a library template to a different use case

The library provides a range of knowledge maps for different decision patterns and use cases. These can be transformed to alternative use cases through some simple updates to the knowledge map.

This article will show you an example of this, by transforming the bank account recommendation map into one that recommends insurance products.

Bank account recommendation

This map recommends a bank account to a customer based on a set of properties, including the features of the bank account required, the customer demographic, documentation requirements and considers other properties of the customer such as age.

Bank recommendation template

Insurance product recommendation

We are going to transform the bank account recommendation map so it recommends an insurance policy to a customer based on the features required of any policy, the customer status and documentation requirements.

Bank account recommendation template transformed to an insurance policy recommendation map

To perform this change, we will just be updating:

• 3 concept names

• 6 relationship names

• 10 concept instance names

• Review 10 facts and update where necessary

• 5 rules

Select the bank recommendation template

To begin, login to the Studio, open the library and select the bank account recommendation template.

Update concepts and relationships

We will start by updating the concepts and relationships where required, so the map looks like the image above.

The considerations about customer demographics are changing to customer status, so let's start there.

Update the concept of Demographic to Customer Status, then change the adjoining relationships to (Customer) has status (Customer Status) and (Policy Type) recommended for status (Customer Status) .

Date of birth and age are not relevant in this example, so we can update these to:

1. (Customer) has onboarding date (Date)

2. (Customer) has number of months insured (Months Insured)

Finally, we can change the concept of (Bank Account) to (Policy Type) and then edit the names of two of the four relationships between Customer and Policy Type:

1. recommend based on demographic becomes recommend based on customer status

2. recommended bank account becomes recommended policy

The map should now look the same as the image above.

Next we will update the data that is stored in the knowledge map.

Update concept instances

Some data stored in the map describes the bank account products, the features a bank account might have, the demographic categories and documentation requirements.

We will adapt these to be specific for our insurance policy recommendation use case.

The bank account products are called bronze, silver and gold and we will keep these for our policy types, no change is required here. However the features will differ, so let's update these.

Open the Features concept and edit the concept instances from mobile phone insurance, vehicle breakdown cover & overdraft to no excess, additional policy discount & third party benefits app.

Updated instances on the Features concept

Now, let's change the instances on Customer Status to make them more relevant. After editing the four existing instances, you should have Onboarding, Recently Onboarded, Steady and Tenured.

Updated instances on the Customer Status concept

Finally, we will update the Documentation concept to change the three instances to Proof of Address, Proof of NCD (No Claims Discount) and Government Issued ID.

Updated instances on the Documentation concept

Next we will update the facts in the map.

Update facts

Some of the instances we have just updated are connected together to establish known facts that support decision-making. For example, the Gold bank account product will be connected to the features it provides, the documentation required and the demographic it best suits.

These need to be reviewed and amended to ensure the features, customer status and documentation requirements are correct for each policy type.

Open the Policy type concept, then select one of the instance (e.g. Bronze) to review and modify the facts associated with it. Below shows an example of this after it has been updated.

Review the facts for each policy type and modify where required to be the following:

	requires documentation	provides features	recommended to status
Bronze	-Proof of Address -Proof of NCD (No Claims Discount) -Government Issued ID	-Additional Policy Discount	-Onboarding -Recently Onboarded -Steady -Tenured
Silver	-Proof of Address -Government Issued ID	-No Excess -Additional Policy Discount	-Recently Onboarded -Steady -Tenured
Gold	none	-No Excess -Additional Policy Discount -Third Party Benefits App	-Tenured

Next we will update the rules.

Update rules

In order to ensure the right recommendation is made, we will tweak some of the existing rules to correctly infer facts based on the data provided at runtime.

Calculating age adapted to calculating months insured

On the bank account recommendation map, a rule inferred the customer's age based on their date of birth. However, these have been adapted to the onboarding date and the number of months insured.

The only change required is to ensure we are calculating the months between the onboarding date and today's date, instead of years.

Open the 'has number of months insured' relationship, select the rule and change yearsBetween to monthsBetween and update.

Rule to calculate the number of months insured, based on the customer onboarding date. The only change required is underlined.

Determining customer status based on months insured

The final set of rule updates relate to the categorisation of the customer, based on how long they have been a customer.

These rules were previously using an age to determine an age demographic. Now they are using a number of months to determine a customer status, so the expression just needs to be updated to correctly reflect how each customer status is determined.

Open the relationship 'has a customer status' and you'll see there are 4 rules, one for each customer status.

'has a customer status' rules

The rule for onboarding will look like the following:

In this use case, we want to say a customer is classed as 'onboarding' if they've been insured less than 1 month. Therefore amend 16 to 1.

We will leave the variable name of %AGE, but you could change this to %MONTHS_INSURED for improved readability. If doing this, it must be done in both places, like the example below:

The remaining rules can be updated to the following:

	From	To
Onboarding	lt 16	lt 1
Recently onboarded	lte 20	lte 12
Steady	lte 60	no change
Tenured	gt 60	no change

Update question text

The final change is to ensure the question text is correct. Running a query on the relationship (Customer) recommended policy type (Policy Type) will allow you to preview the questions asked.

Based on the changes made, there is only one question that needs to be updated so it asks about the customers onboarding date, instead of their date of birth.

Open the relationship 'has onboarding date', expand the question section and change the question of What is the (Customer)s DOB? to What is the onboarding date for (Customer)?

Updating question text

Query updated knowledge map

You can now test these changes.

To get the overall recommendation, query the (Customer) recommended policy (Policy Type) relationship. This will consider features, customer status and documentation.

To test each factor separately, you can query the recommend based on features, recommend based on customer status or recommend based on documentation relationships.

Extending the knowledge map

This is of course a simple example of a recommendation, taking into account only a few factors.

This could be extended with additional factors, such as the value of insured assets, location or previous claims, matching these factors to insurance products and extending the recommendation rules to incorporate this new data.

Why not try extending this yourself? Or adapt a different library template to your own domain?