Best-Next-Action Decisioning Concepts

The building blocks of a Best-Next-Action Decisioning System

Let’s look at the core concepts and building blocks of our Best-Next-Action decisioning system

Category

The category is the type of offer that you are making. Best practice has shown that Best-Next-Action Decisioning systems should be used to cover the whole of the customer lifecycle and for all aspects of the relationship. They should not be used purely for sales activities (see story) as this undermines rather than supports the relationship.

Typical categories of offers include the standard:

• Regulation - things that you have to say and should be the most important
• Data - things that if you knew or the customer could tell you would help inform the relationship
• Service - things that would improve the customer experience but not have an immediate monetary impact
• Sales - where the outcome is typically a financial one

Other catgeories can be envisgaed. The order in which the categories are listed above is the idealised order in that knowing something about a customer is more important than attempting to sell something to them for example. This sometimes takes a while to come to terms with but it makes sense.

Priority

Often simple-is-best and in a lot of situations basic priority ranking is all that is sufficient to produce very useful recommendations. The typical priority system used is as simple as: lowest, low, medium, high and highest - but any odd-numbered scheme or names can be used. Priorities can be applied to offers.

Channel

The physical channel on which a customer interaction is happening - this could be for example website, mobile app, call centre, email, SMS, push. The channel largely dictates the type of content that can be supported and the degree of interactivity.

Rules

Rules are simple beasts that return either True or False - through these simple rules very complex patterns can be built by combining rules in positive and negative ways.

Rules have access to the full context and can be applied as inclusion or exclusion filters.

Context

The context is the up-to-the-second information about the situation in which the recommendations are being requested. The context available includes the following information:

• Channel - the channel on which the interaction is happening
• Customer - the details about the customer such as age, product holding, complaint status
• History - the history of interactions for this customer
• Agent - in managed channels informaion about the agent that helps filter recommendations

Content

The content is the meat in the sandwich - it is the thing that will either be put directly in front of the customer in an automated channel or it is the thing that an agent will use to deliver the message.

Content usually has a variant for evry channel that it supports. Content does not have to support every channel - it is difficult to do.

Offer

The name offer is a little controversial as it often implies that you are trying to sell something with each recommendation - but the name is used more generally to mean any specific We don’t use the word recommendation as that is used for the full instantiation of an offer in a particular channel and is the outcome of the “get recommendations” process. The offer is the piece that brings all of the other things together and it is the pool of offers that is evaluated to see what we have to say.

The offer contains the following pieces of information:

• name - a unique name for the offer
• description - background on the offer and the purpose
• category - the type of offer
• priority - the priority for this offer if we are using a simple ranking scheme
• channels - the list of channels that the offer is available - for each channel there should be a piece of content available
• content - the name of the content that supports the channels
• inclusion_rules - the list of rules that must all evaluate to true for this offer to make it through the filtering process
• exclusion_rules - the list of rules that if any of these rules evaluate to true then the offer will be excluded
• valid_from - an optional timestamp which is the earliest that the offer can be considered for evaluation
• valid_to - an optional timstamp which is the latest that the offer can be considered for evaluation

A sample offer might look like this:

• name: Santa Surprise for Good Children
• description: A surpise from father Christmas for those good boys and girls
• category: service(?)
• priority: high
• channels: [ “chimney”, “window”, “doorstep”]
• content: present
• inclusion_rules: [ “hasBeenNice” ]
• valid_from: 20241225:000001
• valid_to: 20241225:000800

and another

• name: Santa Surprise for Naughty Children
• description: A surpise from father Christmas for those naughty boys and girls
• category: service(?)
• priority: low
• content: lump of coal
• channels: [ “chimney”, “window”, “doorstep”]
• inclusion_rules: [ “hasBeenNaughty” ]
• valid_from: 20241225:000001
• valid_to: 20241225:000800

Note that here we have used two different inclusion rules but we could easily have used an exlcusion rule of “hasBeenNice” for the naughty children if we are convinced that all of the children who have not been nice must have been naughty.

We have also used two distinct priorities - just in case the same child has been naughty and nice then the Good Children surprise will be the top ranked result.

Those are the basics of what constitutes an offer. Next we will learn about the filtering and ranking process.

Prev Blog   Index   Next Blog