Decision intelligence

What is decision intelligence?

Decision intelligence treats a recurring decision as something you design, write down and improve, instead of something that happens in someone's head or gets settled in a meeting. The unit is the decision itself: what is being decided, by whom or by what, on which inputs, under which rules or model, out of which options, and what came of it afterwards.

Analytics has traditionally stopped one step earlier. A report produces a number, the number lands on a screen, and what someone does with it stays implicit. Nobody writes down that the number exists because a purchaser decides every Tuesday whether to reorder, and nobody checks a month later whether the reorder was right. Decision intelligence puts the decision at the centre and the number in a supporting role.

Gartner's glossary calls it a practical discipline that advances decision making by explicitly understanding and engineering how decisions are made and how outcomes are evaluated, managed and improved via feedback. That last clause does the work, and it is the one most companies skip.

The name has two origins. Lorien Pratt and Mark Zangari of Quantellia set the practice out in a white paper in December 2008, on how to model the way actions lead to outcomes, and called it decision engineering. They swapped the name for decision intelligence later, because on their own account engineering did not sell to managers. Google gave it currency in 2018 by renaming its applied data science practice decision intelligence engineering, under Cassie Kozyrkov, who called the field the discipline of turning information into better actions at any scale. Gartner named it a top strategic technology trend for 2022.

The anatomy of a recurring decision

A decision you make fifty times a month has seven parts. Write them out and you have that decision on one page, which is the method in its cheapest form.

1. The trigger. What makes the decision come up, and how often. An order over a limit, a Tuesday morning, a customer mail, a stock level under a threshold.

2. The inputs. The facts you look at and where each one lives. What the person actually has in front of them at the moment they decide, which is usually less than what sits in your systems.

3. The rules or the model. The part that turns inputs into an answer. Sometimes a threshold and a policy, sometimes a prediction, often both.

4. The options. Everything you may choose between. This box is emptier than people expect: plenty of decisions get written down as yes or no when there were four sensible answers.

5. The decider. The person or the system that settles it, and the level at which they may settle it without asking anyone.

6. The record. What gets stored at the moment of deciding: the inputs as they stood, the rule version or model score, the option chosen, who chose it, one line of reasoning.

7. The feedback. What you measure later to say whether it worked, and when you go back to measure it.

Boxes one to five are usually filled in, even if only in someone's head. Box six is half filled: the outcome sits in the ERP, the reasoning does not. Box seven is empty.

A credit limit decision, worked out

Take a Belgian wholesaler. An order gets blocked because it pushes a customer over their credit limit, and someone decides whether to raise it. That happens about sixty times a month.

The trigger is the block in the ERP. The inputs are the current limit, the outstanding balance, the average payment delay over twelve months, the age of the oldest unpaid invoice, the limit the credit insurer covers, and the orders in the pipeline. Two hard rules: never above the insured amount, and no increase while an invoice is more than sixty days overdue. The model predicts how likely this customer is to pay more than thirty days late in the next six months, from their own payment history. The options are refuse, raise to the amount asked, raise partially, or raise on condition of prepayment above the old limit. Increases under ten thousand euro that stay inside the insured amount go through automatically, the credit controller decides up to fifty thousand euro, and the finance manager decides above that.

That much a decent finance team already does. The record and the feedback are what make it improve. On the day itself, store the six input values, the model score, the option chosen, the name of whoever chose it, and one line saying why. Six months later, go back over every decision: did the customer pay late, was anything written off, and how much extra gross margin came from the volume the higher limit allowed.

Say there were 360 requests over six months. The hard rules refused 90 outright. Of the remaining 270, 200 were increases under 10,000 euro that went through automatically and 70 went to a person. Six months on, 6 of those 200 automatic increases paid more than thirty days late, and so did 7 of the 70 a person approved. Two of those thirteen ended in a write-off averaging 4,200 euro, so 8,400 euro lost. Now measure the 90 refusals too: 22 of those customers placed no further order. At 1,900 euro of annual gross margin each, that is 41,800 euro of margin gone.

Nobody was wrong on any single decision, and every refusal was defensible on its own. Counting both sides is what makes the setting visible: the bad debt that got through came to 8,400 euro, and the caution that kept it there cost five times as much in margin. Without box seven you never see it, because write-offs land in a ledger account with a name on it and lost customers land nowhere.

The feedback box is almost always empty

Most companies can tell you what they decided. Few can tell you whether it worked, so the decision never gets better.

Three practical reasons. The outcome arrives months later, by which time nobody connects the two. The outcome is contaminated: the customer paid late, but they also lost a big account, so was the credit decision wrong or was it the world? And refusals produce no data at all, because a customer who stopped ordering does not send you a note about it.

The decision quality work from Strategic Decisions Group, set out by Carl Spetzler and colleagues, helps here. In that tradition a good decision and a good outcome are two different things. Quality lives in the six elements that went into the deciding: the frame, the alternatives, the information, the values and trade-offs, the reasoning, and whether anyone committed to acting on it. The chain is no stronger than the weakest of the six. A bad outcome after a well-made decision is bad luck. A good outcome after a sloppy one teaches the wrong lesson.

For a recurring decision that distinction gets easier, because you are judging fifty a month rather than one case. One late payer says nothing. Six out of two hundred against seven out of seventy says something. Volume is what lets you learn from outcomes without pretending each single case was predictable.

The minimum version of feedback is a table with one row per decision and a column you fill in later. If reading that column once a quarter moves one threshold, the loop has paid for itself.

Rules, a model, or a person

The useful move is not automating the decision. It is separating the three kinds of work inside it.

What is fully specifiable belongs in rules. If you can write it as conditions and outcomes, and the outcome has to be identical every time, it is a rule and it belongs where the business owner of that rule can change it. The formal half of this is DMN, the OMG standard for writing a decision down so that the rule owner and the engine that runs it read the same thing, with version 1.5 adopted in August 2024. The DMN entry in this dictionary covers the notation, the decision table and the versioning. Decision intelligence gives you the reason to draw one, DMN gives you the form.

What needs a prediction gets a model: how likely this customer is to pay late, what demand looks like next month, which order is at risk of missing its date. A model gives you a number with a range around it, and that number is an input to the decision, not the decision.

What needs judgement stays with a person, supported by both. Judgement is what is left when the rules have run out and the model is uncertain: a long-standing customer with one bad quarter, a supplier who has never let you down. Count those cases separately, because if judgement covers eighty percent of them the decision has not been designed yet.

Agents change who executes, not that split. An agent can gather the inputs, run the rule, call the model and write the record, which takes the clerical work out of a decision. It cannot supply the option set or the definition of a good outcome, and it inherits whatever you put in the boxes. A decision with no feedback loop, handed to an agent, is now made wrong faster and in more places. Automation bias makes that worse, because a confident recommendation on a screen gets accepted more readily than an equally confident colleague.

Decision intelligence compared to a dashboard

The two get sold as the same thing. They differ on one dimension: what the output actually is.

A dashboard outputs a state. Here is the outstanding balance, here is last month's turnover, here is the payment delay per customer. True, current, and silent about what to do. Someone reads it, interprets it and acts, and none of that interpretation is written down. Two people can read the same dashboard, do opposite things, and both be following the data.

A designed decision outputs a choice with the reason and the record attached. Raise this limit to 30,000 euro, because the insurer covers 35,000, the customer has paid on average four days late over twelve months, and the model puts them in the low-risk band. Decided by the credit controller on 14 March. Reviewed in September.

The dashboard does not get worse when you work this way, it becomes an input with a job, and you can tell which charts have one. Go through the tiles on your management dashboard and ask which decision each one feeds. The ones with no answer are usually there because they were easy to build, and that is the honest reason most dashboards are as big as they are.

How much of this is new, and where you start

Be honest about the term. Decision intelligence is partly an analyst and vendor label wrapped around practices that already existed: decision modelling, business rules, uplift modelling, operations research, ordinary management discipline. Vendors sell decision intelligence platforms and some are good products, but the category is younger and looser than the practices inside it. The prediction that came with that 2021 trend announcement, that a third of large organisations would be using decision intelligence within two years, says more about how fast the vocabulary spread than about the method landing. The first Magic Quadrant for decision intelligence platforms only appeared on 26 January 2026, four years later.

The value is the discipline, and the discipline costs nothing to try. Take one decision your business makes fifty times a month: reordering, quoting a price, approving an expense, accepting a rush order, assigning a technician. Write the seven boxes on one page and fill them in, with the person who actually makes that decision next to you.

Then count the empty ones. Usually the options box holds two entries where four belong, the record box holds an outcome without a reason, and the feedback box is blank. Fill the feedback box first, because it makes every later change measurable and because it asks for a column in a spreadsheet rather than a project. Once the same decision has fifty recorded outcomes behind it, you can argue about the threshold with numbers instead of anecdotes, and that argument is worth more than any platform you could buy for it.