top of page

Why nobody uses the reports you build

2 days ago
6 min read

Leadership teams stop using reports for five reasons. The report answers a question nobody asked, it arrives after the decision, nobody agreed what the metric means, it takes too long to read, or no one owns acting on it. None of these is a charting problem, and a better design will not fix any of them.

I have built or overseen more than 1,000 dashboards in ten years, and the pattern holds. The reports that get used were built backwards from a decision someone has to make. The reports that get ignored were built forwards from whatever data was easy to reach. Below are the five reasons and the fix for each.

The five reasons at a glance

Reason

What it looks like

The fix

1. It answers a question nobody asked

Pages of metrics, no decision attached

Start from the decision, then pick the metric

2. It arrives after the decision

A monthly report for a weekly decision

Match the refresh to the decision cadence

3. Nobody agreed what the metric means

Two people quote two different revenue numbers

Write one signed-off definition per metric

4. It takes too long to read

The summary needs a walkthrough

Hold page one to a 15-second read

5. No one owns acting on it

Everyone sees the number, nothing changes

Name one owner and put it on the agenda

1. It answers a question nobody asked

Most reports are built from the data that is available instead of the decision that is waiting. Someone asks for a sales dashboard, and the builder puts everything in the CRM on one page. Leadership opens it, cannot find the thing they were wondering about, and goes back to asking a person.

One client's reporting centered on how much their field team traveled. The question leadership cared about was how well the field team performed. Travel is activity. Performance is the result, and it is the number a leader can act on.

The fix: start with the decision. Before any chart exists, write down what choice this report will change and who makes it. A request for a sales dashboard becomes a better report once it is rewritten as a question: which deals will close this quarter, and what do we do about the ones that will not? The business goal sets the focus, the visuals and how often the report refreshes. You do not need all of your data for this, only the data that decision depends on. Then show a first draft to that person before it is final, because they will tell you what you got wrong faster than any requirements document.

2. It arrives after the decision

A report that lands on the 12th of the month cannot inform a decision made on the 5th. Once leadership learns to decide without it, that habit tends to outlast the fix.

One client ran a monthly "data day." Once a month, the team spent a full day pulling data together by hand and then produced the report. That process became a seven-minute update, and they got the day back.

The fix: match the refresh to the decision. Ask how often leadership decides, then refresh at that rate. Cadence depends on the decision, not on the data. Weekly decisions need weekly numbers, even if the data is rougher. Build for the refresh, not the rebuild. Finance teams usually lay data out horizontally, with a new column every month. Go vertical instead, with one row per record and new months added at the bottom. Then a refresh means adding rows, not rebuilding the report.

3. Nobody agreed what the metric means

Three people can look at the same month and report three different revenue figures, and each of them can be right. Here is an illustrative example for a $6 million services firm:

Who

What they mean by revenue

March figure

Sales

Contracts signed in March

$520,000

Finance

Invoices issued in March

$455,000

Owner

Cash received in March

$410,000

Put those three numbers in front of a leadership team and the meeting becomes an argument about which one is right. After that, nobody fully trusts the report, and they are right not to. Revenue, margin, headcount and utilization cause this most often, because every department counts them a little differently.

The fix: write one definition for each metric on the report. State what it counts, what it excludes, which system it comes from and who signed off. Put the definition on the dashboard itself, not in a document nobody opens.

4. It takes too long to read

If a leader needs a walkthrough to understand the first page, the report has already lost. Leaders open reports between meetings and give them a few seconds. If the answer is not there, they close it and ask a person.

My standard is 15 seconds. Someone who has never seen the dashboard should be able to say whether things are on track in that time. I set that bar after building dashboards for C-suite clients, and it rules out most of what gets put on a first page.

The fix: build two layers. Page one is the summary: a handful of numbers, each one compared to a target or last period, and nothing else. Anything that does not change what the reader does belongs on page two or nowhere. The detail goes on a second page for the person who wants to dig. Test page one by showing it to someone cold and timing them.

5. No one owns acting on it

A report that everyone can see and nobody is responsible for becomes wallpaper. The numbers move, people nod, and nothing changes, because no one was asked to do something about the movement.

Early in my career I was an analyst, and my boss kept calling me into his office for numbers. Our team adopted a strategy of easy data first, and after that I was called in about five times less. Meetings got shorter and fewer, and they changed shape. They stopped being "let's figure out the numbers" and became "given these numbers, what should we do?" I had no stake in it beyond saving myself the trips, and I have since watched the same shift happen at clients.

The fix: assign one owner to each metric and make the report the first item on the meeting agenda. The owner's job is not to explain the number. It is to say what they are doing about it.

Fix the definition first

If you can only fix one, fix the definition. The other four depend on it. A report that answers the right question still fails if the answer is disputed. A faster refresh just delivers the disputed number sooner. A 15-second summary produces an argument instead of a decision. And an owner cannot act on a number that two people read differently. Once everyone means the same thing by revenue, margin or utilization, the other fixes get easier and they stick.

Check your own report this week

Pick the report your leadership team opens least and ask five questions:

  1. What decision does it change, and who makes it?

  2. Does it refresh at least as often as that decision is made?

  3. Could two people quote the same metric and get different numbers?

  4. Can a first-time reader get the point in 15 seconds?

  5. Who is responsible for acting on it, by name?

Any answer you cannot give in one sentence is a fix to make, and if question 3 fails, start there.

Where this leads

Fixing the five gets you a report that is worth opening. Getting a team to open it every week is a rollout problem with its own fixes: a first session where someone walks leadership through it, and a standing slot in the monthly meeting where it gets opened. We cover that in our guide to getting a team to use the dashboard.

Teams that do all of this consistently end up with what I call a data-driven culture. Dashboards lead the meetings. Decisions rest on agreed numbers. Meetings are about strategy and action, not about what the numbers were. It is the shift from my old boss's office, applied across a company.

If you would rather build this with someone than alone, a fractional analyst engagement is how we do that. We start from your business goals and work toward the technical steps.

Recent Posts

See All
How to Measure ROI from Analytics

Analytics ROI comes down to one formula: (Value of decisions made faster or better, minus the fully loaded cost of the analytics work) divided by that cost. If the ratio is positive, the investment pa

 
 
 
Do You Need a Data Warehouse to Build Dashboards?

No. Most small businesses don't need a data warehouse to build dashboards. If you're working with one or two source systems and don't need to preserve history the source system throws away, you can bu

 
 
 

Comments


bottom of page
google-site-verification=7fuOdQZl6NNaaA7lAulMXKyRKuL17mb_-BaSAtR8v7s