Internal Dashboards People Actually Use

Nearly every business we work with has a dashboard nobody opens. It was built because someone asked for visibility, it shows fourteen charts, and the team went back to the spreadsheet they trust. The failure is not technical. The screen was never designed to answer a question anybody actually has on a Monday morning.

Start from the decision, not the data

Ask what the person will do differently depending on what they see. If there is no answer, the chart is decoration. A dispatcher wants to know which orders are late right now. An owner wants to know whether this month beats last month and where the gap is. An accountant wants to know what has not been reconciled. Those are three different screens for three different people, and merging them produces a page that serves none of them.

• Name the person and the moment they open it.
• Write the one question the screen answers, in a sentence, and put that sentence at the top.
• Every number should imply an action, or be removed.
• If two audiences need different questions answered, build two screens.
• A number nobody has ever acted on is a candidate for deletion, however interesting it is.

Define each metric once, in one place

The fastest way to kill a dashboard is to have two screens disagree about revenue. It happens because one query excludes cancelled orders and the other does not, and nobody wrote either rule down. Keep the definitions in one place, as shared views or a documented query layer, and have every screen read from that rather than from freshly written SQL. Then put the definition in the interface: a small note saying "orders marked paid, excluding refunds, by order date" ends more arguments than any chart.

Agree the edge cases explicitly before you build. Does a customer who bought once two years ago count as active? Is revenue booked when the invoice is raised or when the money arrives? Does a partial refund reduce this month or the original month? These are business decisions, not engineering ones, and leaving them implicit guarantees a disagreement at the worst possible moment.

Comparison is what makes a number mean anything

A figure on its own tells you nothing. Revenue of four hundred thousand is good or bad only against last month, the same month last year, or a target. Show the comparison beside the number, and show the direction of travel over enough periods that a reader sees a trend rather than a wobble. This single habit does more for comprehension than any chart library choice. The rest is ordinary interface design: hierarchy, restraint, and one thing on the screen that is obviously the most important.

In Nepal the year-on-year comparison needs care, because the festival calendar moves against the Gregorian one. Comparing this Kartik to last October will mislead anyone selling to consumers. Decide which calendar the business actually runs on and label the comparison so nobody has to guess.

If a number on your dashboard cannot be wrong, it is not measuring anything worth watching.

Be honest about freshness and gaps

Put the last-updated time on the screen, in words a non-technical reader understands. When data is missing or a sync failed, say so on the chart instead of drawing a line through the gap, because a silently wrong dashboard destroys trust permanently and nobody tells you it has happened. They just stop opening it. Alert on the pipeline itself, not only on the business numbers: a job that failed at two in the morning should reach a person before the nine o'clock meeting does.

• A visible last-updated timestamp, in plain language.
• An explicit gap or a banner when a source is stale, never an interpolated line.
• An alert when the load job fails, going to a person rather than a log.
• A note when a definition changes, so a step in the chart is explained rather than investigated.

Make it fast and reachable

A dashboard that takes twelve seconds to load will be checked weekly at best. Pre-aggregate the expensive numbers on a schedule rather than computing them per view, cache aggressively, and accept a figure that is fifteen minutes old if that is what keeps the page instant. Make it work on a phone, because the person who most needs it is often not at a desk, and in practice they are on mobile data with a mid-range Android device.

• Pre-compute totals on a schedule; do not aggregate on every page view.
• Default to the period people care about, usually today and this month.
• Let a number be clicked through to the underlying rows, because the first question is always "which ones?".
• Design the phone layout first; that is where it gets checked.
• Add a CSV export. People will take the data to a spreadsheet anyway, and fighting that is a losing position.

Push the important numbers, do not wait to be visited

The most-used dashboards we have built are the ones that also send a message. A short daily summary at eight in the morning to a Viber group or an email thread, with three numbers and a link, gets read by people who would never open a web app. The dashboard then becomes the place you go when the summary looks wrong, which is exactly the right division of labour. Keep the message short enough to read on a lock screen and it will survive; make it a wall of text and it becomes another ignored notification. Scheduling and delivering that digest is a small piece of automation work, and it usually returns more than the dashboard it summarises.

Decide who sees what before you launch

Internal dashboards accumulate sensitive data quickly: salaries, margins, individual staff performance, customer contact details. Work out the access rules before the first login exists, because retrofitting them means rebuilding queries. Be especially careful with anything that ranks named employees, since a leaderboard changes behaviour in ways that are rarely the ones intended, and it usually optimises the number rather than the work.

Buy the boring version first

An off-the-shelf business intelligence tool pointed at a read replica gets you to a working answer in a day, and it is the right first move for most teams. Build something custom when the workflow matters more than the chart, meaning people need to act on the screen: mark an order dispatched, assign a case, approve a payment. That is a product, not a report, and it is where a custom internal tool earns its cost. We build both, as data and analytics work or as custom software depending on which side of that line the requirement falls.

Ship one screen and watch

Build the single most useful view, put it in front of the team, and look at whether it is still being opened after the first fortnight. Usage tells you more than any requirements meeting, and it is the only honest measure of whether you designed the right question. Add the second screen only once the first has earned its place, and delete anything that has not been looked at in a month. A dashboard showing four things people rely on beats one showing forty they ignore, and the deletions are what keep it that way.