What Is Decision Intelligence? Architecture and Enterprise Use Cases

A working definition

Decision intelligence is the practice of turning evidence into a specific choice, within known constraints, and learning from the result. It sits between business intelligence, which describes what happened, and automation, which changes what happens next.

The output should be a decision record: the question, the data version, the candidate actions, the expected effect, the governing rule, the approver and the observed outcome. Without that record, a recommendation is difficult to reproduce and an automated action is difficult to audit.

The six-layer architecture

A practical system separates six concerns. This separation matters because errors have different owners: a stale metric is a data problem, while an unauthorized action is a policy problem.

• Sources: read transactions, CRM events and operational records through explicit, scoped contracts.
• Trust: reconcile identifiers, test freshness and completeness, and preserve lineage back to each source.
• Meaning: define business metrics once, including currency, time window, owner and calculation rules.
• Candidates: describe possible actions, the baseline and the expected upside or downside of each.
• Control: evaluate policy, budget, permissions and approval requirements before any write action.
• Outcome: compare the observed result with the baseline and retain the evidence for later review.

Example: overdue invoices

Imagine that an accounts receivable team wants to reduce invoices more than 30 days late. First, define “overdue” against the invoice due date, payment status and a named reporting time zone. Then deduplicate customers across billing and CRM systems. A candidate might be to send a reminder to accounts with no open dispute and an outstanding balance above a chosen threshold.

Before execution, a policy checks whether the customer opted out, whether another reminder was sent recently and whether the message needs human approval. The decision record stores the eligible cohort and the reason each excluded account was excluded. After sending, compare payment timing with an appropriate baseline rather than counting sent emails as recovered cash. This is an illustrative workflow, not a customer case study.

Where enterprises use it

The same pattern applies to inventory replenishment, margin protection, fraud review and service recovery. Each case has a different action and risk boundary, but the questions are stable: Which metric is trusted? Which intervention is allowed? Who is accountable? How will the result be verified?

Start with one narrow decision whose outcome can be measured. Expand only when its data contract, approval path and rollback plan are explicit. Scale comes from repeating a reliable decision pattern, not from giving every workflow a model.