Getting the Numbers Out of the System
Last updated:
Most reports go unread
Businesses build comprehensive reporting and then look at it twice. The reports that get used are the ones that arrive automatically, answer one question, and require no interpretation.
A four-line email at 7am saying what happened yesterday gets read every day. A dashboard with forty charts gets opened in the first week and then never again.
Push, do not pull
- Scheduled email with the key numbers, before people need them
- Alerts when something is outside its normal range
- A weekly summary with the trend, not just the number
- The detailed view available for anyone who wants to dig in
Do not report from the live database
Heavy reporting queries against an operational database slow the application for everyone. A read replica or a nightly copy removes that risk entirely.
It also lets you build reporting tables shaped for querying rather than for transactions, which makes reports faster and simpler to write.
Define the numbers precisely
- Agree what each metric means, in writing
- Agree which date it is counted on — ordered, dispatched, invoiced, paid
- Decide how cancellations and refunds are treated
- Document it alongside the report itself
Two reports disagreeing because they define revenue differently is the most common reason a business stops trusting its reporting.
Make them reproducible
| Requirement | Why |
|---|---|
| Same inputs give the same output | Trust |
| The date range is explicit | Comparability |
| The definition is documented | Nobody has to guess |
| Historical reports can be regenerated | Auditability |
| Exportable | People will want it in a spreadsheet |
Frequently asked questions
Should we use a BI tool instead?
How do we stop reports slowing the system?
Who should define the metrics?
How many reports are enough?
Reports nobody opens?
They probably need to arrive rather than be fetched. Happy to look at what your business actually reads.
Related services
What we build for problems like this one