From spreadsheets to decision dashboards

A decision dashboard is a single view of the handful of figures a manager needs in order to decide what to do this week, pulled automatically from the systems where the work happens. It is for owners and managers who currently assemble that picture by hand from spreadsheets, exports and messages, and who decide later than they would like because of it.

Key takeaways

• A dashboard answers decisions, not curiosity. Start from the decisions, then choose the figures.
• The data already exists in your shop, CRM, accounting and project tools. The work is connecting and defining it.
• Agree on definitions before drawing a chart. Most dashboard arguments are definition arguments.
• A daily briefing written by AI from the figures saves the reading, as long as a person checks it.
• Vanity metrics look good and change nothing. Remove them.
• Keep a spreadsheet where it is a real source; replace it where it is a manual copy.

What a decision dashboard answers

Most dashboards show everything that can be counted. A decision dashboard shows what you would act on. The difference is a short list of questions a manager asks every week:

• Are we going to reach this month's revenue, and what is in the pipeline to close the gap?
• Which orders or projects are late, and who is on them?
• Which customers have not paid, and how far over are they?
• Where did the inquiries come from this week, and how many did we answer within a day?
• What did we spend on, and is it within plan?

Each question maps to one or two figures and one view. If a figure does not change a decision, it does not belong on the first screen.

Step 1: Start from the decisions

Sit down with the people who make the decisions and list them: weekly, monthly, and when something goes wrong. For each decision, write the figure that informs it, the threshold at which action is needed, and who acts. This list is the specification. Everything else is design.

Step 2: Find where each figure lives

Trace each figure to its source: orders in the shop, deals in the CRM, invoices and payments in accounting, hours in the time-tracking tool, inquiries in the form backend and the inbox. Many sources already have an API or an export; some are spreadsheets kept by one person.

Make a distinction here. A spreadsheet that is the actual source of a figure (a price list, a manual stock count, a planning sheet) stays and becomes an input. A spreadsheet that is a copy of data living elsewhere is replaced by a connection to that system. The second kind is where most errors and most hours go.

Step 3: Agree on definitions

"Revenue" can mean orders placed, invoices issued or payments received. "Open leads" can include or exclude unanswered inquiries older than a month. "Late" needs a date to be late against. Before any chart, write a one-line definition for each figure, with its source and its rule, and have the people who will use the dashboard sign it off. This document is short and it prevents months of argument.

Agree on frequency as well. Some figures are meaningful daily (inquiries, orders), some weekly (pipeline), some monthly (margin). Showing a monthly figure daily invites reactions to noise.

Step 4: Build the data layer first

Behind the dashboard sits a small data layer: scheduled jobs that pull from each source, apply the definitions and store the results in one place with a date stamp. This can be a database or, for a small company, a well-structured set of tables in a tool the team already has. What matters is that each figure is computed once, by a documented rule, and that history is kept so that trends are real rather than reconstructed.

Charts come after this. A chart on top of an undefined figure is decoration.

Step 5: Add a daily briefing, with a person checking

Figures on a screen still have to be read. A step that has worked well for us is a short written briefing produced each morning from the figures: what changed since yesterday, what crossed a threshold, what needs a decision today. An AI model writes the first draft from the computed figures and the agreed thresholds. It does not compute anything itself and it does not see raw customer records, only the figures and their definitions.

Then a person reads it before it goes out to the team. In the first weeks this is a real review: the reader corrects wording, flags figures that are wrong because a source changed, and tightens the thresholds. Later it becomes a quick check. Keeping the person in the loop is what makes the briefing trustworthy enough that people act on it.

Step 6: Remove vanity metrics

Page views, follower counts, total sign-ups since launch, emails sent: these move upward and feel like progress, but none of them answers a decision. If a figure has no threshold and no owner who acts when it is crossed, take it off the dashboard. Keep it in a report if someone wants it for reference.

A useful test for each figure: what would we do differently if this were a fifth lower than it is? If the answer is nothing, it is not a decision figure.

Step 7: Operate it

Sources change. A column is renamed in the shop export, a CRM stage is added, an API token expires. The dashboard needs the same monitoring as any integration: a check that each source job ran, an alert when a figure is missing or jumps implausibly, and a monthly review of definitions with the people who use it. A dashboard nobody maintains becomes a dashboard nobody trusts within a quarter.

How we do it at Hot Skulls Labs

We treat a dashboard as an automation project, not a design project. Discovery starts with the decisions: we sit with the owner or the operations lead, list the weekly and monthly decisions, and write the figure, threshold and owner for each. We then trace every figure to its source system and classify the spreadsheets in use as either sources to keep or copies to replace.

The definitions document is written and signed off before we draw anything. Then we build the data layer: scheduled pulls from each system through its API or export, the definitions applied in code, history kept with a date stamp. The dashboard is a view on top of that layer, and the figures on the first screen are the ones from the decisions list.

The daily briefing follows our standard pattern: a trigger (the morning schedule), an AI step (a draft written from the computed figures and thresholds), a human check (a named person reads and releases it), and execution (it is sent to the team). We run this pattern in Strady, our own AI operations product, where an assistant briefs the owner from the pipeline and approvals data. The way we structure definitions and the review step comes from running it there.

We host in the EU, keep the data layer under the client's accounts, and review the definitions and the exceptions with the client as part of operation.