When businesses describe the software they want, reports often take up half the list: sales by region, jobs by technician, stock by location, overdue invoices, production by shift, and dozens more. After launch, a familiar pattern appears: a few reports are used every day, many are opened once and forgotten, and someone still exports data to Excel to build the report they actually needed. Designing reports well is less about the number of reports and more about understanding what people need to see, decide and do.
Start with decisions and actions
For every requested report, ask three questions:
- Who uses it? A specific role, not "management".
- How often? Every hour, every morning, every month-end.
- What do they do after reading it? Assign jobs, chase payments, reorder stock, call a customer, change a plan.
If nobody can answer the third question, the report probably is not needed. If the answer is "call the customers on this list", the report should be an actionable list with phone numbers and a way to record the outcome — not a summary chart.
Three kinds of reports
Operational lists
These help people do today's work: jobs due today by technician, orders ready to dispatch, items below reorder level, invoices overdue by more than 30 days, AMC visits due this week. They are filtered lists with actions attached. They should be fast, current and usually built directly into the relevant screens.
Management summaries
These help managers understand performance and trends: sales by month and region, first-time fix rate by technician, on-time delivery by customer, scrap by machine. They are typically aggregated, compared with targets or previous periods, and reviewed daily, weekly or monthly.
Documents and statutory outputs
Invoices, statements, certificates, registers and compliance reports with fixed formats. These are usually generated from templates and must be exact.
Treating these differently leads to better design: operational lists inside workflows, summaries on dashboards and in scheduled reports, documents through templates.
Define every measure precisely
"Sales" can mean orders booked, invoices raised or payments received, with or without tax, before or after returns. "On-time" can mean shipped by the promised date, delivered by it, or within a tolerance. Different definitions in different reports are the main reason managers stop trusting numbers. For each important measure, write a definition: what is counted, from which date, with which exclusions. Calculate it in one place in the software and use that calculation everywhere.
Filters, grouping and drill-down
A small number of well-designed reports with good filters replace dozens of rigid ones. Useful patterns:
- Common filters — date range, branch, customer, product group, team, status.
- Grouping — by day, week, month; by region, technician, product.
- Saved views — users save their usual filter combinations.
- Drill-down — click a total to see the records behind it, and click a record to open it. Drill-down builds trust because users can verify numbers.
Exports and scheduled delivery
People will always want to analyse some data in spreadsheets. Provide clean exports with consistent column names and formats, respecting the user's permissions. For recurring needs, scheduled reports — a daily summary emailed at 8 am, a weekly overdue list to each branch manager, a monthly performance pack — deliver information to people without them having to remember to look. Make sure scheduled reports are easy to subscribe to and unsubscribe from, so they do not become ignored email clutter.
Dashboards: a few numbers, well chosen
A dashboard should answer "is anything wrong, and where?" at a glance. Choose a handful of measures per role, show them against targets or previous periods, highlight exceptions with colour or alerts, and link each figure to the detailed list behind it. A dashboard with thirty charts is a report nobody reads.
Performance with growing data
Reports that are instant at launch can become slow after two years of transactions. Plan for it:
- Database indexes for common filters and joins.
- Summary tables updated periodically for heavy aggregations.
- Background generation for large reports, with a notification when ready.
- Limits on very large date ranges, or pagination for long lists.
- Archiving or separating old data that is rarely needed.
- A separate reporting database or read replica for heavy analysis, so reports do not slow down daily operations.
Report permissions
Reports often expose more data than screens. A branch manager should see their branch's sales, not the company's; a salesperson may see their customers but not margins; exports of customer lists may be restricted. Apply the same access rules to reports and exports as to the rest of the system, and log exports of sensitive data.
In-app reports or a BI tool?
Business intelligence (BI) tools are powerful for exploring data and combining sources. They complement, rather than replace, reports built into the application:
| Need | Best place |
|---|---|
| Daily operational lists with actions | Inside the application |
| Role dashboards for routine monitoring | Inside the application |
| Fixed documents and statutory reports | Inside the application (templates) |
| Cross-system analysis | BI tool or data warehouse |
| Ad-hoc exploration by analysts | BI tool |
If you plan to use a BI tool, design the application's data so it can be exported or accessed cleanly, with clear definitions.
Avoiding the hundred-report trap
When replacing an old system, there is a temptation to recreate every existing report. Many of them exist because the old system lacked filters, or because someone once asked for a one-off view that became permanent. Instead:
- List existing reports and find out which are actually used, by whom and for what decision.
- Merge similar reports into a few flexible ones with filters.
- Move action lists into the relevant screens.
- Launch with the essential set; collect requests after launch.
- Review usage periodically and retire reports nobody opens.
Example
A distributor asked for 85 reports to be rebuilt from its old system. Discovery showed that fewer than twenty were used regularly, and many differed only by filters. The new system launched with twelve flexible reports with saved views, six operational lists built into screens (orders to dispatch, credit holds, items to reorder, overdue invoices, pending returns, quotes awaiting follow-up), three role dashboards and four scheduled email summaries. Six months later, only seven additional reports had been requested — and usage data showed the operational lists were opened hundreds of times a day.
Summary
Good reporting starts with the decisions and actions people need to take. Separate operational lists, management summaries and documents; define measures precisely and calculate them once; use filters, saved views and drill-down instead of many rigid reports; deliver routine information by schedule; design for performance and permissions; and resist recreating every old report. Fewer, better reports get used — and trusted.
Alerts instead of reports
Many reports exist only so someone can spot an exception: a job overdue against its SLA, stock below minimum, a customer over their credit limit, a machine idle for too long, a quotation not followed up within a week. In those cases, an alert is often better than a report. The system watches for the condition and notifies the right person — in the app, by email or by message — with a link to the record. Nobody has to remember to run anything, and attention goes only where it is needed. Keep alerts few and meaningful; too many alerts are ignored just like too many reports.
Reports on phones and tablets
Managers increasingly check numbers on their phones, and supervisors on the shop floor use tablets. Wide tables with fifteen columns do not work on small screens. For mobile users, design compact summaries — a few key figures with comparison to target — and lists with the two or three most important fields, with the option to open a record for details. Test reports on the actual devices people use, in portrait orientation, before launch.
Small design details that build trust
- Show the date range, filters and time of generation on every report, so printed or shared copies can be understood later.
- Use consistent number formats, currencies and units, and label them clearly.
- Show totals and counts, and make sure totals match the rows displayed.
- Sort by what matters most — usually the biggest problem first, not alphabetically.
- Use colour sparingly, for exceptions, and never as the only way to convey meaning.
- Explain any calculated figure with a short tooltip or footnote using the agreed definition.
Testing report accuracy
Before launch, test reports against known figures. Run them for a period where totals are already known — last month's sales from the accounts, last quarter's job counts from the old system — and reconcile differences until each one is explained. Include edge cases: cancelled orders, returns, partial deliveries, jobs reopened after closure, records changed after the period ended. Reports that are verified this way at launch are trusted for years; reports that are wrong in the first month are doubted long after they are fixed.
Frequently asked questions
How many reports should a new system have?
Fewer than most people expect at launch — the reports needed to run daily operations and the handful managers use for decisions. Add more based on real requests after launch, rather than copying every old report.
Should we build reports in the application or use a BI tool?
Operational reports that people use to do their work belong in the application. Cross-system analysis and ad-hoc exploration can suit a BI tool connected to the application's data. Many businesses use both.
Why are reports slow in some systems?
Usually because they calculate over large volumes of live transaction data every time they open. Indexes, summary tables, background generation and archiving solve most performance problems.
Can users create their own reports?
Flexible filters, saved views and exports cover most needs. A full report builder is complex to build and use; it is worth it only when many users genuinely need to design their own reports.
How do we make sure report numbers are trusted?
Define each measure precisely, use one calculation everywhere, show the filters applied, reconcile key figures with finance and let users drill down to the underlying records.
