How We Build Dashboards Around Machine Learning Predictions
Last updated:
Predictions die in dashboards nobody opens
Good models get attached to bad dashboards all the time. The model scores every customer for churn risk, the scores appear on a beautifully designed page full of charts, and within a month the page has three visitors a week. The model has not failed. The interface has, because it shows information when what people needed was a list of things to do.
So when a SpiderHunts ML project needs an interface, we design it around the action the prediction supports. The question is not what the model knows. It is what the person using it should do next, and what they need to see to do it confidently.
First choice: do you need a new dashboard at all?
Often the right answer is no. If the account team lives in the CRM, a churn-risk field and a sorted view inside the CRM will get used. A separate dashboard will not. We look at where the decision is already made before designing anything new.
| Option | Best when | Watch out for |
|---|---|---|
| A field or column in an existing tool | People already work in the CRM, ERP or spreadsheet | Limited room for reasons and feedback |
| A BI tool such as Power BI or Metabase | You already use one and need trends and filtering | Poor at capturing actions and feedback |
| A custom review screen | People must work through cases and record decisions | Costs more to build; justify it with volume |
| Alerts by email or Teams and Slack | Rare, urgent cases need a fast response | Too many alerts and they get muted |
Many projects combine two: scores written into the main tool, plus a small custom screen for the cases that need review. Our broader thinking on reporting that gets read is in reporting dashboards people actually use.
Lead with the work queue, not the chart
When a custom screen is warranted, the first thing on it is a prioritised list of cases needing attention today. Charts showing overall risk trends are useful for managers, but they belong further down or on a separate page.
- Sorted by what matters: risk multiplied by value, not risk alone
- Limited to a number someone can realistically work through
- Filtered to the person viewing it, so each team member sees their own cases
- Clearly marked when a case is new since yesterday
- Cleared once acted on, so the list shrinks as work is done
If a dashboard does not get shorter as people use it, it is a report pretending to be a tool.
Show the reason next to the score
A bare score of 0.82 is almost meaningless to the person acting on it, and it invites either blind trust or blanket dismissal. We show the two or three factors that pushed each prediction up or down, in plain words: “order frequency down sharply over eight weeks”, “two support complaints this month”.
Reasons do two jobs. They let people act sensibly, because the reason often suggests the right conversation. And they let people catch the model being wrong for a silly reason, which is the fastest way to find a data problem after launch.
We also avoid false precision. Scores are usually shown as bands such as high, medium and low, with the thresholds chosen against the cost of errors agreed before go-live, rather than as decimals that imply more certainty than the model has.
Capture what happened, in one click
The most valuable feature on a prediction dashboard is the smallest: a way for the user to record what they did and whether the prediction looked right. “Called, customer fine”. “Called, confirmed at risk”. “Wrong: account on a payment plan”.
That feedback becomes labelled data for the next retraining, reveals where the model is systematically wrong, and shows whether predictions are actually being acted on. Without it, nobody can tell the difference between a model that works and one that is ignored.
A separate view for model health
Users need confidence that the predictions are still reliable. Managers and whoever supports the system need to see when they are not. We keep a small model-health page alongside the working views.
- How many predictions were made, and whether that volume looks normal
- Whether incoming data has drifted from what the model was trained on
- Real accuracy on cases whose outcomes are now known
- How often users mark predictions as wrong, and why
- When the model was last retrained, and which version is live
When any of these crosses a threshold, the right people are alerted before the users lose trust. We cover the support side of this in how we support models after launch.
How we test a prediction dashboard before launch
During shadow mode we put a draft of the screen in front of the people who will use it, with real predictions that are not yet acted on. We watch what they click first, what they ignore and what they ask. A column nobody looks at is removed. A question asked twice becomes a field.
It is unglamorous work and it decides whether the model earns its keep. Dashboards and review screens are part of the machine learning builds we scope, priced alongside the model rather than bolted on afterwards.
Frequently asked questions
Do machine learning predictions need their own dashboard?
Can you add predictions to Power BI or our existing BI tool?
How do you explain predictions to non-technical users?
How do users correct the model when it is wrong?
Have predictions nobody looks at?
Show us the dashboard or report they live in today. We will tell you what we would change so the people who should act on them actually do.