From unanswered questions to better documentation: a weekly knowledge-gap review

An unanswered employee question is easy to dismiss as a bad prompt. Repeated unanswered questions are something else: evidence that the company cannot reliably deliver knowledge people need to do their work.

The useful response is not to upload more files at random. It is to run a small, repeatable review that distinguishes missing knowledge from retrieval, permission, freshness, and wording problems. The result should be an owned backlog of specific documentation fixes, not a dashboard nobody acts on.

This guide gives operations, HR, support, compliance, and knowledge owners a practical weekly workflow. It is designed for a small company: thirty minutes, a short queue, clear owners, and a retest before anything is closed.

What counts as a knowledge gap?

A knowledge gap exists when a person needs information to complete a real task, but the approved knowledge system cannot provide a reliable answer. The cause may be:

• The policy or procedure was never documented.
• The correct document exists but is not connected or indexed.
• Two versions conflict and nobody knows which one is authoritative.
• Access rules hide the source from someone who should be allowed to use it.
• The answer cites a document that does not support the claim.
• The question describes an exception that the current procedure does not cover.
• The user asks in language that the source or retrieval system does not handle well.

This distinction matters. Writing a new article will not fix a permission error. Re-indexing a folder will not resolve two contradictory policies. A useful review diagnoses the owner problem before choosing the remedy.

For the broader quality model, see answer quality, sources, and knowledge gaps. The supporting knowledge gap definition gives teams a shared vocabulary.

Why review gaps every week?

Knowledge-Centered Service, maintained by the Consortium for Service Innovation, treats knowledge as demand driven: actual requests reveal what people need, and use is part of review. The NIST AI Risk Management Framework likewise describes continuous, iterative management and regular incorporation of adjudicated feedback. Microsoft’s RAG guidance adds an important technical point: teams need representative questions and human feedback to diagnose whether a weak answer came from retrieval, generation, or another component.

Together, these ideas suggest a simple operating rule: do not guess what to document next. Use real questions, diagnose the failure, fix the smallest owner, and test again.

Weekly is frequent enough to catch patterns while people still remember the context. It is also light enough for an SME. High-risk teams may review urgent gaps sooner; the weekly review handles the normal queue.

The 30-minute weekly workflow

1. Group repeated questions

Start with unanswered questions, low-confidence answers, missing citations, and negative feedback from the previous week. Merge wording variants that represent the same job.

“Where is the parental-leave form?” and “Which document starts parental leave?” may belong to one gap. “Can my manager see my medical attachment?” is a different permissions question and should not be merged merely because both mention leave.

Keep the original wording. It preserves the language employees actually use and becomes a realistic retest later.

2. Inspect the attempted answer and sources

Read the answer, its cited passages, and the user’s feedback. Then check whether an authoritative source exists.

Classify the failure before editing anything:

This table prevents the documentation team from becoming a dumping ground for every AI failure.

3. Prioritize by operational impact

A gap deserves priority when it repeats, affects many people, blocks a frequent workflow, creates legal or security exposure, or causes customers to receive inconsistent answers.

Do not invent a precision score if the underlying data is weak. A short ordered queue is enough:

1. Safety, legal, financial, privacy, or access-control gaps.
2. Repeated gaps that block active work.
3. Onboarding and high-interruption questions.
4. Useful improvements with a known owner.
5. One-off questions that can wait for more evidence.

Occurrence count helps, but impact can outweigh frequency. A rare question about deleting customer data may matter more than ten questions about an office template.

4. Assign one owner and one due date

Every accepted gap needs a person responsible for deciding what changes. The owner is not necessarily the person who writes the final document. HR owns the leave rule; IT may fix the folder; a knowledge manager may edit the page.

Add a due date, a short internal note, and the expected answer or outcome. If nobody can identify the owner, that is itself an operating problem worth escalating.

5. Make the smallest durable fix

Prefer changing the existing authoritative source. New pages are justified only when no current owner serves the same intent.

A good fix might be:

• adding one missing exception to the approved policy;
• replacing an obsolete file;
• linking the correct source folder;
• correcting a document type or role;
• creating a concise procedure from a repeated support resolution;
• recording that the company intentionally has no approved answer yet.

The goal is not maximum documentation. It is a smaller distance between a real question and a trustworthy answer.

6. Retest the exact question and a neighbour

Ask the original question again with the same permissions. Then test one nearby formulation. Confirm that:

• the correct person can access the answer;
• the answer uses the approved source;
• the citation supports the material claim;
• an outdated source does not reappear;
• the system abstains when the evidence remains insufficient.

Microsoft’s guidance recommends representative, evolving evaluation questions because a RAG system has multiple interacting components. One successful phrasing is not enough proof that the gap is closed.

7. Close with evidence

Record what changed, which source now owns the answer, who verified it, and the retest result. Dismiss duplicates and irrelevant questions explicitly so they do not return as unexplained backlog noise.

A closed gap should be recoverable evidence of improvement. “Documentation updated” is too vague. “Replaced the 2024 leave policy, retested two approved questions as an employee, and verified the cited clause” is useful.

A worked example

Suppose three new employees ask how to request equipment for remote work. The assistant gives no source.

The reviewer first searches the connected documents. No approved procedure exists, but an operations manager confirms the current process in a private message. The gap is therefore missing documented knowledge, not failed retrieval.

Operations becomes the owner. The team adds a short equipment-request section to the existing onboarding handbook, names the request channel, approval limit, expected response time, and exception path. The updated handbook replaces the old version. The reviewer then asks the three original questions with a normal employee account and checks the cited section.

Only then is the gap closed. The fix improves onboarding, reduces future interruptions, and leaves one authoritative source.

How Polp supports the loop

Polp’s current product flow can detect gaps from low-confidence answers, missing sources, or negative feedback. Company administrators can review knowledge gaps, assign owners, set priorities and due dates, add notes and an expected answer, link or upload a source, and resolve, dismiss, or reopen the item.

That workflow does not decide the truth for the company. It makes the signal actionable and keeps the source, owner, and resolution together. Start with the Polp getting-started guide, then use a few real team questions before expanding the document set.

If you want to test the loop with representative company documents and permissions, request a Polp demo.

The small-company checklist

For each weekly review, leave with:

• a deduplicated list of real questions;
• a diagnosed failure type;
• a ranked queue;
• one owner and due date for every accepted gap;
• the smallest authoritative source change;
• a retest with the intended permissions;
• evidence for closing or dismissing the item.

A knowledge base becomes useful through this loop. The best backlog is not the longest one. It is the one that repeatedly turns real questions into clearer, current, permission-aware knowledge.

Sources

• KCS v6 Practices Guide — Consortium for Service Innovation
• NIST AI Risk Management Framework Core
• Evaluation and monitoring of RAG applications — Microsoft Learn
• Getting started with Polp