The questions your service desk keeps asking, and nobody answers
Every service desk has a handful of questions that come back every week and get answered from memory, differently, by whoever picks them up. Those repeats are demand-driven evidence of a knowledge gap: somebody needed to know something and the organisation could not tell them. You can count them this week with the export you already have, and the count is usually higher than anyone expects.
The pattern everybody recognises
Pull the last month of tickets from your service desk and read the ones that were resolved without a link to any document. You will find a small set of questions that keep coming back: when an exception is allowed, which of two policies applies, what to do when a supplier misses the window, whether a case needs a second signature.
Each one gets answered. Usually quickly, usually correctly, usually by the same two or three people, and usually from memory. Nothing is written down afterwards, because the ticket is closed and the queue is long.
Why the wiki does not fix it
The standard response is to write more documentation. It rarely works, because the thing that is missing is not a page. It is a criterion.
Documents record what was decided. They almost never record the conditions under which the decision applies, the threshold that changes the answer, or the exception everybody in the team knows about and nobody has ever typed. That is the knowledge the repeated question is reaching for.
This is also why search cannot rescue you. Search finds what exists. If the criterion was never recorded, there is nothing to return, and a confident tool will assemble something that sounds right from whatever it did find.
MindKeepr captures what your team knows and keeps it usable, even after people leave.
Demand-driven gaps are the cheapest signal there is
A lot of knowledge programmes start by trying to map everything: every process, every role, every document. They stall, because the map is enormous and out of date the week it is finished.
There is a much cheaper starting point. A question that somebody actually asked, which the organisation could not answer from anything verified, is already evidence. It needs no reference model to interpret. It arrived with its own proof of demand, and closing it has obvious value to the person who asked.
Start there and the programme has a queue instead of a project.
What to do on Monday
Export the last sixty days of tickets. Group them by the question rather than the category, which usually means reading them, because the categories were chosen for routing and not for meaning. Mark every question that appears more than twice and has no document behind it.
For each one, write the name of the person who can confirm the answer. Where there is exactly one name, you have a dependency. Where there is no name at all, you have a gap you are already carrying, and it will surface at the worst possible moment.
This takes an afternoon and needs no new system. It also gives you the honest version of the question every vendor in this category will ask you: which knowledge actually matters here?
What changes when the answer is governed
Writing the answer somewhere is better than nothing, and it is not enough on its own. An answer with no owner and no date decays into the same folklore it replaced.
The version worth building routes the question to a named person with a deadline, keeps what they write as a candidate rather than publishing it, and puts it in front of somebody with the authority to confirm it. After that the answer carries who declared it, when, and what it was based on, and it is available to your people and to the AI agents you have approved.
When the underlying rule changes, the approval that relied on it reopens rather than silently covering the new text.
The number that actually matters
If you run this exercise, the tempting metric is how many gaps you found. The one that decides whether anything improves is how often the person you asked actually answers.
No vendor in this category publishes that number, including us. We intend to measure it in every pilot, because a system that asks people to confirm things they never volunteered will run out of goodwill long before it runs out of questions.
- ✓A repeated question is evidence, not noise, and it needs no process map to interpret.
- ✓The expensive gaps are undocumented criteria, not missing documents.
- ✓Writing more pages does not close a gap that nobody knew existed.
- ✓Count the repeats before buying anything: the exercise costs an afternoon.
- ✓A gap is closed when a named person's answer has been approved, not when a ticket is resolved.
FAQ
If it was resolved without linking to any document, and the answer came from a person's memory, the knowledge is not in your systems. Repetition tells you somebody keeps needing it.
Deflection tries to stop the question reaching a person. This is about making sure the answer exists, is owned, and is current, so deflection has something true to serve.
Wherever your people already work, with the answer carrying its source, its date and the person who stood behind it. A separate portal that nobody opens is the failure mode of every knowledge base.
An afternoon for a single team, using the ticket export you already have. The value is the list of questions with exactly one name, or none, against them.
Then you have learned something important before you bought anything. Response rate is the metric that decides whether a knowledge programme works, and it is worth measuring deliberately.
Start free in minutes, or get a demo on your own tools and team.
Faizan Khan is the co-founder and COO of MindKeepr, the operating memory for governed AI. He has twelve-plus years across enterprise IT and digital marketing and is also the founder and CEO of Cubitrek. At MindKeepr he leads growth, go-to-market, and customer experience.