Reports go unopened for three reasons. The report answers questions nobody actually asked. People do not trust the numbers in it. Or getting to the one figure they came for takes longer than asking a colleague.
All three are design problems, and none of them are fixed by more training, better promotion or a mandate from a director. Those are the three things usually tried, in that order, and they fail because the report is doing exactly what it was built to do. It was built for the wrong thing.
What is the actual cause?
| What you observe | Likely cause | What fixes it |
|---|---|---|
| Opened once at launch, never again | Built for imagined users, not real questions | Ask the two questions people actually ask |
| People ask you for figures that are on it | They can't find them, or don't believe them | Cut the report down, or fix the trust problem |
| They export to Excel immediately | The report doesn't do what they need it to do | Watch what they do in Excel, build that |
| Used by the person who commissioned it, nobody else | Designed in one conversation with one stakeholder | Talk to the people who'd use it daily |
| Everyone says it's great, usage is near zero | Politeness. Nobody wants to criticise your work | Look at the usage figures, not the feedback |
| Used heavily for a week each month | That may be correct and fine | Not every report needs daily use |
The last row deserves its own note. Low usage is not automatically failure. A board pack read carefully once a month by six people can be the most valuable report in the business. Judge against what the report is for, not against a target of daily active users, which is a metric borrowed from consumer software and mostly meaningless here.
The two-question test
Before anything gets built, someone should be able to answer this: what are the two questions this report exists to answer, and who acts on the answers?
Not five, not "give visibility into performance". Two questions, phrased the way a person would say them, with a named individual who does something differently depending on the answer.
Most unopened dashboards fail this test at the design stage and nobody notices, because the requirements process asked what people wanted to see rather than what they needed to decide. Those two questions produce very different reports. "What would you like to see?" gets you a wish list, everything on the wish list gets built, and the result is a report where the two things that mattered are buried among forty that did not.
When a report is genuinely built around two questions, the design gets easier. The most important figure goes top left, at a size that makes it unmissable. Everything else earns its place by supporting the answer or gets cut. That is what makes the difference between a report someone glances at for four seconds and gets what they needed, and one they have to study.
Trust is the invisible cause
The failure people rarely admit to: they do not believe the numbers.
Nobody says this out loud. Telling a colleague their report is wrong is awkward, especially if they cannot prove it. So they keep their own spreadsheet, use that, and are perfectly pleasant about the dashboard in meetings. Usage collapses and the feedback stays positive, which is why the feedback is worthless and the usage figures are not.
The cause is usually one bad experience. The report disagreed with a figure someone knew was right, and it happened at a moment that mattered. After that the report is guilty until proven innocent, and proving innocence is much harder than it sounds, because trust is not restored by the report being right for six months. It is restored by someone explaining why it was wrong that one time.
If you suspect this is your problem, the diagnostic is direct: ask three people who should use the report where they actually get that number. If the answer is a spreadsheet, you have a trust problem, not an adoption problem. What sits underneath it is usually a definitions disagreement, described in six reports, six different numbers, and sometimes a refresh that failed silently and served stale figures without saying so, which is covered in why your Power BI refresh keeps failing.
The speed problem
If the report takes eleven seconds to load, people will not use it for a ten-second question. They will message a colleague instead, because that feels faster even when it is not.
This is a small thing that has an outsized effect on habit formation. A report has to be quick enough that opening it is not a decision. Anything that makes someone think "I'll check that later" has effectively lost, because later does not come.
Slow reports are usually slow for structural reasons rather than mysterious ones, and the ranked causes are in why your Power BI report is slow. It is worth treating as an adoption issue and not just a technical one, because that is how it actually shows up.
The export tell
When people open a report and immediately export to Excel, that is the most useful diagnostic signal you will get, and it is usually treated as a nuisance to be blocked.
Do not block it. Go and watch what they do in Excel. Nine times out of ten they are doing something specific and repeatable: filtering to their own accounts, adding a column the report does not have, comparing to a target that lives in a different file. That activity is the report you should have built. They have specified it for you, in the most reliable way possible, by doing it every week.
What actually improves adoption
Build for two questions, not twenty. Cut ruthlessly. A report that answers two things well beats one that covers everything badly, and the cutting is the hard part because everything on the page has a supporter.
Put the answer where the eye lands first. Top left, largest, unambiguous. If someone has to hunt for the number the report exists to show, the design is wrong regardless of how good the underlying model is.
Make the definitions visible. A short note saying what "active customer" means here, on the page, removes an entire class of quiet disagreement. It also stops the report being blamed for a difference that was actually correct.
Fix the trust incident properly, and say so. If the report was wrong once, tell people what happened and what changed. Silence gets read as it never being fixed.
Design so people can actually read it. This includes colour. Around one in twelve men has some form of colour vision deficiency, and a report that encodes its meaning purely in red and green is unreadable to a portion of its audience who will not necessarily tell you. I am red-blind myself, so this is not a hypothetical for me, and the practical rules are in colour-blind-safe Power BI.
Check the usage figures rather than asking. People are polite. Usage data is not.
Is it worth rebuilding, or starting again?
If the underlying model is sound and the problem is design, a rebuild of the report itself is usually days rather than weeks, and the model you already paid for keeps its value.
If the numbers are wrong or contested, fix that first, because a beautifully redesigned report showing figures nobody believes gets exactly the same usage as the old one. Sequence matters: trust, then speed, then design. Fixing design first is the most common way to spend money and change nothing.
If you are not sure which category you are in, a health check scores the model and the reports separately, which is precisely the distinction you need before deciding what to rebuild.
Common questions
Why is nobody using our Power BI dashboards?
Usually because the report answers questions nobody asked, because people do not trust the figures, or because it is too slow to be worth opening for a quick question. Check trust first by asking three intended users where they actually get the number from.
How do I improve Power BI adoption?
Cut the report down to the two questions it exists to answer, make the main figure impossible to miss, ensure it loads fast enough that opening it is not a decision, and resolve any outstanding disagreement about the numbers. Training and mandates do not fix a report built around the wrong questions.
Should I force people to use the dashboard?
You can, and it produces compliance rather than use. People will open it because they were told to and continue making decisions from their spreadsheet. Mandates also destroy the diagnostic signal, because you can no longer tell from usage whether the report is any good.
Why do people always export to Excel?
Because the report does not do the thing they need. That is worth investigating rather than blocking: watch what they do after exporting, because it is a precise specification of the report they actually wanted, delivered by demonstration.
How many people should use a report?
However many need it for their decisions. A report used by six people monthly can be more valuable than one used by two hundred daily. Judge it against its purpose, not against usage targets borrowed from consumer software.
Is low usage always a design problem?
Not always. Sometimes the business question genuinely went away, or the report was built for a project that ended, in which case the right answer is to retire it rather than fix it. Reports that no longer have a purpose should be removed, not improved, and clearing them out makes the remaining ones easier to trust.