Reporting nobody reads, and how to tell early

We added page logging to the reporting section of a platform we had built, originally to size a caching problem. The caching problem turned out not to matter. Over the following quarter a handful of the reports were opened almost daily by the same small group, and most of the rest had not been opened since the training session.

That says less about the reporting build than about how reports get specified. A requirements workshop rewards asking. Nobody is ever criticised for requesting a report they might one day want, and nobody in the room is holding the maintenance budget.

Each report is a permanent obligation. It is a query against a schema, so every schema change has to keep it working. It is a permission decision, so every change to the access model has to be applied to it. On a platform with row-level access, where a regional manager sees only their own territory, each report is another surface where that rule can leak. Forty reports do not carry forty times the value of one, and they carry close to forty times the maintenance.

Instrument the dashboards we ship

The instrumentation is trivial: log opens, filters applied, exports taken, and who did each. Do it from the first release, and tell the client it is there, because it is their data and their staff. Reporting on the reporting sounds like a joke until the first support review, when it becomes the only evidence in the room.

Usage tracks one thing more than any other: whether the output feeds a decision that a named person is accountable for on a schedule. Reports attached to a weekly operational meeting survive for years. Reports built to answer a question somebody was curious about in March are dead by April.

The access log also says what kind of report was actually built. Opened and immediately exported means the real analysis tool is a spreadsheet and the report is a query with a login page in front of it, so give those people an extract or an API and stop maintaining the page. Opened, filtered repeatedly, then closed without an export means somebody is genuinely working inside it, and that is where further investment goes. Never opened after the second week means it exists to satisfy a line in a document.

Cutting reports is a service, and an awkward one

Proposing that reports be deleted is uncomfortable when we billed for building them. We do it anyway, at the first support review after launch. The proposal is specific: these six have not been opened in a quarter, we will take them off the menu, keep the definitions in the repository, and stop testing them. If anyone objects, they come back the same week.

Almost nobody objects. When someone does, it is usually for a report they run once a year, which is worth knowing on its own, because an annual report is exactly the kind of thing that quietly breaks in a schema change and gets discovered at the worst possible moment.

The gain has nothing to do with compute cost, which is negligible. It shows up in the next schema change, which is cheaper because there are fewer queries to keep working, and in the credibility of what remains. A short menu where every report is current is worth more than a long one where half the entries are suspect and nobody knows which half.

The service desk we built for Tata Realty carries department-level analytics for resolution time and backlog. Those numbers get looked at because somebody is answerable for an SLA clock attached to them. That is the whole test, and it can be applied in the design workshop rather than a year later. A dashboard nobody opens is a maintenance obligation with a login page.