Use the standard reports for 90 days before building new ones
· 2 min read
Why a new knowledge base should run on its standard reports for 90 days, and how to decide at day 90 which new reports are worth building.
In brief
When a new knowledge base goes live, requests for custom reports arrive almost immediately, and within months many organisations have dozens of reports that are rarely run and sometimes contradict each other. This article argues for a simple discipline: use the standard reports that come with the platform for the first 90 days before building anything new. In the early weeks nobody yet knows what normal usage looks like, so reports designed then are designed around guesses. The standard reports cover what most knowledge bases need to know, including searches, reads, helpfulness ratings and overdue reviews, and living with them shows which questions really matter. Waiting also spares the team the cost of owning and maintaining reports nobody needs. The article sets out what to do during the 90 days, such as logging every unanswered question and noting which reports nobody opens, and gives three questions to decide at day 90 which new reports are genuinely worth building.
A new knowledge base goes live on a Monday. By Wednesday, someone has asked for a custom report.
It is an understandable request. People want to see whether the investment is working, and the reports that come with the platform rarely look exactly like the picture in their head. So a report gets built. Then another. Within a few months there are thirty, most of them run once, several of them disagreeing with each other about the same number.
There is a better order of things. Use the standard reports for the first 90 days, and only then decide what is missing.
Why wait?
In the first weeks after go live, you do not yet know what normal looks like. Usage is lumpy. People are curious, then distracted, then they settle into habits. A report designed in week one is designed around a guess.
The standard reports are dull, but they are honest. They measure the things almost every knowledge base needs to know: what is being searched, what is being read, what is rated helpful or not, and what is overdue for review. Living with them for a while teaches you which of those questions actually matter in your organisation.
Waiting also protects the team. Every custom report needs an owner, needs maintaining when the data changes, and needs someone to explain it when the numbers look odd. Building them before you know you need them is taking on that work early, for no clear return.
What to do in the 90 days
- Pick a small set of standard reports and look at them on a regular rhythm, perhaps fortnightly.
- Write down every question the reports cannot answer, along with who asked it and why.
- Note which reports nobody opens. That is useful information too.
- Agree who decides when a new report is justified.
At day 90, ask three questions
- Which unanswered questions came up more than once, from people who would act on the answer?
- Can any of them be answered by filtering or combining a standard report, rather than building a new one?
- For each report you do build, who owns it and when will you check whether anyone still uses it?
Most teams find that the list of genuinely missing reports is much shorter than the list of reports they would have built in week one.
Reporting is meant to help people make decisions. The best way to find out which decisions matter is to watch them being made for a while first.
Next step: Share how your team decides which reports to build in the Knowledge and self-service conversation on ESM's Exchange: https://exchange.esm.institute
Tags: knowledge management, service management, reporting, ESM
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
How do I compare help desk tool pricing before rolling it out across several departments?
4 min read
Turning 'not helpful' into a fix
1 min read
When the author leaves, who owns the article?
2 min read
Test after every change, or find out from users
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.
Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
How do I compare help desk tool pricing before rolling it out across several departments?
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
When the author leaves, who owns the article?
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.