Copy page

What is Decisioning?

Every platform or app makes decisions: who gets notified, what price to charge, which tier a customer falls into, whether to escalate a request. These decisions go way beyond simple if/else statements. They also shape the user experience, product features, market dynamics, and regulatory compliance.

How do these decisions get made? How do you audit why the decisions were made? What happens when the platform or business needs to change the logic?

"Decisioning" is that process. It's when you capture data and then evaluate it against a set of predefined rules to come to a decision. It's what lets the rest of your platform know that it needs to send a notification to an email but not to a phone, or that a customer is eligible for a discount but not a refund.

Decisioning has been around for decades, but it's often relegated to big corporations with teams that can run heavy decisioning engines. The collective knowledge and wisdom of how to do it well is usually locked up in enterprise-first solutions, but the need for decisioning is universal.

Parts of a Decision

If you think about it, every decision has three parts:

1. Data: The information you have about the situation or context. This could be customer attributes, transaction details, or historical behavior.
2. Rules: The logic that defines how to evaluate the data. This could be simple thresholds ("If the customer has made more than 5 purchases...") or complex combinations of conditions ("If the customer is in the 'Gold' tier and has made more than 5 purchases, and it's a weekday...").
3. Outcome: The result of evaluating the rules against the data. This could be a decision like "Apply a 20% discount" or "Send an email notification."

There are many solutions for decisioning systems, from Saas style products to open source rules engines. But the core concept is the same: a way to define rules, evaluate them against data, and get a deterministic outcome.

Before and After

In most set ups, the decisioning engine sits in the middle. Before it you have some sort of data gathering or transformation. After it, you have some sort of fulfillment or action. Together, they form a complete workflow.

In some solutions, particularly Saas products, the data gathering and fulfillment are built in. You can have the platform pull in the necessary data from your systems, and then have it trigger the necessary actions based on the outcomes. In other solutions, particularly open source ones, you have to build the data gathering and fulfillment yourself, and then integrate them with the decisioning engine.

Breaking things down into these different parts is helpful because each part of the system wants to achieve different goals.

• Data Gathering needs to pull in all the data required in as short a time as possible. Often, data gathering systems tend to favor parallelization and concurrency to speed up the process.
• Decisioning needs to evaluate the rules as quickly as possible. It often favors optimization techniques like caching, indexing, and pre-compilation to speed up the evaluation process.
• Fulfillment needs to propagate the outcome to the rest of the platform as quickly as possible, whether that's updating a database, sending a notification, or triggering an API call. It often favors reliability and consistency to ensure that the outcome is properly executed.

Evaluation

A decisioning engine works by evaluating a set of rules against a set of data. In runtimes, you have control flow structures like loops and if/else conditionals, but in decisioning you just have rule evaluation.

Different solutions have different ways of structuring the rules and evaluation logic. But the core concept is the same: your data gets evaluated through a list or graph of rules, and at the end an outcome is produced based on the rules that were satisfied.

Let's say we have four rules in our booking pricing system:

1. If the customer is a "Gold" member, apply a 20% discount
2. If the customer has made more than 5 purchases, apply a 10% discount
3. If the customer is booking on a weekday, apply a 5% discount
4. If the customer is booking on a weekend, apply a 5% surcharge

Now, let's say we have a customer Alice who is a "Gold" member, has made 10 purchases, and is booking on a weekday. The decisioning engine would evaluate the rules in order and produce an outcome of "Apply a 35% discount" (20% from rule 1, 10% from rule 2, and 5% from rule 3).

Notice how the rules are evaluated independently of each other. The decisioning engine doesn't care about the order of the rules, it just evaluates them all and produces an outcome based on which rules were satisfied. This is different from a control flow structure where the order of the statements matters.

Good Decisions, Bad Decisions

How you set up your decisioning system, the individual components or the solutions you purchase, can have a big impact on the quality of your decisions. There are four general signs of a good decisioning system:

• Centralization: Rules are defined in one place, not scattered across codebases, spreadsheets, or automation tools. Rules are written in a structured format (like a DSL, JSON, or other solution)
• Speed: Rules typically need to be evaluated in milliseconds, so the system should be optimized for performance. This often means pre-compiling rules, caching results, and optimizing data access patterns.
• Updates: Rules can be updated independently of code deployments. This allows for quick adjustments to thresholds, policies, or tiers without needing to go through a full development cycle.
• Auditability: The system should provide a clear audit trail of which rules were evaluated, which were satisfied, and what the final outcome was. This is crucial for debugging, compliance, and understanding the impact of rule changes.