A report should come from the work, not Friday's spreadsheet

Name the action behind the report

Imagine a weekly sales meeting. The manager asks which orders have stalled before payment and who should intervene. A chart of total revenue cannot answer that question, even if it refreshes automatically. The team needs a definition of “stalled”, an acceptable time in that state and an owner for each exception.

Choose one recurring conversation and record the decision, the evidence it requires and when that evidence must be ready. This sets a boundary for the first release. If the decision happens on Monday, real-time data may be unnecessary. The team still needs to know the reporting period and the time of the last successful update.

Agree on what the numbers mean

Different systems may use the same word for different events. A CRM calls a signed proposal a deal, a website records a submitted order and accounting records a shipment. Adding their columns does not produce a meaningful sales count. Every metric needs a definition, an underlying event, a time period, a unit and a rule for cancellations or returns.

Write a short metric dictionary. An “order paid for” might mean a confirmed payment excluding full refunds, with partial refunds tracked separately. That is an example, not a universal accounting rule. The business must choose its own definition explicitly. Without it, automation merely repeats an old disagreement at greater speed.

Trace each figure to its source

Take one report line and work backwards: which field produced it, who entered that field, can the record change later and how will the reporting system notice? Joining data requires stable customer, order or project identifiers. A matching company name is unreliable when the same name is entered differently.

Check missing and duplicate records separately. If two channels create one enquiry, the report should not show two new customers. If a required status is absent, put the row on a review list instead of silently assigning a convenient category. People should be able to see data quality alongside the result.

Refresh is part of the product

A scheduled import does not guarantee fresh reporting. A source may be unavailable, a file structure may change or one operation may finish later than the others. Show the last successful refresh, an error state and a policy for displaying older figures. “No data” and “yesterday's data” lead to different decisions.

In common analytics tools, an imported model must be refreshed to include source changes, and refresh history helps reveal failures. The right frequency depends on the decision and the system. Agree on acceptable data age before choosing a schedule or event-driven update.

Reconcile decisions, not just charts

Run a pilot over one period and a small set of metrics. Compare the totals with source records, then inspect awkward cases: a refund, a duplicate, an order crossing reporting periods and a backdated edit. A manager should be able to open the records behind a number and understand a discrepancy.

Then ask whether the new report changed a decision and what happened sooner than it did with the manual process. If nothing changes, the wrong question may have been automated. A dashboard is the next layer: it displays agreed data rather than repairing its origins.

Release one dependable data route first

Start with one management question, two or three sources and a clear correction path. Name the owner of the metric, the owner of each source and the person who receives a failure alert. That route is a foundation for management reporting automation and a later dashboard. For an internal tool, I would design this route before drawing the screen, then make the interface follow the decisions it needs to support.

A dashboard for a decision

If you need a dashboard, we can first define the management question, data sources and the decision it should support.

Discuss a dashboard