Dashboards: record the decision, not just the number
Which decision last quarter did your management dashboard actually change? If the answer depends on memory, the panel cannot prove it was useful. A dashboard earns its place when you can point, months later, to a decision it changed. For that, the system has to store the decision next to the number that prompted it: date, indicator, value, choice, owner and review date.
Why doesn't a good-looking panel prove the decision improved anything?
Because the panel answers "what happened" and the decision answers "what did we do about it." They are different records, and it is common for a company to have only the first.
Think of the monthly results meeting. The panel is on screen, margin has dropped, someone proposes revisiting the price of two products, the group agrees. The meeting ends. The decision lives in minutes, an email or the memory of whoever attended. Two months later the panel shows margin back up. Was it the price? The sales mix? Seasonality? Nobody can separate them, because the system kept the effect and lost the cause.
This is an architecture problem, not a BI tool problem. The tool draws the chart as well as you ask it to. What is missing is a place in the system where the decision has an address, an owner and a date, tied to the indicator that triggered it. If you have read about why dashboard numbers don't match or about too many metrics, you know the pattern: the presentation layer is usually more finished than the layers beneath it.
What does the data say about decisions and foundations?
It says that, at least in AI investment, decision quality gets less money than efficiency, and that results depend on what sits beneath the panel.
In Gartner's March 2026 survey of 204 finance leaders, 45% said their function's AI investments lean toward productivity and 20% said they lean toward decision quality. The sample is CFOs and the subject is AI, not small businesses, and the data shows where investment goes, not whether decisions improved. Even so, it points to the pattern: most of the money aims at doing things faster, and a smaller slice aims at deciding better.
The second data point comes from another Gartner study, of 353 data, analytics and AI leaders surveyed in November and December 2025. Those reporting successful AI initiatives invest up to four times more, as a percentage of revenue, in foundation areas: data quality, governance, AI-ready people and change management. The focus is AI again. What matters for your panel is the same: the result comes from what sits below the visible layer.
The third data point shows why this weighs more on smaller companies. According to Eurostat, in 2025 only 11% of small EU enterprises (10 to 49 people) used business intelligence or data analysis software, against 69% of large ones. The data suggests that in smaller companies analysis tends to depend on manual work, which is why the record has to be born in the system, not in someone's goodwill. That is our inference, not a finding of the survey.
The three sources cover different populations and should not be added together. Read side by side, they support a working hypothesis: deciding better is a foundation question, and the recorded decision is a part of the foundation that rarely shows up in system design. Technology, artificial or not, shows the number. Choosing what to do with it is still a human job, and the system has to keep that choice.
What should you record so the panel can be evaluated?
Six fields, filled in when the meeting decides.
The first is the indicator and its value that day, frozen. The panel changes with every refresh, and the decision must point to the number that prompted it, not to today's number.
The second is the decision, in one sentence: what will be done, not what was discussed.
The third is the owner, one person. A decision with a collective owner is hard to follow up.
The fourth is the review date, which says when the indicator will be looked at again to check the effect.
The fifth is the hypothesis: why the action is expected to move the number. It is the most uncomfortable field and the most useful, because it separates a decision from a reaction.
The sixth is the outcome, filled in on the review date: the indicator moved, stayed the same or got worse. With this field, the panel gains a memory.
These fields become a record in the system where the indicator lives, with history and no retroactive edits. A spreadsheet is enough to start, but the logic is the same traceability and version history that supports audit in the document management platform behind the Repap On case. Management decisions deserve that discipline.
A practical example: the margin that came back and nobody knew why
The scenario below is hypothetical, and the numbers are illustrative assumptions, not measurements. A solar energy company with 60 employees and monthly revenue of $1.5 million tracks margin per project on a monthly panel. In March, average margin drops from 22% to 17%. In the meeting, leadership decides to renegotiate with two inverter suppliers and raise the minimum quote for residential jobs.
By June, margin is at 21%. Leadership celebrates. In August the board asks which of the two actions worked, because the supplier renegotiation strained relationships and the price increase cost the sales team two contracts. Nobody can answer. March's minutes cover both actions in one paragraph, with no hypothesis and no review date. The panel shows the number, and the cause depends on who remembers.
Now the same scenario with the record. In March each action becomes an entry: indicator frozen at 17%, decision, owner, hypothesis ("inverter cost explains most of the drop"), review in 60 days. At review, each outcome sits next to the other. If margin rose because the supplier gave way and the price increase only cost contracts, leadership sees it and reverses the increase. The panel is the same. What changed is the question the system can answer.
How do you start without building a data project?
Start with a recurring meeting where the panel is already used and add a two-minute step at the end: each decision becomes one line with the six fields. In eight weeks you will have enough to see which indicators produce decisions and which only decorate the screen. That period is a planning reference, not a measurement.
Then move the record to where the indicator lives. If the indicator is born in the ERP or an internal system, the decision should sit next to it, linked to the number. The logic is the same as in when to replace spreadsheets with custom software: the spreadsheet shows the habit, and the system makes it survive staff changes.
The last step is a maintenance rule. An indicator that produced no decision in two review cycles leaves the main screen. That gives the panel back its job of supporting choices.
Frequently asked questions
My team resists change. Won't recording decisions become more bureaucracy?
It will, if it is a long form. That is why there are six fields, filled in two minutes inside the meeting that already exists, with no new meeting. In general, adoption improves when the team sees the record defending a good decision, not only asking for justification.
I can't see how to measure the result. Does the record help?
It does, because it creates the comparison. Each decision stores the indicator's value before and the review date. It does not prove cause on its own, since other factors move at the same time, but it reduces arguments from memory and shows which decisions have a pattern of effect.
I worry it won't remove the real bottlenecks. What does the record change?
It does not remove bottlenecks by itself. What it does is show where decisions stall: absent owner, review that never happens, hypothesis nobody knows how to write. Those points show where the information architecture fails, and the fix starts there.
The next step
If you want to see which system should hold the decisions behind your dashboard, the Operational Architecture Diagnostic, a 30-minute conversation, is a way to start: talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic