What a decision system actually is
- decision systems
- analytics
Most analytics work stops one step short of being useful. You build the pipeline, you build the dashboard, and then it sits there — accurate, well-designed, and largely unread. The problem is rarely the data. It is that nobody defined what the thing is for.
A decision system starts from the opposite end: name the decision, then work backwards to the data that informs it.
The difference in one line
A dashboard answers what happened. A decision system answers what should we do, and notices whether you did it.
What that looks like structurally
The shape is consistent across the engagements I have worked on:
Steps 1 to 3 are what most projects deliver. Step 4 is what makes the first three compound instead of decay.
Where it goes wrong
| Symptom | Root cause | What actually fixes it |
|---|---|---|
| "Nobody uses the dashboard" | No decision was named | Interview the decision-maker, not the data owner |
| Numbers argued over in meetings | No single source of truth | Reconcile once, publish the lineage |
| Refresh keeps breaking | Manual steps in the chain | Automate the boring middle, not the last mile |
A note on tooling
The stack matters far less than the loop. I have built versions of this in Power BI, in plain SQL with scheduled email, and in Python. What did not vary was naming the decision first. If you want the longer argument for that, the services page sets out how I structure the engagements themselves.
For a worked example, the enrolment agent demo (opens in a new tab) shows the conversational layer sitting on top of exactly this kind of loop.