Dashboards Do Not Fix Bad Data

A dashboard is a presentation layer. It takes numbers from somewhere and displays them attractively. It has no capacity to tell whether those numbers are correct, and its polish actively works against anyone who suspects they are not.

This matters because dashboards are usually bought as a solution to a data problem. They are not. They are a solution to an access problem — and only when the data underneath is sound.

What actually happens when you build on bad inputs

Wrongness gains authority. A number typed in an email invites scrutiny. The same number in a well-designed chart on a large screen does not. Presentation confers credibility that the underlying data has not earned.

Errors become harder to trace. In a spreadsheet you can follow the arithmetic. In a dashboard the transformation is hidden inside a query nobody in the room can read. When a figure looks odd, the conversation stops, because nobody can check it during the meeting.

Disagreements become political. Two dashboards showing different revenue figures produce an argument about which team is right rather than an investigation into which definition differs. This is one of the more corrosive things that can happen to an organisation's relationship with its own data.

Bad data gets locked in. Once a dashboard depends on a field being populated in a particular way, fixing the underlying process becomes a change that breaks reporting. The workaround becomes permanent.

Confidence rises while accuracy does not. The most expensive outcome. Decisions get made faster, on the same unreliable basis, with less hesitation.

Where bad data comes from

It is rarely one big fault. It is an accumulation of small, reasonable things.

Optional fields. A field that can be left blank will be left blank, and any metric derived from it is computed over a self-selected subset. This is the single most common cause of quietly wrong reporting.

Free text where a list belongs. "Source of enquiry" as a text box produces "Google", "google", "google search", "web", "internet" and "GOOGL". Any grouping of these is a guess.

Inconsistent definitions across teams. Sales counts a deal at signature, finance at invoice, operations at delivery. Three correct answers, one label.

Timing and timezone mismatches. Systems recording in different timezones or with different day boundaries produce reconciliation gaps that look like real business variation.

Records created for the wrong reason. Duplicates created because search was slow. Test records never deleted. Placeholder customers created to get past a required field.

Backfilled and corrected data. A system where past records are edited will produce reports that change retrospectively, which destroys trust faster than being wrong in the first place.

Manual steps in the pipeline. Any export, reshape and re-import performed by a person is a place where a filter gets left on. See the hidden cost of re-entering the same information.

Doing it in the right order

1. Pick the few decisions the reporting is meant to support. Not "we want visibility." Specific recurring decisions: where to spend marketing budget, which service line to expand, whether to hire.

2. Identify the minimum data those decisions need. Usually a handful of fields. This is a much smaller problem than "get all our data in order", which is a project that never finishes.

3. Fix the capture of those fields. Make them required. Replace free text with a short list. Remove the fields nobody uses so the important ones get attention. Capture at the moment the fact is known, not later from memory.

4. Check them against reality. Take twenty records and verify them by hand against the source. This is tedious and it is the step that tells you whether anything that follows is worth building. Doing it once is informative; doing it quarterly is a control.

5. Then build the reporting. With definitions written down and visible next to each figure.

6. Keep a way to drill to the underlying records. Every number should be clickable down to the rows behind it. This single feature does more for trust than any amount of visual design, because it lets a sceptic settle the question themselves.

Signals your data is not ready

• Two people produce different figures for the same thing and the difference is never resolved.
• A regular part of preparing the report is "cleaning it up."
• Certain records are excluded by convention that is not written down.
• The report is prepared by one person and nobody else could reproduce it.
• People check the dashboard and then ring someone to confirm.

That last one is definitive. If the dashboard exists and people still verify by phone, it has not replaced anything. It has been added.

A reasonable position

None of this is an argument against dashboards. Once inputs are trustworthy and definitions agreed, good reporting is genuinely valuable: it removes the delay between a question and an answer, and it lets more people make decisions without going through one analyst.

The argument is about sequence. Reporting is the last step, not the first, and a business that has not done the earlier steps will get a faster, prettier route to the same misunderstandings. Before purchasing anything, see what to know before buying analytics software.

The uncomfortable version of this advice is that the useful work is upstream, unglamorous and mostly consists of removing optional fields and agreeing on definitions. It is also the only thing that makes the dashboard worth having.