MELLORCATalk to Mellorca
Insights›Systems & Strategy
Article

Why more dashboards do not automatically create better decisions

A dashboard is useful only when the information is trustworthy, relevant to a decision, and connected to clear ownership and action.

Mellorca Insights·Systems & Strategy·6 September 2026

Businesses often respond to poor visibility by creating another dashboard. A new report is commissioned, a business intelligence licence is bought, or each team builds its own view of performance. Information becomes easier to display, but not necessarily easier to interpret or act on. Within a year or two, many organisations have dozens of dashboards, several versions of the same metric and a management meeting that still opens with the same question: which number is right?

The problem is rarely the charting tool. A dashboard sits at the end of a chain that starts with how work is recorded, how terms are defined and who is expected to respond when something changes. If that chain is weak, adding more screens multiplies the weakness rather than fixing it.

Why dashboard count grows without decisions improving

Dashboards are cheap to create and awkward to retire. Each new question tends to produce a new view, and few views are ever switched off. Several mechanisms then compound:

  • Questions without owners. A chart is built because someone asked once. Nobody is accountable for responding to what it shows, so it becomes background information.
  • Metrics without definitions. Two teams each calculate “active customers” or “backlog” in good faith, using different filters, date rules or source systems. Both dashboards are accurate to their own logic, and they disagree.
  • Summaries without signals. Monthly totals and traffic-light ratings describe outcomes after the fact. They rarely show the queue building up, the exceptions accumulating or the handoff that is slowing down.
  • Burden shifted to the reader. Every additional view asks a manager to work out what matters. The UK Government Analysis Function’s guidance on building and managing dashboards warns that dashboards can put the burden of understanding data onto users and can overwhelm them, and it recommends asking what decisions users will make before building one.

The result is a reporting estate that looks mature but does not change how the business responds.

Start with the decision, not the chart

Every important metric should answer a decision question: what is happening, why does it matter, who owns the response, and what threshold changes the action? If a number moves and nobody would do anything differently, it may be useful context, but it is not decision support.

A practical test is to write the decision before designing the chart. An illustrative example: “If more than ten onboarding cases have been waiting for client documents for longer than five working days, the onboarding lead reallocates chasing capacity and the account manager contacts the client.” That one sentence names a measure, a threshold, an owner and an action. The chart is then straightforward to design, because its job is already known.

Shared definitions matter

If teams calculate revenue, backlog, service level or conversion differently, visual polish does not create trust. Resolve data ownership and definitions upstream before multiplying reporting layers. In practice that means agreeing, for each measure that informs a decision:

  • which system is the source;
  • the precise rule: what counts, from which date, and what is excluded;
  • who may change the definition;
  • how changes are communicated to everyone who relies on the figure.

Consider an illustrative services firm where finance reports recognised revenue and sales reports signed contract value, and both are labelled “revenue”. Neither is wrong. But a board pack that places them side by side without explanation will produce argument rather than decisions. Renaming and documenting the two measures often resolves more than a new visualisation would. For the upstream causes, see why your reports cannot agree on the same number and how to decide which system owns which data.

Leading signals are often more useful than summaries

Completed outcomes matter, but operating decisions improve when leaders can also see queues, delays, exceptions and deteriorating conditions before the final result is affected. For most service operations, useful leading signals include work waiting at each stage and for how long, items returned for rework, exceptions resolved outside the main system, and the age of the oldest open item.

How a signal is read matters as much as which signal is chosen. NHS England’s Making Data Count guidance describes two-point comparisons and red-amber-green reports as limited ways of looking at data, and promotes statistical process control, which plots data over time and separates ordinary variation from unusual patterns that may need action. The Healthcare Financial Management Association makes a similar case in its article on the programme: looking at data over time helps teams recognise when something unusual merits investigation, rather than reacting to every movement.

The lesson for a business is not that every dashboard needs control charts. It is that a single month-on-month change, coloured red, is a weak basis for action, and a green rating can hide a trend that is already moving the wrong way.

Warning signs

  • Meetings spend more time reconciling numbers than deciding what to do.
  • Teams export dashboard data into spreadsheets to “correct” it before using it.
  • Nobody can say who would act if a given metric deteriorated.
  • Several dashboards answer nearly the same question in slightly different ways.
  • Red ratings trigger investigations that usually conclude nothing has changed.
  • Important problems are reported by customers before they appear in management reporting.

A practical diagnostic

  1. Inventory. List existing dashboards and reports with their audience, owner and last meaningful use. Usage logs help, but asking “what did you decide with this last month?” is usually more revealing.
  2. Map decisions. For each recurring management meeting, write down the decisions it actually makes. Match each decision to the measures that inform it.
  3. Define. For every measure that supports a decision, record one definition, one source system and one owner. Where two definitions are both legitimate, give them different names.
  4. Add operating signals. For each outcome measure, identify one or two upstream signals, such as queue size, waiting time or rework rate, that would warn of deterioration earlier.
  5. Set response rules. Agree thresholds and who acts. Prefer trends over time to single comparisons.
  6. Retire. Archive views that support no decision. The Analysis Function guidance treats retirement as a normal part of a dashboard’s life once it is no longer useful or relevant.

Trade-offs

Fewer dashboards are not automatically better. Some exploratory reporting is valuable precisely because nobody yet knows which question matters, and analysts need room to investigate. Agreeing definitions takes time and can surface disagreements between teams that were previously hidden. Response rules can become rigid if nobody reviews them. The aim is a deliberate split: a small, governed set of decision measures, and a clearly labelled exploratory space that is not mistaken for management truth.

There is also an upstream dependency. If work is not recorded with clear states and timestamps, no dashboard can show where it is waiting. In those cases the reporting fix is really a workflow or system fix, which is the subject of what management cannot see usually becomes expensive.

What better looks like

A smaller set of trusted indicators is tied to explicit decisions, owners and response rules. Definitions are written down and owned. Outcome measures sit alongside a few leading signals that show where work is accumulating. Trends are read over time rather than through isolated comparisons, and dashboards that no longer support a decision are retired. Reporting becomes part of operations rather than a separate presentation exercise.

When reporting debates keep recurring despite investment in tools, the cause usually sits upstream in definitions, data ownership or workflow design. A Digital Systems Audit can trace those causes, and Digital Operations Improvement can redesign the measures and workflows that feed management reporting.

Sources and further reading

Related Mellorca reading

Explore MellorcaExplore our solutions or start a conversation.