Strategy Crafter Tutorial 2

Guest-Authored by Barry Nelson, Salesforce, this tutorial builds upon the first NBA Tutorial.

Return Home

Building a Strategy

Let’s walk through all the steps involved in establishing and deploying an example Strategy. There is a Tutorial available here which involves setting up a very simple “Happy Birthday” strategy. It’s worth checking out as an introductory primer but the resulting strategy is too simple to fully illustrate the concepts you’ll need to understand in order to actually sell this thing, so below we’ll walk through setting up something less basic, because SEs love fiddling with things, right? Right???

Click on the App Launcher and open Strategy Crafter.

Ooooo, pretty. Although yours looks nothing like that right now. That’s because you haven’t built a Strategy yet! And as a good SE, surely nothing gives you more delight than a blank canvas, right? Right?????

We’ll walk through building your first Strategy now. Bear in mind, when it comes time to build your own, you’ll definitely want to plan it out in advance before you do any of the build steps further below. Much in the same way we separate Solution Design and Solution Build into separate steps, so should you separate Strategy Design and Strategy Build/Craft into separate steps. So let’s start with a scenario and use that to deduce what our resulting strategy should look like.

the scenario

Cirrus Harbor Cruises and Demo Widgets wants to better equip their Support organization to facilitate cross-sell/upsell opportunities. They’ve gone down this road in the past but it turns out that while their Support agents are really great at troubleshooting, they’re really horrible at recognizing when a good opportunity to engage in selling activity has materialized. Moreover, there have been limited instances of success dealing with at-risk customers by offering discounts, but only a few Agents seem to have a knack for doing this right — Cirrus doesn’t want their reps tossing lucrative discounts around to already perfectly satisfied customers!

Rather than spend scads of money on re-training their Support organization, Cirrus is going to leverage the power of CRM to proactively guide Agents towards the right offers and responses to inbound customer interactions. This is going to be awesome!

First, Cirrus wants to make sure that product discounts are only offered to customers who are at risk of attrition. Cirrus’ Marketing organization has recently leveraged Einstein Prediction Builder to assign a relative Attrition Risk to all of Cirrus’ current accounts. This data will be useful in building a Strategy.

Second, Cirrus has learned over time that discounts to current services are far more effective in retaining smaller customers, whereas larger customers respond more favorably to service expansions, premier service offerings, etc.

Third, Cirrus doesn’t want to offer any sort of discount to a non-attrition risk customer. To these customers, Cirrus will exclusively default to standard Troubleshooting.

configuring propositions

In order to make our Strategy work, we start with Propositions. Propositions are the actual offers we will be making in response to various customer situations, so in our scenario here, we will have 3 types of Proposition.

But wait! How do we categorize Propositions by type? After all, the Proposition object only has 3 fields: Name, Description, and whatever Action Reference is. Well, let’s change that.

1. Navigate to Setup, and select the Object Manager tab.
2. Type Proposition in the quick find box, and select the Proposition object.
3. Select the Fields & Relationships node. Click New.
4. We’re going to create 2 additional fields: Category and Ranking. We will use these new custom fields to help our Strategy figure out what Proposition is relevant to each customer situation.
5. The Category field should be Text.
6. The Ranking field should be a Number.

Much better. Now, let’s start making some Propositions!

1. Click the App Launcher, and launch Strategy Crafter.
2. Click the Propositions tab, and click New to create a new Proposition.
3. Input the following fields:
4. Name: Discounted Premier Service
5. Description: Offer the customer a discount on Premier Service.
6. Action Reference: PropFlow (we’ll create this flow later)
7. Category: ServiceOffer
8. Ranking: 2
9. Continue creating Propositions per the below List. You should have 5 Propositions in total by the end.
10. For the truly typing-averse, you can download a Data Export CSV of the below Propositions and use the Data Import Wizard to populate these Proposition records.

Okay. Now you have 5 simple but illustrative Propositions in your org. Next, we need to build a Strategy to map these Propositions to specific cases/contacts based on criteria aligned with Cirrus’ goals for this initiative.

add a fake aI field to the account object

Next Best Action is intended to be a great tool for leveraging predicted values from Einstein tools like Prediction Builder. For the sake of demo expediency, to say nothing of sanity, we’re going to fake a simple predicted value and use it in our Strategy. This value determines if a given Account is or is not at risk of Attrition, based on an Einstein prediction.

1. Open Setup, then Object Manager.
2. Open the Account object.
3. Add a new checkbox field called Attrition Risk.
4. Leave all other settings default and save the new field.

We’ll leverage this field in our Strategy. Speaking of which…

configuring the strategy

1. Launch the Strategy Crafter app and navigate to the Strategy Crafter tab.
2. Click on the gear thingy to the left of the “Select a Strategy” dropdown, and click New Strategy.
3. Input the following values:
4. Unique Name: SupportSales
5. Label: Support Sales
6. Description: A strategy to help Support support Sales.
7. You’ll then be presented with your newborn Strategy, waiting to be told what the heck to do by its maker. That’s you, by the way.

The orange box that says “WinningProposition” is what’s called a Node. This particular Node is a Combine node. A Combine node takes Propositions from multiple sources and combines them into a list. This particular Combine node provides the list that is ultimately presented in the Einstein Recommendations Lightning Component to the agent.

Let’s start by loading the Propositions we created earlier into this Strategy.

Loading propositions

1. Right-click on the WinningProposition node, and select Add Child Node.
2. In the modal, input the following:
3. Unique Name: LoadProductOfferProps
4. Description: Loads Propositions with Category = ProductOffer
5. Node Type: Load Propositions
6. Formula: Category__c = ‘ProductOffer’
7. You can use the Expression Builder or standard Formula builder to create the formula.
8. Click Save.

When done, you should have a node that is configured like this:

….and your Strategy should look like this:

Now, technically, this is already a functioning Strategy! The Load Propositions node type does exactly what the name implies: it loads Propositions meeting whatever criteria you define — in this case, Category = ‘ProductOffer’ — into your Strategy for consideration. However…this is a pretty boring Strategy. Let’s enrich this by making sure that ProductOffer Propositions are only seen by the right customers, as discussed in the scenario earlier.

the all-important gate node

To ensure that these Propositions are only seen by the right customers, we turn to the Gate node. The Gate node is used to open or close a branch in your strategy based on the criteria you determine. Critically, the Gate node is the primary way you have to involve non-Proposition fields in your Strategy as criteria. In this case, we’re going to create a Gate node that is only open when the Account associated with a Case is below a certain size. Let’s do this.

1. Right-click on WinningProposition and click Add Child Node.
2. Input the following:
3. Unique Name: OnlyBelow10k
4. Description: Only open if Account Employees < 10000
5. Node Type: Gate
6. Click Save.
7. Click and drag the existing LoadProductOffers node onto the new OnlyBelow10k node. Your Strategy should then look like this:

Looking a little more interesting, but it’s not yet actually doing anything!

1. Click on your new Gate node (OnlyBelow10k).
2. In the section that says “The gate controlling the branch LoadProductOfferProps is open when this is true”, click on the box with the blue “true” in it.
3. In the resulting expression builder, build the below expression (assume the Object type is Case), and then Save the node.

In the formula, $Record is swapped out for the Record that launches the Strategy at runtime. In our example, we’re going to ultimately use this Strategy on Case records, so what this formula is doing is looking at the Case record, looking up the Account related to it, and as long as the NumberOfEmployees field value is less than 10,000 this branch of the Strategy stays open. Translation: ProductOffer Propositions will be available for consideration only if we’re not talking to one of our larger accounts. Large accounts will get different Propositions.

Let’s get the big guys set up. The instructions below are less detailed because they involve doing the same actions we did above!

1. Create another Load Propositions node.
2. Set this new node to only load Category = ServiceOffer Propositions.
3. Create another Gate node.
4. Set this node to only open if $Record.Account.NumberOfEmployees >= 10000
5. Arrange the new nodes the same way you arranged your first two nodes, as follows:

Now we’re getting somewhere! This is still pretty simple, but it’s beginning to resemble a strategy that would actually do something useful. We have two different sets of Propositions, but we’re only making one set available to customers based on the Account Type associated with each customer — perfectly aligned with Cirrus’ goals.

However, remember that Cirrus doesn’t want to offer this stuff at all to customers unless they’re at risk! Right now, these Propositions are going to get offered to anyone and everyone. This is no bueno. Let’s fix this.

1. Create another Load Propositions node, this time loading Category = Troubleshooting.
2. Create another Gate node, called OnlyAttritionRisk. Leave the formula section blank for now.
3. Click and drag the nodes to arrange them like the below:

Now, re-open the OnlyAttritionRisk node, and configure the Gate formula like the below.
NOTE: You will need to switch to “Formula Mode” in the Expression Builder in order to type the below formulae.

Okay, what are we doing here? First, we’re making Troubleshooting available to everyone. It’s a safe assumption that our agents will be engaged in Troubleshooting activities even if making offers becomes relevant. Next, we’re going to leave the entire branch with our ProductOffer and ServiceOffer Propositions closed unless the Contact we are talking to has a risk of Attrition, which we’re pretending is derived from an AI prediction.

We have to do one more thing. Remember how we added a Ranking__c field to the Proposition object? That field is being used by Cirrus to rank Propositions based on Cirrus’ preference in terms of which ones get offered first. Now we need the Sort node.

the sort node

The Sort node serves a simple purpose: it sorts (and eliminates) Propositions based on criteria stored on the Proposition object.

1. Right-click on WinningProposition and select Add Child Node.
2. Input the following:
3. Unique Name: SortByRanking
4. Description: Sorts Propositions by Ranking
5. Node Type: Sort
6. Limit: 3 (this limits the resulting Propositions to only the top 3 after they’ve been Sorted by Ranking__c)
7. Sort on which Proposition field?: Ranking__c
8. Select a sort direction: ascending
9. Propositions without a value sort to the top: leave unchecked
10. Drag the OnlyAttritionRisk and LoadTroubleshooting nodes onto the new SortByRanking node, so that your Strategy looks like so:

Ermagerd, we did it! This is your new Strategy. To be clear, this is a very simplistic strategy designed to illustrate how you can cobble one together. There are several Node types we haven’t even covered.

But for now, let’s put the finishing touches on this. We’ll start by creating the Flow that will execute when a Proposition is acted on by an agent, and then finally configure the Lightning Component.

create the action reference flow

1. Navigate to Setup, and the Flows node.
2. Click New Flow.
3. Drag the Screen element from the palette on the left to the flow workspace.
4. Configure the Screen element to say anything you want. Keep it simple if you’d like.
5. Save the flow with name PropFlow, and make sure to Activate it.

Now, in the real world, you’d probably create distinct Flows for each Proposition, or at least each Proposition category. But, happily, we aren’t in the real world right now, and we’re going to use one Flow for the whole thing, just to keep this simple.

configuring the lightning component

Now for the easy part.

1. Navigate to the Cases tab.
2. Open any Case record.
3. Click the setup widget in the top right and select Edit Page.
4. Drag the Einstein Recommendations Lightning Component from the palette on the left onto your Record page (anywhere will do).
5. Input the following into the component configuration:
6. Title: [whatever you want]
7. Maximum number: 3
8. Strategy Name: SupportSales
9. Click Save.

let’s do this

Well, this is it. Navigate to any Case record. You should see the Einstein Recommendations component and, at a minimum, should see it suggesting Troubleshooting. If you want to make sure everything’s working, navigate to the corresponding Account, and check/uncheck Attrition Risk, and/or adjust their Employee count to greater than or less than 10,000.

If all is going well, you should see the Recommendations below for Cases with a related Account that is an Attrition Risk and has fewer than 10,000 employees:

Note the ranking. Remember way back at the beginning when we set up Propositions, we assigned a Ranking to each, with Troubleshooting set to 1 and everything else either 2 or 3. This is reflected in what NBA suggests. Troubleshooting is always going to appear as the first suggestion. If an account is an attrition risk, NBA will suggest additional Propositions based on how big the Account is.

Congrats! You’ve built a Strategy. Go ahead and click on any of the offers to see what the Flow experience looks like.

And please review the Node type definitions here. In this guide we have only covered Load Propositions, Gate, Sort, and Combine. Record Join, Filter, and Mutually Exclusive were not used and are all quite powerful. Ping your NBA Pillar Owner for more information on use cases for any of these.

Troubleshooting and Gotchas

You can follow the steps in this guide perfectly and still encounter problems. The most common gotcha is Strategy Crafter failing to save a change you’ve made. Other common gotchas involve typographical errors and malformed formulas. Troubleshooting your Strategy is a combination of a few simple (but tedious) tasks:

1. Click on each Node in your Strategy and make sure everything you inputted in the Node is still there. Pay particular attention to any formulae.
2. Verify that you have no typographical errors in formulae and field references.
3. Verify that you have no typographical errors in your Proposition fields and field names.
4. Verify that the Sort By field reference is using the full API name for the field (e.g. “Ranking__c”).
5. If any formula references a Picklist value, make sure to use the proper syntax.
6. E.g. if you have a Gate that should be open when a Picklist field called “Attrition_Risk__c” equals the Picklist value ‘High’, you need to convert the Picklist value to a text string in order for the formula to work, in this case TEXT($Record.Attrition_Risk__c) = ‘High’
7. If any Gate node formula references a Checkbox, make sure to use the proper syntax:
8. E.g. if you have a Gate referencing a Checkbox called Attrition_Risk__c and the Gate should be open when that box is checked, your formula is $Record.Attrition_Risk__c.
9. Do not use anything like $Record.Attrition_Risk__c = TRUE. This is because the Gate node is a True/False node checking if your formula evaluates to true, so if you add = TRUE to the end the implicit formula becomes $Record.Attrition_Risk__c = TRUE = TRUE/FALSE