Closing the Gap Between Dashboards and Decisions

The gap is at the hand-off

A dashboard can be accurate, fast and well designed and still change nothing. The failure is rarely in the visualization. It sits in the hand-off between a number and a person who has the authority to act on it, a threshold that says when to act, and a known set of options.

The research evidence is honest about this. A 2015 review of clinical and quality dashboards in the International Journal of Medical Informatics found some evidence that dashboards improved care processes and outcomes, specifically where clinicians had immediate access to them in their working context, such as on a screen saver. A 2021 systematic review of patient-safety dashboards found their use had grown for 15 years but their impact remained poorly understood, and that design rarely considered whether content actually helped people complete tasks or make decisions. The visualization research community reaches a similar conclusion from another direction: the widely cited 2019 study What Do We Talk About When We Talk About Dashboards? characterizes dashboards by their design goals, levels of interaction and the practices around them, and identifies several distinct dashboard types. A dashboard built for awareness is not automatically fit for driving a decision.

Most enterprises do not measure dashboard impact at all. They can measure dashboard use: Power BI's workspace usage metrics, for example, report views, unique viewers and a count of unused reports over a rolling 30-day window. That is a useful start for a clean-up. It says nothing about whether a decision changed.

Our executive guide, From Business Intelligence to Decision Intelligence, sets out why the decision rather than the report should be the unit of design. This article is the operating framework. INVISOM's position: close the gap by managing a decision inventory, not a report catalogue, and by refusing to build any metric that cannot name the decision it serves, the owner who acts, and the threshold that triggers action.

The framework: five parts, one loop

Each part is simple. The discipline is in doing all five for the same decision, rather than doing one of them for everything.

1. Build a decision inventory

Start by listing decisions, not reports. A useful inventory has 20 to 40 entries for a business unit, each written as a question with a finite set of answers: "Do we mark down this store's fresh produce today, and by how much?" rather than "fresh produce performance".

For each decision, record five attributes:

• Frequency: daily, weekly, quarterly, one-off.
• Value at stake: rough order of magnitude per decision and per year.
• Reversibility: can a poor choice be corrected cheaply and quickly?
• Current basis: what information and logic is used today, honestly described.
• Latency: how long between the triggering signal and the action.

Reversibility deserves special weight. In his 2015 letter to shareholders, Jeff Bezos distinguished between consequential, near-irreversible "Type 1" decisions and reversible "Type 2" decisions, and warned that large organizations tend to apply the heavy Type 1 process to everything, which makes them slow. The same applies to analytics: a reversible, frequent decision should get a fast, simple trigger and probably automation; an irreversible, infrequent decision needs a richer brief and deliberate review.

The inventory is also a governance artefact. Saudi Arabia's National Data Management Office standards include a Data Value Realization domain that expects entities to maintain a pipeline of value-generating data use cases. A decision inventory, with owners and expected outcomes, is a concrete way to evidence it, and a better one than a list of dashboards. Our NDMO implementation guide covers the wider standard.

2. Name a single owner for each decision

A dashboard has an owner who maintains it. A decision needs an owner who is accountable for making it. These are rarely the same person.

Bain's RAPID model is a well-tested way to assign the roles: one person who Recommends, those who must Agree (used sparingly, for legal or regulatory necessity), those who Perform the action, those who provide Input, and ideally a single person who Decides. Applying it to the inventory surfaces two common problems quickly: decisions with no D, where a metric goes red and nobody is obliged to act; and decisions with several Ds, where the signal triggers a meeting rather than an action.

Write the owner's decision rights down: what they can change without escalation, within what limits, and how quickly they are expected to respond to a trigger.

3. Tie every metric to a decision

Each decision needs a small number of metrics, arranged in three roles:

• Outcome metric: what the decision is ultimately trying to move (margin, losses, churn, wait time).
• Trigger metric: the leading signal that says this decision needs making now.
• Guardrail metric: what must not deteriorate as a side effect.

The guardrail is the role most often missing, and its absence is how good metrics turn harmful. Wells Fargo is the standard warning. In September 2016 the US Consumer Financial Protection Bureau fined the bank $100 million after employees opened roughly 1.5 million deposit accounts and about 565,000 credit card accounts that customers may not have authorized, to meet sales targets and earn incentive pay. Sales targets were pursued with no effective guardrail on whether customers had asked for the products at all.

A practical rule: a metric that cannot name its decision, its owner and its role does not go on a decision dashboard. It may still belong in an exploratory or regulatory report. It should not compete for the owner's attention.

4. Set thresholds that trigger action, not noise

Thresholds turn a metric into a trigger. Getting them wrong in either direction breaks the loop: too loose and nothing fires; too tight and people learn to ignore alerts.

Statistical process control gives the clearest picture of the trade-off. NIST's Engineering Statistics Handbook notes that adding the Western Electric run rules to standard three-sigma control limits makes a chart far more sensitive to shifts, but raises the in-control false-alarm rate from about one point in 371 to about one in 92. Healthcare shows the human consequence. A 2006 review in the Journal of the American Medical Informatics Association found that clinicians override drug-safety alerts in 49% to 96% of cases, and attributed much of this to low specificity and unnecessary workflow disruption.

Five design rules follow:

1. Derive thresholds from the decision, not the data. The threshold is the point at which the owner's best action changes. If no action changes, there is no threshold.
2. Separate noise from signal statistically. Use control limits or forecast intervals, not fixed percentages chosen in a workshop.
3. Route to the owner, with the playbook. An alert should arrive with the options and the recommended action, not just the number.
4. Budget alerts. Set a maximum number of alerts per owner per week and tune thresholds to stay within it.
5. Review alert precision. Track how often an alert led to action, and retire or retune rules that are routinely dismissed.

5. Close the loop: record decisions and outcomes

The fifth part is what turns reporting into learning. For each decision in the inventory, record the trigger, the option chosen, the reason, and, after an agreed interval, the outcome against what was expected. A simple decision log in the same platform as the metrics is enough to start.

Two practices make the loop credible:

• Look before you leap. Gary Klein's premortem, published in Harvard Business Review in 2007, asks a team to imagine that a decision has already failed and explain why. Klein cites research showing that this kind of prospective hindsight increases people's ability to identify reasons for future outcomes by 30%. Use it for Type 1 decisions.
• Test where you can. For frequent, reversible decisions, controlled experiments give the cleanest feedback. Booking.com, profiled by Stefan Thomke in Harvard Business Review in 2020, runs about 25,000 tests a year. Most organizations will never need that volume, but even a holdout group for one decision rule gives a far better answer than before-and-after comparisons.

Once a decision has a reliable history of recommendations and outcomes, it can be considered for more automation. Without that history, automation simply scales an untested rule.

Worked example: fresh-produce markdowns

Consider an illustrative grocery chain with 120 stores. Fresh produce waste is reported monthly on a regional dashboard that is viewed often and changes little. The decision that actually drives waste is made daily in each store: whether to mark down short-dated items, and by how much.

Applying the framework:

• Inventory entry. "Mark down short-dated fresh produce in this store today: no, 30% or 50%?" Daily, high frequency, fully reversible, moderate value per decision and high value in aggregate.
• Owner. Store fresh manager decides within policy limits; the category manager owns the policy table; regional operations performs the audit.
• Metrics. Outcome: fresh margin after waste. Trigger: projected unsold units at close, from stock on hand, days to expiry and the day's sales rate. Guardrail: full-price sell-through on the same lines, so markdowns do not cannibalize regular sales.
• Threshold. Alert the store when projected unsold units exceed the store's control limit, by mid-afternoon, with the recommended markdown level from the policy table.
• Loop. Record markdown taken or not taken, and next-morning waste. Run a four-week test with 20 stores holding the old practice as a control.

The numbers would be specific to the chain. The design point is general: the regional waste dashboard did not need replacing. It needed a daily decision underneath it.

Anti-patterns to retire

Some patterns recur in almost every BI estate. Each has a direct fix.

Vanity metrics. Eric Ries popularized the term in The Lean Startup for numbers that look good and inform no decision, such as cumulative registrations or total page views. In enterprise BI they appear as "total reports published" or "dashboard views". If a number only ever goes up, it is probably not a trigger.

Dashboard sprawl. Reports multiply because creating one is cheap and retiring one is politically costly. Use the usage data your platform already provides, map each surviving report to an inventory decision, and archive the rest on a published schedule.

Orphan alerts. Alerts sent to a distribution list rather than a decision owner, with no playbook. They train people to ignore the channel.

The metric becomes the target. Economists know this as Goodhart's law. Any metric tied to incentives needs a guardrail metric and periodic review of how it is being achieved.

Automating before learning. Moving a decision to full automation before there is a recorded history of outcomes. The case for doing it in stages, with evidence at each step, is set out in the executive guide.

What to do in the next 90 days

1. Pick one business unit and build its decision inventory: 20 to 40 decisions, each with frequency, value, reversibility, current basis and latency.
2. Assign RAPID roles for the top ten decisions by value, with written decision rights for each D.
3. Rebuild metrics for three decisions as outcome, trigger and guardrail, and remove everything else from those owners' primary view.
4. Replace fixed thresholds with statistical ones for those three triggers, route alerts to the owner with a playbook, and set an alert budget.
5. Start a decision log and review it monthly with the owners, including alert precision.
6. Run a sprawl audit: export usage data covering a full quarter (built-in Power BI usage reports keep only 30 days), map surviving reports to inventory decisions, and publish a retirement list.
7. Run one controlled test on a frequent, reversible decision and use the result to decide whether to augment or automate it.

For deciding which of these initiatives earn investment, the prioritization method in how to select enterprise AI use cases applies equally to decision intelligence work.

Frequently asked questions

Why don't dashboards lead to better decisions?

Because most are designed around available data rather than specific decisions. They lack a named owner with decision rights, a threshold that triggers action, defined options, and any record of what was decided and what happened next.

What is a decision inventory?

A list of the recurring decisions in a business area, written as questions with finite answers, with each decision's frequency, value at stake, reversibility, current basis and latency. It replaces the report catalogue as the organizing list for analytics work.

How do you avoid alert fatigue in business monitoring?

Derive thresholds from the point where the owner's best action changes, use statistical control limits rather than fixed percentages, route alerts to a single owner with a playbook, cap alert volume, and retire rules that are routinely dismissed.

What are vanity metrics?

Numbers that look impressive but do not inform any decision, such as cumulative totals or raw page views. A useful test is whether a change in the number would change what a named owner does next.

Sources and further reading

• Dashboards for improving patient care: review of the literature, Dowding et al., International Journal of Medical Informatics, 2015.
• Dashboards for visual display of patient safety data: a systematic review, Murphy et al., BMJ Health & Care Informatics, 2021.
• What Do We Talk About When We Talk About Dashboards?, Sarikaya et al., IEEE Transactions on Visualization and Computer Graphics, 2019.
• Monitor usage metrics in Power BI workspaces, Microsoft Learn, updated May 2026.
• Amazon.com 2015 Letter to Shareholders, Amazon.com, Inc., filed April 2016.
• RAPID: Bain's tool to clarify decision accountability, Bain & Company, 13 October 2023.
• What are Variables Control Charts?, NIST/SEMATECH Engineering Statistics Handbook, section 6.3.2.
• Overriding of drug safety alerts in computerized physician order entry, van der Sijs et al., JAMIA, 2006.
• CFPB fines Wells Fargo $100 million, Consumer Financial Protection Bureau, 8 September 2016.
• Performing a Project Premortem, Gary Klein, Harvard Business Review, September 2007.
• Building a Culture of Experimentation, Stefan Thomke, Harvard Business Review, March–April 2020.
• Data Management and Personal Data Protection Standards, National Data Management Office, SDAIA.