What Belongs on a Business Dashboard?

Plenty of dashboards get built; far fewer get opened twice. The failures usually trace back to the same planning gaps — nobody decided what the dashboard was for, nobody agreed on what the numbers meant, and nobody was on the hook to act on them. This guide walks through the questions that separate a dashboard your team relies on from one that quietly dies, ending with a checklist you can plan against.

Start with the decision, not the data

The instinct when planning a dashboard is to ask "what data do we have?" That's backwards, and it's the root of most dead dashboards. Start instead with: what decisions do we make regularly, and what would we need to see to make them faster or better?

Say a hypothetical HVAC company decides every Friday how to staff next week's crews. The decision needs: booked jobs by day, open estimates likely to close, and current crew availability. That's the dashboard — three things tied to a real weekly decision. Compare that with a screen showing every number the company's systems can produce, tied to nothing. The Friday-decision screen gets opened every Friday. The everything screen gets opened at the demo.

A useful planning trick: for every number you're tempted to include, finish the sentence "if this number looks bad, we will ___." If nobody can finish it, the number doesn't earn a spot.

Who is it for?

"The company dashboard" is usually a mistake, because different people make different decisions:

• The owner needs the health of the whole: cash position, revenue against plan, jobs in the pipeline, anything on fire. A dozen numbers, glanceable in two minutes.
• Operations needs today: which jobs are running, which are stuck, who's where, what's due. More detail, narrower window, refreshed more often.
• Sales needs the funnel: new leads, follow-ups due, quotes outstanding, what closed. Ideally organized as "what do I act on next?"

That usually means separate screens (or views) per audience rather than one screen for everyone. One screen for all three audiences serves none of them — the owner drowns in job-level detail while ops hunts for today's schedule between revenue charts.

Choosing KPIs

Three rules cover most of it:

Few. A dashboard with eight numbers gets read; one with forty gets skimmed, then ignored. If everything is highlighted, nothing is. Cutting a metric is not losing information — the data still exists one click deeper — it's choosing what deserves attention by default.

Defined in writing. Every metric needs a written definition: "revenue" — invoiced or collected? "jobs completed" — when the crew finishes or when the customer signs off? Undefined metrics generate meetings about what the dashboard means instead of decisions based on what it says.

Tied to actions. Each KPI should have an owner and an implied response. If close rate drops below the line you've set, someone specific looks into it. A number nobody owns is decoration.

It also helps to mix leading and lagging indicators. Lagging indicators (last month's revenue) tell you how it went; you can't change them. Leading indicators (quotes sent this week, first-response time on leads) tell you how next month is shaping up while there's still time to act. Most dashboards over-serve lagging numbers because they're easiest to pull. The leading ones are where the steering is.

Data sources & data quality

A dashboard is only as honest as what feeds it. Two things to settle before building:

Where each number comes from. Inventory the sources — accounting software, CRM, job tracker, spreadsheets — and flag any metric that requires manual entry to stay current. Manually fed dashboards decay fast: the person updating the spreadsheet goes on vacation, and the screen starts lying politely. Prefer numbers that flow in automatically; if a metric can't, decide who updates it and how often, out loud.

What the words mean. Agree on definitions like "what counts as a lead." Every form fill? Only prospects with a phone number? Does a returning customer count? If sales and marketing count leads differently, the dashboard will pick one definition silently, and whoever loses the silent argument will stop trusting the screen. Have the argument once, in a meeting, and write down the winner.

Refresh frequency

Real-time dashboards sound appealing and are occasionally worth it — a dispatch board, a live order queue. But real-time costs more to build, more to run, and more to keep reliable, because every feeding system has to stream rather than sync.

Here's the more useful question: how often does the decision get made? If you review numbers each morning, data refreshed nightly is exactly as useful as data refreshed every second — and considerably cheaper. Most business decisions are daily or weekly, which is why most businesses genuinely need daily refresh, not real-time. Spend the savings on better data quality; freshness never rescues a wrong number.

Permissions

Not everyone should see everything. Payroll and margin data usually stay with owners; a technician needs their schedule, not the company's cash position. Decide per audience what's visible, and prefer role-based screens over one screen where everyone sees all of it. This is also a security matter: a dashboard aggregates your most sensitive numbers in one convenient place, so it deserves real logins, per-person accounts you can revoke, and the same access discipline you'd apply to your accounting system — the kind of thinking covered in our security reviews. "Everyone shares one password" is how convenient dashboards become expensive stories.

Mobile & wall-screen use

Where a dashboard is read should shape how it's built. An owner checking numbers from a job site needs a phone layout that puts the vital few on top — not a desktop screen pinched and zoomed. A wall screen in the shop is the opposite: readable from twenty feet, no interaction, big type, few items, and it needs to refresh itself, because nobody walks over to click a wall.

Wall screens carry a social effect worth thinking through: a visible metric becomes a public scoreboard. Jobs-completed-this-week can rally a shop floor; a metric a crew can't influence, displayed where they eat lunch, mostly breeds resentment. Post numbers people can move.

Alerts

A dashboard you must remember to check will eventually go unchecked — usually the week something goes wrong. Alerts close that gap: define thresholds that page a human when crossed. Cash below the line you've set, no leads recorded in 24 hours (often a broken form, not a slow day), a job past due, a queue past a limit — pick the conditions that would make you act, and have them come to you by text or email instead of waiting to be noticed.

The discipline is restraint. Alert only on conditions that demand action, and tune noisy ones immediately. An alert that cries wolf trains everyone to swipe it away, and then the one that matters gets swiped with it. A good test: if this alert fired right now, would someone do something within the hour? If not, it's a report, not an alert.

Exporting & scheduled reports

Dashboards answer "how are we doing right now?" Reports answer "what happened last month?" — for the banker, the accountant, the partner meeting. You'll want both: on-demand export to a spreadsheet or PDF for whenever someone asks, and scheduled reports (say, a Monday-morning summary emailed to owners) for the rhythm your business already runs on.

Scheduled reports have a quiet superpower: they arrive without being asked for. A dashboard requires the habit of opening it; a Monday email builds the habit for you. For some owners, the emailed summary ends up being the dashboard, and that's a perfectly good outcome.

Common dashboard mistakes

• Vanity metrics. Numbers that only go up — total customers ever, lifetime revenue, social followers. They feel great and inform no decisions. If it can't go down, it can't warn you.
• The 40-widget screen. Usually the fossil of a committee, where every request got granted and nothing got cut. Attention is the scarcest resource a dashboard spends; a screen that spends it on everything buys nothing.
• Undefined metrics. Covered above, and worth repeating because it's the most common trust-killer: the first time two people discover they read the same number differently, the dashboard stops being the referee.
• Dashboards nobody opens. The end state of all the above. The fixes are structural, not cosmetic: tie screens to recurring decisions, give metrics owners, and add scheduled reports and alerts so the numbers reach people even when nobody visits.

A dashboard-planning checklist

Work through this before anyone builds anything — whether that's us, another developer, or a BI tool you configure yourself:

• We've listed the recurring decisions this dashboard supports, and who makes each one.
• Each audience (owner, ops, sales) has its own screen or view.
• Every metric passes the "if this looks bad, we will ___" test.
• Every metric has a one-line written definition, agreed by the people who'll argue about it.
• Every metric has an owner.
• We know each number's source system, and which metrics depend on manual updates.
• We've chosen a refresh frequency per screen based on how often the decision is made — not "real-time by default."
• We've decided who can see what, with individual logins.
• Alert thresholds exist for the handful of conditions that demand same-day action.
• Scheduled reports cover the recurring meetings and stakeholders that need them.

If you can check all ten, you've done the hard part — the build itself is the straightforward bit. That planning conversation is exactly where our dashboard development work starts, and when a dashboard grows into something bigger — a system that runs the process instead of just reporting on it — it becomes a custom software conversation. Either way, the checklist above is the same one we'd walk you through first.