Getting the Numbers Out
Last updated:
Define the numbers before building
Automating a report requires stating exactly what each figure means: which date it is counted on, how cancellations are treated, what is included and excluded.
Two reports disagreeing because they define revenue differently is the fastest way for a business to stop trusting its own reporting.
Do not report from the operational tables
- Heavy aggregations slow the application for everyone
- Use a read replica, or nightly aggregate tables
- Pre-compute anything expensive that changes infrequently
- Paginate or stream anything large
Deliver rather than display
- Scheduled email with the key figures, before people need them
- Alerts when something is outside its normal range
- The detailed view available for anyone who wants to dig in
- Everything exportable, because people will want it in a spreadsheet
A dashboard people must remember to open is opened in the first week and rarely afterwards. A short email arrives and gets read.
Make them reproducible
| Requirement | Why |
|---|---|
| Same inputs give the same output | Trust |
| Explicit date range | Comparability |
| Definition documented alongside | Nobody guesses |
| Historical periods regenerable | Auditability |
| Exportable | People want the data |
Respect permissions in reports
A report that ignores the permission filter leaks everything the interface carefully restricted. Exports are the most commonly forgotten path.
Apply the same filtering to reports and exports as to screens, enforced centrally rather than remembered.
Frequently asked questions
Should we use a BI tool?
How do we stop reports slowing the app?
Who defines the metrics?
How many reports?
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