Nobody trusts the dashboard
If executives still ask for the spreadsheet after you've shipped the dashboard, the problem isn't the chart. It's that two systems disagree and nobody owns the definition.
A recognisable failure: an institution invests in business intelligence, ships a good-looking dashboard, and six months later the executive committee is still working from a spreadsheet a manager assembles by hand. The dashboard is open in a browser tab. Nobody uses the number.
This is almost never a visualisation problem, and the instinct to redesign the charts wastes another quarter.
It is a trust problem, and trust broke at a specific moment. Somebody compared the dashboard's figure for total lending against the one in the monthly pack, found a difference, could not get an explanation within the meeting, and quietly stopped relying on it. Once that happens, no amount of polish brings the audience back — they have learned that the number might be wrong and that nobody can tell them why.
Three things cause it.
The first is that nobody owns the definition. Ask five people in a bank what a customer is and you will get five answers: unique national ID, unique account holder, anyone with an open account, anyone with a balance above zero, anyone transacting this month. All are defensible. All produce different totals. Without a written, owned definition, the dashboard uses whichever the developer picked and the monthly pack uses whichever the manager has always used, and both are right, and they disagree, and everyone concludes the system is broken.
The fix is unglamorous: a definition per headline metric, written in a sentence, with a named human owner who arbitrates. Not a data dictionary nobody reads — a short list of the twenty numbers that matter, and who decides what each one means.
The second is timing that nobody surfaces. The dashboard reads a warehouse loaded at 2am. The core system is live. At 11am on a Tuesday these disagree, correctly, and the difference is a day of trading. If the dashboard does not say prominently what it is as of, every user eventually catches it out and concludes it is unreliable, when it was accurate all along.
Put the as-of timestamp on the screen, in the same visual weight as the number. Make staleness loud when a load fails. A dashboard that says clearly that it could not refresh this morning keeps its credibility; one that silently shows yesterday's number as if it were today's loses it permanently the first time somebody notices.
The third is that the underlying data is genuinely wrong and the dashboard is the first thing to show it. This is the most common case and the one people are least willing to say out loud. Duplicate customer records because there was no deduplication at onboarding. Branch codes that changed in 2021 with no history kept. A product reclassified retrospectively so last year's mix no longer reproduces. The reporting layer did not create any of this — it made it visible, and it gets blamed for it.
When that happens, the only recovery is to fix the source and say so. Publish what was wrong, what it affected, what was corrected and from when. Institutions are extremely reluctant to do this, because it feels like admitting the numbers were bad. But the alternative — quietly correcting and hoping nobody re-runs an old report — guarantees that the next discrepancy is read as another unexplained error.
The pattern underneath all three is the same. Trust in a number is not established by the number being right. It is established by discrepancies being explainable, quickly, by someone with authority to say what the definition is.
Get that and a plain table will be believed. Miss it and the most beautiful dashboard you have ever built will lose to a spreadsheet on a manager's laptop, every time.