Why Dashboards Do Not Drive Decisions
- Attach a threshold, an owner, an action and a review date before a metric is reported.
- Name one person per metric, because a metric owned by a team is owned by nobody.
- Agree the action in advance, while nobody is under pressure to defend a number.
- Retire every metric nobody will act on at any value, since each one costs attention.
- Treat alerting as one field of four rather than as a solution.
- Expect better data to improve trust in the report and not the rate of decisions.
Last updated: November 2026
Dashboards do not drive decisions, and after thirteen years of watching growth teams build them I no longer think the problem is the dashboard. A reporting layer reports state. It tells you what the number is. A decision needs three things a state report does not contain: the value at which somebody has to act, the person who has to act, and what they are going to do. Omniconvert has run 70,000+ experiments across 2,500+ Shopify stores over 13 years in eCommerce, and the teams that decide quickly are not the ones with the better reporting.
This is a different problem from the cost of assembling the data, which I have written about separately in the real cost of human middleware. A team can fix the assembly entirely, arrive at a fast and trustworthy dashboard, and still take the same number of decisions per quarter as before.
Dashboards do not drive decisions because they report state
Watch what happens in the meeting. A metric is down. Somebody asks whether that is bad. Somebody else says the answer varies by segment. A third person offers to pull it apart and come back. The number was correct, visible and timely, and the meeting produced a task rather than a decision.
That sequence is not a failure of discipline. It is the predictable result of presenting a number to a room that has not agreed in advance what any particular value of it would mean. The interpretation is being improvised, under mild social pressure, by people who each have a different stake in the answer.
eCommerce managers spend roughly three hours a day assembling data [CROBenchmark Report 2026, Omniconvert]. The hours are the visible cost. The invisible one is that the output of all that work is a number with no agreed interpretation attached, which is why the next step is so often another analysis.
The Decision Contract, in four fields
A decision contract is defined as the agreement, recorded before a metric is published, that specifies the value at which that metric requires action, who is accountable for taking it, what the action is, and when the agreement itself is reviewed. It is short on purpose. Anything longer does not get maintained.
The ordering matters. The threshold is agreed while nobody is under pressure, which is the only condition under which it gets set honestly. In the meeting where the number has already moved, every threshold proposal is read as a position about whose work is in question.
| Field | What it settles in advance | Its absence produces |
|---|---|---|
| Threshold | Whether this value is acceptable | A debate about interpretation |
| Owner | Who acts, by name | A debate about whose call it is |
| Action | What happens at the threshold | A request for more analysis |
| Review date | When the contract is revisited | A stale rule, quietly ignored |
Four rows, and each one removes a specific conversation that currently happens every time the number moves. That is the whole mechanism. There is nothing clever in it, and the reason it is rare is that writing a threshold down commits somebody to something, which a dashboard never does.
One named owner, never a team
This is the field teams resist most, and the resistance is understandable: naming a person looks like assigning blame for a number they do not fully control. In practice it does the opposite, because the action is pre-agreed. The owner is accountable for executing a decision the group already made, not for the metric's behaviour.
Where the owner is a team, the predictable thing happens. The number crosses its threshold, two people each assume the other is handling it, and a fortnight passes. Nobody behaved badly, and the contract had a hole in it where a name should have been.
There is a second-order benefit worth naming. Once each metric has an owner, the question of how many metrics a person can reasonably own answers itself, and dashboards shrink without an argument about which charts to delete.
Retiring the metrics that have no contract
Run the four fields against your current dashboard and a split appears immediately. A handful of metrics take all four fields easily. Most take a threshold with some argument and then fail at the action, because the honest answer to what would happen is nothing.
Those are not bad metrics. Several of them are genuinely informative, and they belong in an analysis document rather than on the screen a team makes decisions from. Mixing the two teaches people that the screen is a status display, and after that a real threshold crossing on it does not register either.
Most teams that try this stop at the first two fields, because threshold and owner are uncomfortable but writable, and the action field forces an admission nobody wants to make in front of colleagues: that for two thirds of the dashboard, nothing would happen at any value. The exercise only works if you say at the outset that discovering a metric has no action is the intended output rather than a failure, and that the metric is being moved rather than criticised.
AliveCor used Omniconvert to run a structured A/B testing programme and achieved +21% conversion rate, +5% revenue per visitor, and 94% statistical relevance across their experiments. [Omniconvert, AliveCor case study] The third figure is the one that belongs here. Statistical relevance is a threshold agreed before the result arrives, which is exactly what a decision contract is, and it is why a testing programme produces decisions where a dashboard produces discussions.
Why better data does not fix this
This is the most expensive misdiagnosis in the field, and it is expensive because the project is large, visible and genuinely valuable for other reasons. A team that cannot decide concludes it cannot trust its numbers, spends two quarters on a data platform, arrives at numbers it trusts, and takes the same number of decisions.
Both pieces of work are worth doing and they fix different things. Unifying the data removes the assembly cost and the reconciliation error. Writing contracts removes the interpretation debate. A team that does only the first has a fast, trustworthy dashboard that nobody acts on, which is the most common end state I see.
The commercial case for doing both is well established in the retention literature. A 5% retention lift can raise profits by 25 to 95%, a finding popularised in Harvard Business Review crediting Bain's Reichheld [Harvard Business Review, 2014], and retention decisions are precisely the ones that wait longest for an agreed threshold, because nobody wants to be the person who declares a cohort unacceptable. On the acquisition side the same pattern holds: unexpected cost and unclear information have been among the leading reasons shoppers abandon purchases for as long as Baymard Institute has measured it, at around 70% average cart abandonment [Baymard Institute, 2025], and almost every dashboard reports that number without anybody having agreed what value of it would trigger work.
Where this leads, for us, is a layer that does more than report. Omniconvert Commander (formerly Nexus) unifies commerce data, prioritises experiments by True Profit and generates campaigns and creative you approve before they go live, and the part that matters to this argument is the prioritisation: a ranked next action is a decision contract expressed as software. Omniconvert Explore is where the resulting hypothesis gets proved rather than asserted. The wider argument for treating these as one system rather than three tools is in how CRO, creative and AI visibility tie into one growth system, and the market context is in the state of DTC growth in 2026.
FAQ: dashboards and decisions
Because they report state, and a decision needs three things a state report does not carry: the value at which action is required, the person who owns that action, and the action itself. Without those, a moving number produces a discussion rather than a decision, and the discussion is where it stops.
Four fields attached to a metric before it is reported: a threshold, a named owner, a pre-agreed action and a review date. It converts a number that is interesting into a number that is binding, and it is the shortest specification I have found that reliably changes behaviour.
Alerting delivers the threshold and leaves out the other three. That is why alert channels fill up and get muted: a notification with no owner and no agreed action is a louder dashboard. The owner and the action are what make the threshold worth setting.
As many as have contracts, which is usually far fewer than it currently carries. A metric nobody will act on at any value is costing attention and teaching the room that this screen is for looking at rather than for deciding from.
One named person, never a team. A metric owned by growth or by analytics is owned by nobody at the moment it crosses its threshold, because the first question in the room becomes whose call it is, and that question takes longer to settle than the action would have taken.
No, and it is the most expensive wrong answer available. Cleaner data in a layer with no thresholds and no owners produces a more trustworthy report that still changes nothing. The data work is usually necessary and it is not the reason decisions are not being taken.
Take the three metrics your team looks at most often and write four fields against each one: the value at which somebody has to act, the name of that person, the action in one sentence, and the date the contract is reviewed. Twelve fields, one sitting, no tooling. Most teams find that two of the three metrics cannot be completed, and that is the finding rather than a failure of the exercise.
A metric that cannot carry a threshold and an owner is a metric nobody was ever going to act on, and it belongs somewhere other than the screen the team makes decisions from. The ones that can carry the four fields will start producing decisions within a fortnight, because the number now arrives with its interpretation already agreed.
A number is not a decision
Give three metrics a threshold, an owner, an action and a review date, and watch what changes in two weeks.