Why does nobody actually open the dashboard we paid for?
Because a dashboard is a pull system: it asks the viewer to remember to open it, scan it, decide whether anything changed, and work out what to do. Most people will not do that daily for information that is usually unremarkable. Dashboards get opened when something is already known to be wrong. The fix is to push exceptions to people and keep the dashboard as the place they go to investigate.
A pull tool in a business that runs on interruptions
Service businesses are interrupt-driven. The phone rings, a tech calls from a roof, a job goes sideways, a crew is short. Nothing in that day contains a natural moment where someone stops and asks "what does the dashboard say?" The dashboard is competing for attention against things that are actively demanding it.
That is not a design flaw you can style your way out of. It is a mismatch between how the information is delivered and how the reader lives. Pushed briefs work because they arrive; dashboards only work once someone already has a question.
Three failure modes, in the order we usually find them
The third one is fatal. Trust in reporting is asymmetric: it takes months to build and one unexplained discrepancy to lose.
- No metric has an owner. Twenty numbers on a screen and no name attached to any of them. Everyone assumes someone else is watching, so nobody is.
- No expected range. A number with no sense of normal cannot be scanned. The reader has to reconstruct context every single time, which is real cognitive work, and they will stop doing it.
- Friction and doubt. A separate login, a slow load, and one memorable occasion when the number looked wrong. After that, people go back to asking the office manager.
Instrument your own dashboard before you redesign it
Most teams debate dashboard design without knowing who actually opens it. Log views by user and by panel. You will typically find a launch spike, a decay over the first several weeks, and a small set of panels carrying nearly all the attention. That tells you what to keep and what to delete.
If your reporting cannot tell you who looked at it, that is the first thing to fix, and it is a good early test of whether whoever built it thought about use rather than just display.
What replaces it
The pattern that survives is a short written brief that names what changed and what needs a decision, with every line deep-linking into the dashboard view that explains it. The brief does the remembering. The dashboard does the investigating. Neither is asked to do the other's job.
That is also the difference between a reporting tool and operational AI — one displays state, the other decides that state is worth someone's attention.
The one kind of dashboard that always survives
There is a reliable exception: a dashboard attached to a recurring meeting. If the weekly ops meeting opens with the same screen every time, it gets used, because the habit already exists and the dashboard is riding on it.
So rather than trying to create a new daily habit around a link, attach the view to a ritual that is already on the calendar and make that view the agenda. The metrics people argue about in that meeting are, by definition, the ones worth keeping. Everything else can move to a drill-down.
Topics: dashboard adoption · exception reporting · reporting design · daily briefs
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.