A dashboard nobody opens is a dashboard that does not exist. The most common reason a custom build fails is not bad data or wrong widgets. It is a rollout that ends on day seven and leaves the team to discover the tool by accident. The fix is a short, deliberate rollout pattern.
Below is the rollout we have run, with small variations, for every client. It takes about three weeks of light effort, starts on the day of go-live, and turns a dashboard from a thing-on-a-URL into a daily habit.
Week zero: ship to the smallest possible audience
The day-seven go-live should reach two people: the executive sponsor who paid for the build and the operational owner who will live in the dashboard most. Nobody else. Resist the urge to send the URL to the whole team.
Those two people get one week to break it in. They will find things we did not, because they know the workflow at a depth we cannot reach. We fix what they find before week one ends.
Week one: the standing nudge
At the start of week one, we add the dashboard URL to two places that the rollout depends on.
- The team's standing meeting agenda. The first three minutes of every weekly meeting become "open the dashboard together". This is the single highest- leverage habit in the rollout.
- A daily Slack message at 8:55am, pulled from the change tile. People open the dashboard because the message intrigues them, not because they were told to.
Both habits are removable. Most clients keep the meeting ritual and drop the Slack message by week six. By then, the team opens the dashboard without prompts.
Week one and two: training on the live thing
We do not run a separate training session. Training happens in the meeting where the team uses the dashboard for real work. The operational owner narrates while opening tiles, drilling down, and filtering. We sit silently in the room and only step in to fix bugs.
Two of these are enough. After two meetings, the team has the same fluency they would have had after four hours of classroom training, and they remember it because they used it.
Week two: kill the parallel tools
Two weeks in, look at which old reports are still being maintained. The Excel that finance updates on Tuesday. The Notion page someone keeps in sync. Either retire them, or acknowledge that the dashboard is missing something they provide and add it.
The dashboard cannot win against a parallel tool. If both exist, the team uses both, and uses both worse.
Week three: the "something is missing" review
Three weeks in, we run one structured review. Three questions, with the operational owner and one stakeholder.
- Which tile have you looked at every working day this week?
- Which tile have you never looked at?
- What did you go to a different tool for this week?
The first question confirms what is working. The second identifies tiles to cut. The third identifies what to build next. In about a third of cases this is where we agree on the second dashboard.
The signs the rollout has worked
Three signals show up by week four.
- The dashboard gets opened nine or more times a day across the team, not just on Mondays.
- Somebody we did not train shows somebody else how to use it. This is the most important signal of all.
- The team starts saying things like "hold on, let me check the board" in conversation, instead of pulling out a spreadsheet.
What we do if the rollout stalls
Two interventions, in order.
- Ask the operational owner to use the dashboard alone for a week, and report what they avoid. If they avoid it too, that is a layout problem, and we rebuild the tile causing the avoidance.
- If the layout is fine and the team still does not adopt, almost always the cause is a missing tile that the team is not asking for because they did not know it could exist. Sit with the team for an afternoon and watch them work without prompting. The missing tile is usually visible within an hour.
We have never had a build that did not adopt after these two interventions. The first time we do, we will write a longer article about that.
