Most organisations are drowning in data, yet starved of decisions.
You can measure almost anything now, and most teams do. The result is a wall of dashboards, each packed with charts, filters, and drill-downs, and almost none of it changes what anyone does on a Tuesday morning.
The data is there. The decision is buried in it.
Why most dashboards go unread
A dashboard is built to show everything, so it decides nothing. It hands the viewer twenty numbers and leaves them to work out which one matters, whether it is good or bad, and what to do about it. That is real cognitive work, and most people do not have a spare ten minutes to do it before their next meeting. So they glance, they get no clear signal, and they stop looking.
There are a few reasons this keeps happening:
- It shows the same thing to everyone. An operations lead, a field engineer and a finance director all get one view, so none of them gets theirs.
- It treats every number as equal. Nothing on the screen says “look at this first”. The urgent and the trivial sit side by side at the same size.
- It reports, it does not prompt. The dashboard waits for you to come and check it. The problems that matter rarely wait.
- It speaks in metrics, not in plain language. “Throughput down 4% week on week” is data. “Line 3 is slipping and will miss Friday unless someone reallocates” is an answer.
The build was not the problem. Plenty of these dashboards are technically excellent. The problem is that a chart describes the world, and a decision needs a recommendation about it. Closing that gap is a design and judgement job, not a data-engineering one.
The haystack of usable needles
The interesting shift with modern data tooling, AI included, is not that we can crunch more. It is that we can finally do the last mile: take a mass of information and turn it into a small number of specific, actionable things for a specific person.
Think of it as turning the haystack into a short list of needles, each one already picked out and handed to whoever needs it. That reframes the whole exercise. The value is not the model or the chart. It is the judgement of how you put the answer in front of the person who has to act, in language they use, at the moment it is useful.
Three things make that work.
Role-based delivery
Different people need different answers from the same underlying data. The engineer needs to know which asset to check next and why. The operations manager needs to know whether today’s plan still holds. The director needs to know whether the trend is drifting off target and whether it needs a decision this week.
Same data, three different needles. Design each view around the decision that person actually owns, not around the shape of the database. If a view does not map to a decision someone is accountable for, it is decoration.
Prioritised, not exhaustive
The most useful thing you can do with a mass of signals is rank them. Not “here are forty things that changed”, but “here are the three that matter, most important first, and here is why”. That ordering is the product. It is also where the hard thinking sits, because deciding what matters most for a given role is a genuine judgement call, and getting it wrong trains people to ignore the tool.
Plain language over raw metrics
A number tells you the state of the world. A sentence tells you what it means. “Sensor 12 has drifted outside tolerance twice today and is trending worse” carries the reading, the pattern and the implication in one line a busy person can act on. The metric is still there underneath for anyone who wants to dig, but the headline does the interpreting, so the reader doesn’t have to.
Proactive alerts beat passive reporting
The bigger change is moving from pull to push. A dashboard is passive: it sits there and relies on someone remembering to look, having time to look, and knowing what to look for. Most of the value in operational data is time-sensitive, and by the time someone goes and checks, the window to act has often closed.
Flip it. Instead of waiting to be read, the system watches the data and speaks up when something crosses a line that matters, to the person who can do something about it, through the channel they already live in. The default question stops being “what does the dashboard say today” and becomes “tell me when I need to pay attention, and stay quiet otherwise”.
The discipline is in the threshold. Alert on everything and you have rebuilt the noise problem in a louder form, and people mute it within a week. A good alerting layer is mostly an exercise in restraint: what warrants interrupting someone, and what can wait for the weekly view. That is a judgement about the business, made with the people who will receive the alerts, not a setting you toggle on.
Where a conversational or AI layer helps
This is where an AI or conversational interface earns its place, and where it is often just an expensive gloss on top.
It helps when:
- The questions are open-ended. People rarely know in advance every question they will want to ask. A conversational layer lets someone ask “why is line 3 behind” and follow up with “was it the same last month”, without a developer building a new report each time.
- The data is dense and technical, and the reader is not. Turning a stream of sensor or log data into a plain-language answer is exactly the last-mile translation that used to need an analyst sitting next to you.
- The answer needs context, not just a number. A good response can pull the reading, the recent trend and the likely cause into one explanation, which is far more useful than a figure on its own.
It is decoration when it is a chat box bolted onto the same old dashboard so the interface looks modern, when the answer to most questions is a single number a plain view would show faster, or when it produces confident-sounding answers with no way to check the working. A conversational layer is worth building when it removes real friction between a person and a decision. If it doesn’t, a clear, well-designed view will beat it every time and cost a fraction as much to run.
We worked on this exact problem on a consortium project in the rail industry. Trains and overhead lines are monitored continuously by very sophisticated equipment mounted to the train roof, with sensors watching things like the pantograph, the arm that draws power from the wire, and flagging anything unusual. The monitoring worked. What came next did not: a flood of readings that a busy engineer had to wade through to find the few that mattered. The people we interviewed described it as a haystack of usable needles, and the needles weren’t the same for everyone, because a controller, a maintenance engineer, and an investigator each needed something different from the same feed.
We were one partner on a large project, and our work package was the part those engineers would actually touch: designing and building the AI-driven interface that turns the feed into prioritised, plain-language answers, routed to the person who makes the decision. We built and demonstrated it as a working prototype.
The point
The organisations getting value from their data are not the ones with the most dashboards. They are the ones who worked out, for each person who has to act, what decision that person owns, what would change it, and how to put that in front of them clearly and at the right time.
That is a judgement job before it is a technology one. The tools have got good enough that the interesting question is no longer “can we measure it” but “have we handed the right person the needle”. Get that right, and the data starts earning its keep. Get it wrong, and you have built one more thing nobody reads.
If you are sitting on data that is not turning into decisions, we are happy to talk it through. Book a free 30-minute call, and we will look at where the answers are getting stuck.