We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

Decision modelling stages – how to work through the process

In my previous two blogs, I looked at how and why an organisation should use decision modelling to improve its ability to hyper-personalise its communications. In this last blog in the series, I will walk you through the stages involved in developing decision models.

Developing the decision model involves four basic stages: decision identification, decision description, decision requirements and finally model decomposition and refinement. Following these stages can occur as both a “one off” or as a recurring agile activity.

“One-off” modelling activity usually occurs in the context of a high-level solution design in order to, for example, size the project’s scope. Recurring modelling activities are performed in the context of an agile project - sprints.

The stages can be summarised as follows:

1.   Identify Decisions.

  • Identify the decisions that are the focus of the Next-Best-Action platform.
    • From a marketing perspective these decisions usually fall into three classes: eligibility, relevancy and prioritisation
  • What are the KPIs (Key Performance Indicators) surrounding that decision? Now is the time to consider how a decision will drive a given KPI such as churn, risk, NPS, etc.

2.   Describe Decisions.

  • Describe the decisions and document how improving them will impact the business objectives and metrics of the business. The activities performed in this stage would guide how simulations are performed on the strategy. For example, what would be the likely impact of using a suitability rule which excludes propositions related to already owned products? What would be the impact of using a different prioritisation algorithm which considers NPS (Net Promotor Score) for service-related communications?

3.  Specify Decision Requirements.

  • Specify the detailed information and knowledge required to make the decisions. What are the inputs (human and computer) required to make the decision?  Decision requirements will now be used to express this. For example, what knowledge would be required to define suitability rules for a cross-sell mobile international call discount proposition? The cross-sell marketing leader would provide input to determine who should (or should not) be suitable for the international call discount proposition.

4. Decompose and Refine the Model.

  • Refine the requirements for these decisions using the graphical notation of Decision Requirements Diagrams. In addition, identify additional decisions that need to be described and specified.
  • For example, eligibility decisions could be decomposed by applicability and suitability. Applicability defines rules which ask “Can I show this proposition?” Suitability defines the rules which ask “Should I show this proposition?”
  • The cycle is repeated. We repeat the process by returning to step 1. 
diagram of the stages of decision modelling
The stages of decision modelling


This process repeats until the decisions are completely specified and everyone has a clear sense of how the decisions will be made. In summary, the decisions should be in a testable and implementable state.

Clear, concise decision model design communication is essential

Communicating designs in a clear and concise way to stakeholders is fundamental in getting strong, reliable solutions built. When the stakeholders understand what is being built, it increases the chances of identifying potential issues early.

DMN enables this clear communication in decisioning requirements. In addition, it enables a truly agile way of building a next-best-action solution. I described the hybrid iterative waterfall approach traditionally used in projects (where you “just had to have” the framework complete before proceeding with the more agile aspects). This would include adding channels, data sources, propositions and rules. With DMN the framework design could be built in an agile manner. For instance, is the cross-sell strategy required in go-live? No - we can proceed without it. Using DMN, we can later design and then build in a different strategy which may add more business value or may be quicker to build. In effect, the fundamental design and implementation will become more agile in nature.

Do you need help with furthering your decisioning capabilities? If so, do contact us here. You can also read the other two parts in this blog series, Enabling personalised interactions through decision modelling and The mechanisms of organisational decision making.