Detecting Knowledge Gaps From Failed Searches and Repeats

Methodology and findings

Research question

Which signals reliably indicate that a help desk knowledge base is missing or mislabeling an answer, and how can a team distinguish a content gap from a search, routing, or product problem? The unit is one search or one repeated question linked to the article set shown and the action the agent took next.

Start with the customer's language

Knowledge gaps are often described in internal vocabulary. Customers use different words for the same problem. Capture the query as entered, the channel, the product or service, and the result the customer was trying to achieve. Do not clean up the query before storing it. The misspelling, the regional term, and the vague phrase are evidence about how people search. Group queries by intent after collection, not by rewriting them into the taxonomy you wish customers used.

Use six signals

A practical signal set includes: a search with no clicks; a search followed by a contact within the same session; a repeated question from multiple customers within a short window; an agent opening several articles and then escalating; a ticket reopened after an article was sent; and a manual workaround used repeatedly. Each signal has a different false-positive rate. A no-click search may mean the answer was visible in the snippet. A repeated question may reflect a product change rather than a missing article. Use at least two signals before declaring a gap.

Inspect the result set, not only the query

For each candidate gap, record the top results, their titles, their last review dates, and the step where the customer or agent stopped. A relevant article with an unclear title is a labeling problem. A correct article buried below an outdated one is a ranking or retirement problem. No article at all is a content gap. An article that answers a different product version is a version problem. These need different owners and different fixes.

Read the ticket that followed

A search is only a proxy for need. Read the contact or the agent's note that followed the search. Identify the actual question, the missing fact, and the workaround used. If the agent solved the issue with a sentence that is not in any article, that sentence is a candidate for the knowledge base. If the agent needed a system permission or a product fix, the gap is not a writing problem. Classify the proximate cause before assigning the article.

Run three review passes

First, a volume pass: which gaps appear most often and affect the most customers? Second, a risk pass: which gaps touch access, money, safety, legal rights, or protected data? Third, a feasibility pass: which gaps can be fixed with the available source owner and review capacity? A high-volume cosmetic gap may be less urgent than a low-volume access gap. A gap that no one can own will not be fixed by adding it to a backlog. Rank by risk and feasibility, not volume alone.

Fix the system around the article

Some gaps require more than a new page. Add synonyms to search, improve the intake form so the customer's goal is captured, split a long article, retire an obsolete one, or add a related-article link. Measure the effect on the original signal: does the no-click search now lead to a click, does the repeated question decline, does the agent stop escalating? If the signal does not move, the fix may have addressed the wrong cause. Keep the baseline and the retest date.

Avoid counting the same gap twice

Deduplicate by intent and by source, not by exact query text. Two different phrasings may point to the same missing answer. Conversely, one phrase may hide two different product problems. Use a stable gap identifier and link all related queries and tickets to it. Record when a gap is merged, split, or closed. This prevents a dashboard from showing fifty gaps when there are five underlying issues.

Limitations

Search logs may omit voice calls, chat, and informal help. A repeated question can reflect a confusing product rather than a missing article. Article views do not prove comprehension. The method depends on access to queries and tickets under the organization's privacy rules. It should not be used to monitor individual agents or customers. The output is a prioritized learning agenda, not a complete map of everything the support team knows. Keep the raw query set under the same retention rule as other support records, and remove personal data before sharing the analysis outside the review group.

Practical use

Run the method monthly on one product area. Review the top risk-weighted gaps with the article owners, choose a small number of fixes, and retest the same signals. Publish the closure reason so the team can see the difference between a written answer, a search improvement, and a product change.

Sources

1. W3C Web Content Accessibility Guidelines 2.2 - Content structure and accessibility criteria. Checked October 22, 2026.
2. W3C WAI, Use Clear and Understandable Content - Clear-language guidance for reader comprehension. Checked October 22, 2026.
3. U.S. GAO, Assessing Data Reliability - Data provenance and fitness-for-use review. Checked October 22, 2026.

Related research

• Designing a Reopen Taxonomy Study for Help Desk Queues
• A Method for Testing First-Contact Resolution Denominators