Customer engagement space is inherently complex. NBA (Next Best Action) framework tries to navigate this complexity by adding layers of metadata on top of the data and glue everything in an orchestration layer. In regulated service operations, that complexity extends further still. The decisions being made carry regulatory obligation, not just engagement preference.
Applying NBA framework in Customer Engagement space involves not just static rules but a whole mix of dynamic behaviors, statistical analysis, machine learning, personalization, and end-to-end orchestration.
The Concept of Decisioning in Customer Engagement
When we talk about “decisioning” in the context of customer engagement, we're basically talking about how organizations make real-time, 1:1 personalized decision about how to interact and engage with their customers. This could be deciding what offer to show, which channel to use, or even what tone of communication to adopt. The aim is to enhance engagement by making each decision as relevant and personalized as possible.
The Traditional Data-First Model
In that data-first world (e.g. data-driven approach), the process usually goes something like this: you start by gathering a bunch of customer data. Then you add layers of metadata that define actions, product catalogs, and various data rules about what you can offer or how you can engage. Finally, you have this orchestration layer that tries to glue everything together and figure out, based on all that data and metadata, what the next best action should be.
The orchestration layer loads all the data for a specific customer from a storage called Customer Analytical Record (CAR) and applies a set of filters on all the enabled NBAs defined in metadata layers and filter them out based on different criteria. These criteria are based on Eligibility, Contact policy, Propensity score, Channels, Treatments and so on.
Once the set of NBAs are out of the cumulative filtering process is out, they apply ranking to find out what are the best one in the context of the customer at the moment.
In this data-first approach, there is no decisions, we are trying to retrofit decision into data and metadata layer.
Applying Decision-Centric to Customer Engagement
In the decision-centric world, the flow starts by identifying the decision that needs to be made. You don't begin with data, metadata, or massive lists of actions. You begin by asking, “What decision are we making for this customer right now?” That decision becomes the core structure everything else serves.
There is no need to load a giant customer profile into memory. Instead, the decision model defines exactly what data is needed and when. Data is pulled on demand from appropriate sources, driven by the structure of the decision. This makes the process lean, contextual, and fast.
There is no massive NBA catalog that needs to be filtered down. You don't start with all possible actions and apply layer after layer of rules and constraints. The decision structure itself determines what actions are possible, eligible, and appropriate in the context. Applying logic to determine NBAs become part of the decision, not a separate orchestration effort based on metadata.
Ranking is not a bolt-on step at the end. It is a sub-decision natural part of the decision graph using many different techniques as part of a Composite AI model. Whether it's based on scores, policies, optimization models, or AI-based prioritization, ranking is handled as part of the structured decision, using clear logic and traceable inputs.
The Decision-Centric Approach® makes business decisions the first-class of organizations by explicitly modeling decisions and operationalizing them. In the case of customer decisions using NBA the decisions are front office engaging with customers in real time.
The Shift
When we apply the Decision-Centric Approach® to Next Best Action (NBA), we shift the focus from the data and metadata to decisions. The NBAs become a natural emergence of the decisions rather than just a metadata layer.
This Decision-Centric Approach® is more natural and adaptive because each decision node inherently produces the Next Best Action. Instead of bolting NBA on top of a data layer, you let decisions guide the flow. That means personalization and multi-channel engagement become a natural outcome of the actual decisioning.
It's a shift from a data-first to a decision-first model, which tends to simplify and clarify the whole engagement strategy.
Why the Decision-Centric Approach® Feels More Seamless
The reason the Decision-Centric Approach® ends up being smoother and often better is that you flip that script. Instead of starting with a big pile of data and then trying to orchestrate your way to a decision, you start with the decision itself. You say, “What decision do we need to make for this customer at this moment?” and then you pull in just the data and rules needed to make that decision in a focused way.
Because you're treating decisions as the core building blocks, everything else such personalization or the Next Best Action naturally emerges from that decision model and underpinned decision logic (rules, data, analytics, AI/ML etc.). You don't have to glue things together afterward because the decision is the starting point, not the endpoint.
Nothing is for Free!
In the data-first model, the cost comes later. You pay with glue code, orchestration, complexity, and translation layers to retrofit decisions.
In the decision-centric model, the cost is upfront. You invest in modeling decisions clearly and explicitly. But once you do, execution becomes clean, explainable, and scalable.
Let's put these two approaches side by side.
| Area | Data-First Model | Decision-Centric Approach® |
|---|---|---|
| Starting Point | Data and Metadata | Business Decision |
| Runtime Data | Load everything into CAR | Pull what is needed at runtime |
| NBA Handling | Filter from a pre-defined catalog | Derived from decision outcome |
| Filtering | Multi-layer external filtering | Embedded in the decision structure |
| Ranking | Final external process | sub-decision of Composite AI |
| Orchestration | Glue logic required into a nested process (flow) model | Channel delivery and event-driven by Continuous Decision model |
| Execution Logic | Scattered across metadata and scripts, code and nested orchestration | Unified in a decision model |
| Explainability | Fragmented and opaque | Clear, traceable, explainable |
Understanding the Different Barriers
The data-First Barrier
In the data-first approach, the barrier is kind of front-loaded. You start off by tagging and categorizing and doing all this metadata work, but then you hit a wall because you're waiting for that translation into actual runtime behavior. It's like all the activity is on the front end, and then you have to wait for the payoff. So that's where the barrier is: it's a delay between business understanding and actual execution and heavily investing in the technical translation of data and metadata to runtime behavior.
The Decision-Centric Barrier
On the other hand, the Decision-Centric Approach® does have a barrier, but it's more about perception and initial buy-in. The moment you bring in a graphical tool like Decision Model and Notation (DMN), some folks might fold their arms and say, “Oh, this looks technical”. So, the barrier here is more about that initial comfort level and overcoming the perception that a graphical interface equals a technical hurdle.
Different Timing, Different Solutions
What's interesting is that both barriers are real; they just appear at different stages. In the metadata approach, the barrier is later, when you're trying to turn all that groundwork into real decisions. In the Decision-Centric Approach®, the barrier is earlier, when you're getting people comfortable with a new way of visualizing decisions.
The Consequential Side Effects
Every choice we make, there will be a consequences, and in customer engagement and implementing NBA program in organizations is not an exception.
Decision-Centric: One-Time Barrier, Long-Term Clarity
With the Decision-Centric Approach®, once you overcome that initial barrier of getting everyone comfortable with Decision Model and Notation (DMN) and the graphical interface, you're pretty much set up for long-term clarity. There aren't hidden downstream costs or delays caused by that approach. Once everyone's on board, your decisions flow smoothly from modeling to execution without those ongoing translation headaches.
Data-First: Ongoing Costs and Delays
In contrast, the data-first approach might feel easier at the start because it doesn't require that upfront shift in mindset. Although you cannot go live because you need all the data to be ready and loaded into CAR. Additionally, when you have the data ready which takes like around 5 to 6 months if you are lucky the consequential side effects start piling up. You get delays in delivery, misalignment between what the business wants and what's actually implemented, and a constant need to throw more resources at interpreting and operationalizing the data and metadata. In other words, the cost isn't just in the initial setup, but in the ongoing process of constantly bridging the gap between business understanding and technical execution.
Book a Custom Demo
Final Thoughts
We explored the concept of customer engagement decisioning and how the Decision-Centric Approach® applies to Next Best Action (NBA), making it more seamless and adaptive. In a traditional data-first approach, you start by gathering data and layering on metadata like product catalogs, stages, actions and, then you glue it all together in an orchestration layer. The barrier here is that you end up with a delay and a disconnect between what the business wants and what the technical team delivers, often resulting in ongoing costs and maintenance challenges.
In contrast, the Decision-Centric Approach® starts with modeling the decisions themselves using something like DMN (Decision Model and Notation), and then pulling in data as needed. The barrier here is more about the initial perception that a graphical tool is “technical.” However, once you overcome that initial discomfort, there are no ongoing side effects. It becomes a smoother path from decision modeling to execution.
In other words, both approaches have barriers, but they appear at different times. The metadata approach leads to ongoing delays and costs, while the decision-centric approach has an upfront learning curve but offers long-term clarity. Once you're past that initial barrier, the Decision-Centric Approach® avoids the ongoing misalignment and maintenance overhead of the data-first method based on data and metadata.
Furthermore, it's important to note that many vendors in the rules and operational decisions space try to sell simplicity to the NBA domain. But NBA requires a far more cohesive, dynamic set of behaviors that can't just be addressed by layering on static rules. It requires the eligibility, contact policy, arbitration, ranking, personalization, treatment, which some of them requires static rules, but many areas require adaptive behavior, statistical analysis, machine learning execution, advanced data operations, end-to-end orchestration.
In regulated industries, this distinction becomes critical. The data-first approach cannot produce governed decisions. It produces filtered metadata. And filtered metadata cannot answer a regulator who asks why a specific customer received a specific action at a specific moment.
Leveraging multiple separate tooling to overcome the NBA requirements also only adds more complexity. The solution is to unify these dynamic needs into a single, decision-centric UI that embraces complexity rather than trying to simplify it away.
Read More
Last updated May 16th, 2026 at 10:23 am Published September 3rd, 2025 at 01:24 pm
