Module configuration
Knowledge gaps
How Gfacility spots a missing article: a search with zero results, logged as behaviour, clustered per topic and only reported once at least two different users hit the same wall.
Updated Aug 14, 2026
Configuration · Modules · Knowledge base
Most knowledge bases fail quietly. Nobody files a ticket saying “your documentation is missing a page about the VPN password”, they search, find nothing, and ask a colleague instead. Knowledge gaps turn that invisible moment into a measurable one: every search in Gfacility that returns zero results is logged, and once enough people hit the same wall it appears on a priority list for your content writers.
The trigger is behaviour, not opinion. A gap exists because a search produced no results, not because an AI decided an answer was not good enough.
What counts as a gap
Zero results, measured
The trigger is objective and reproducible: the search returned nothing. No model scores the quality of an answer.
A shared problem, not one person
At least two different users have to run into the same topic before it becomes visible as a gap.
Noise filtered out
Typing letter by letter, repeat searches and typos are merged, so the list shows topics rather than keystrokes.
A list, not a process
No ticket is raised and no workflow starts. You get a ranked backlog of topics to document.
Where a miss is registered
Three places in Gfacility log a miss in real time:
Knowledge base search
The search bar users type into when they look for an article themselves.
Find panel and AI chat
The search box in the find panel and in the AI chat, where questions are asked in natural language.
"Not helpful" feedback
An explicit thumbs-down on an article that was shown: the answer existed, but it did not help.
The process in six steps
| Step | What happens |
|---|---|
| 1. Registration | Real time. A search with zero results, in the knowledge base or the find panel / AI chat, is logged as a miss, as is explicit "not helpful" feedback on an article. |
| 2. Normalisation | The search text is cleaned up: punctuation removed, lowercased, stop words dropped. What is left under three characters is ignored. |
| 3. Noise suppression | The same user searching the same term within ten minutes does not create a second row. Type-ahead (typing letter by letter) is recognised and merged into one search. |
| 4. Clustering | At reporting time, typos and variants of one subject are merged through fuzzy matching on text similarity, so "vpn password reset" and "password reset" count as the same gap. |
| 5. Privacy threshold | Only once at least two different users hit the same problem does it become a visible gap. One individual mistyping something does not count, and anonymous searches never count. |
| 6. Result | A priority list: which subjects clearly lack documentation, how often it happens, and the exact search terms people used. |
Privacy by design
The threshold in step 5 is the point of the design, not a technical detail. A single search says something about one person; the same search by two different people says something about your documentation. Gfacility only surfaces the second kind.
Minimum of two users
Below the threshold nothing is shown, so the report can never be read as one colleague's search history.
Anonymous searches excluded
A search without a known user cannot contribute to the count, because it cannot be established that two different people are involved.
What your content writers get
The output is deliberately small: no ticket, no workflow, no approval chain. Just the three things you need to decide what to write next.
Subject
The clustered topic people were looking for and did not find.
Frequency
How often it happens, so the biggest gap is written first instead of the loudest request.
Exact search terms
The words people actually typed, which are the words the new article should use in its title and tags.
Those search terms are the practical part: an article titled with the phrasing your colleagues use will be found by the matching rules described in 4.2 Knowledge base, and will surface automatically the next time somebody creates a ticket about it.
Which decisions will you make?
Who reviews the list, and how often?
A fixed moment (monthly, or every sprint) beats an ad-hoc look, because frequency only becomes meaningful over a period.
Write an article, or fix the findability?
If the content exists, adding the searched-for wording as tags is often the faster fix.
Which language do people search in?
The search terms show it. In international teams that is the argument for a translated article rather than a new one.
Which gaps do you deliberately not fill?
Some searches point at another system entirely. Documenting that boundary once is also an answer.