How to Write Literature Review from Your Knowledge Base

Do You Actually Know What Your Own Documentation Says?

Ask a remote team lead what their knowledge base currently says about onboarding, or incident response, or vendor escalation, and the honest answer is usually a guess. Not because the documentation doesn't exist — because it was written incrementally, by different people, at different times, for different purposes, and no one has reread all of it recently enough to know what it currently says.

The onboarding section was written eighteen months ago. The process docs were updated by three people over two years. The retrospectives live in a folder no one opens. Nothing here is wrong, exactly — it's just unaudited.

A literature review from your knowledge base is that audit: a systematic survey of what your existing documentation says about a topic, organized by theme, with coverage gaps and contradictions made explicit. It tells you, before you write new documentation or redesign a process, what's consistent, what conflicts, and what isn't addressed at all.

This is the most internally-focused literature review format in this cluster — you're surveying your own organization's documented knowledge, not external sources — and WebSnips' literature review generator can produce the audit once you've grouped your documents by theme.

---

Knowledge Base Literature Review vs. Knowledge Base Research Report

Both formats draw on an organizational knowledge base, but for different purposes:

	Knowledge Base Literature Review	Knowledge Base Research Report (Article 771)
Purpose	Audit what's documented; find gaps	Analyze operational patterns and trends
Content focus	What the documentation says	What the data/events in the KB show
Source material	SOPs, guides, playbooks, policies	Incident logs, retrospectives, decision records
Primary question	"What have we documented about X?"	"What patterns do our records show about X?"
Output use	Before rewriting docs; new team member orientation	Operational decisions; process improvement
Gap focus	Missing documentation	Missing data or unresolved operational questions

The literature review asks: "What does our knowledge base say?" The research report asks: "What do our records show?" The former audits documentation; the latter analyzes operational evidence.

---

When to Write a Knowledge Base Literature Review

Situation	What it tells you
Before rewriting or consolidating process docs	What the existing docs say, where they conflict, what they miss
Before building a new process or policy	What related processes are already documented so you don't contradict them
Onboarding a new team lead or ops manager	A synthesized view of what the KB covers on their area, faster than reading every doc
Quarterly knowledge audit	What's documented vs. what's outdated or missing across the KB
After team turnover	What institutional knowledge has been captured vs. what left with departing team members

---

The Confidentiality Consideration

Knowledge bases are internal documents, and a literature review drawn from them inherits that confidentiality — with some additional complexity.

Client and partner references: Many knowledge base documents reference specific clients, vendors, or partners by name in the context of processes or past decisions. A literature review that synthesizes those documents should not include specific client or partner names — describe the pattern without identifying the parties. "Our escalation process was revised after a high-urgency account situation in Q2 2023" rather than "[Client name]'s support request triggered a process change."

Personnel references: Process documents often reference specific team members — "Sarah handles X" or "the process was approved by [manager]." A literature review that will be shared with the team should aggregate these to role references: "the ops lead handles X" rather than individual names. For internal-only use by the author, this may be less critical.

Sensitivity tier: Before treating a knowledge base section as material for a literature review, assess its sensitivity. High-sensitivity documents (legal, financial, HR records, client contracts) typically shouldn't be synthesized into a broadly shared document even within the organization. Standard process documentation, SOPs, and playbooks are generally appropriate.

---

The Knowledge Base Literature Review Format

KNOWLEDGE BASE LITERATURE REVIEW: [Topic]
[Date] | Documents reviewed: [N docs, date range of creation/last update] 
Prepared by: [Name] | For use: [Internal only / Team-shared]

SCOPE
What sections of the knowledge base were reviewed (documentation categories, 
folders, or spaces). Date range (when documents were created or last updated). 
Research question: "What does our knowledge base currently document about [topic]?"
Note: any sensitive sections excluded, any team areas not covered.

WHAT THE KNOWLEDGE BASE DOCUMENTS (by theme)

Theme 1: [Theme name — e.g., "Customer onboarding — first 30 days"]
[2-4 sentences: what the documents on this theme collectively say. Where 
documents agree. Any inconsistencies across documents on the same process.]
Documents in this group: [N documents]
Consistency: [Consistent / Partially consistent / Contradictory]
Most recent update: [Date of most recently updated document in this group]
Key documents: [Document title(s)]

Theme 2: [...]

[3-5 themes]

GAPS — WHAT ISN'T DOCUMENTED
• [Process or policy that team members handle but that isn't in the KB]
• [Topic area that documents reference but don't explain ("see the relevant policy"
  with no link to the policy)]
• [Outdated or empty sections]

INCONSISTENCIES IDENTIFIED
• [Two documents that give different guidance on the same situation]
• [A process documented in one place that contradicts a related process elsewhere]

RECOMMENDATIONS FOR DOCUMENTATION WORK
[3-5 bullets: what documentation to create, update, or consolidate based on the review]

DOCUMENTS REVIEWED
[Organized by theme: document title, location in KB, last updated date]

---

Step-by-Step: Write a Literature Review From Your Knowledge Base

Step 1: Define the Review Scope and Question

One sentence: "What does our knowledge base currently document about [topic], and where are the gaps?"

Then define what sections of the knowledge base you'll review. Don't try to review everything — scope to the relevant area:

• "The customer success and onboarding sections" for an onboarding literature review
• "The engineering process and incident management sections" for a process audit
• "The product and roadmap documentation" for a product strategy alignment review

Step 2: Inventory the Documents

List every document in your scoped sections:

• Document title and location in the KB
• Last updated date (this tells you staleness)
• Author/last editor (for follow-up questions)
• Brief descriptor of what it covers

This inventory reveals the landscape before you start reading. Documents that haven't been updated in 18+ months are candidates for the "outdated" gap. Documents with unclear scope are candidates for consolidation.

Step 3: Read for Consistency, Not Just Content

When reviewing knowledge base documents, read for two things at once:

What does this document say? → For the theme synthesis Does this document agree with related documents? → For the inconsistency section

The inconsistency check is the most uniquely valuable part of a knowledge base literature review. External literature reviews check for conflicting findings across studies; knowledge base reviews check for conflicting guidance across your own documentation — an equally important type of inconsistency that typically goes unexamined.

Step 4: Write Theme Syntheses — With Consistency Ratings

For each theme group, write 2-4 sentences describing what the documents say about that topic. Then add a consistency rating:

• Consistent: All documents in this group give compatible guidance
• Partially consistent: Documents agree on main points but differ on details (e.g., different examples, slightly different timelines)
• Contradictory: Documents give different guidance on the same situation — this requires resolution

Partially consistent and contradictory ratings are the most actionable findings in a knowledge base literature review.

Step 5: Identify Documentation Gaps

Three types of documentation gaps:

Missing documentation: Processes that team members follow but that aren't written down anywhere. You typically identify these by asking "Is there a doc for how we handle X?" and getting "no, [person] just knows how to do that."

Dangling references: Documents that reference other documents, policies, or resources that don't exist or can't be found. "See the relevant policy" with no link is a documentation gap.

Outdated sections: Documents last updated more than 12-18 months ago in a rapidly changing area — these are high-risk for having outdated information that people continue to follow.

Step 6: Draft With a Grounded Prompt

I'm writing a literature review of our team's knowledge base on [topic].

Sections reviewed: [KB sections, date range of documents]
Research question: What does our current KB document about [topic]?

My theme groupings with consistency notes:

Theme 1: [Name] — [N documents]
What documents say: [Summary of guidance]
Consistency: [Consistent / Partially consistent / Contradictory]
Most recent update: [Date]
Issue (if any): [What's inconsistent or outdated]

Theme 2: [...]

Documentation gaps: [Missing, dangling references, outdated sections]
Inconsistencies to resolve: [List]

Draft:
SCOPE (1 paragraph)
WHAT THE KNOWLEDGE BASE DOCUMENTS (3-5 themes: synthesis + consistency rating + 
most recent update + key documents)
GAPS (bullets by type: missing / dangling / outdated)
INCONSISTENCIES (bullets with document pairs)
RECOMMENDATIONS (3-5 bullets)
DOCUMENTS REVIEWED (by theme)

---

Before/After Worked Example

Context: A remote operations lead at a 40-person distributed company is about to rewrite the customer onboarding playbook. Before writing, she wants to understand what the knowledge base currently says about onboarding.

Documents found in KB on onboarding:

• "Onboarding Overview" — created 2021, last updated 2022
• "Customer Success Kickoff Call Guide" — created 2023, last updated 2024
• "Account Setup Checklist" — created 2022, never updated
• "30-Day Check-In Template" — created 2023, last updated 2023
• "Escalation Policy" — created 2020, references a "Senior CS Manager" role that no longer exists
• "Onboarding FAQ (Internal)" — created 2023, 8 questions answered, 4 marked [TBD]

Before (no audit, writing from scratch): "I'll just write a new onboarding playbook. I'll look at the old docs as I go but mostly start fresh."

Result: She unknowingly duplicates some good 2024 content, contradicts the escalation policy without realizing it, and misses that the account setup checklist has never been updated since 2022.

After (knowledge base literature review):

---

KNOWLEDGE BASE LITERATURE REVIEW: Customer Onboarding November 2024 | 6 documents, last updated 2020–2024

SCOPE Six documents in the Customer Success section of the Notion knowledge base related to customer onboarding. Review question: what does our current KB say about the onboarding process, and where does documentation need to be created, updated, or consolidated?

WHAT THE KNOWLEDGE BASE DOCUMENTS

Theme 1: Kickoff call and initial setup (2 documents) The Kickoff Call Guide (2024) and the Account Setup Checklist (2022) both cover the first week of onboarding. The Guide is current and detailed; the Checklist has not been updated since 2022 and references two product features that have been renamed and one that no longer exists. Guidance in these two documents is currently contradictory on account permission setup.

Documents: 2 | Consistency: Contradictory | Most recent update: 2024 (Guide), 2022 (Checklist) Issue: Checklist is outdated and contradicts current kickoff guidance on account setup steps

Theme 2: 30-day engagement (1 document) The 30-Day Check-In Template provides a consistent framework that team members appear to use. No contradictions. Slightly outdated on product feature names (refers to legacy terminology from 2023).

Documents: 1 | Consistency: Consistent (internally) | Most recent update: 2023

Theme 3: Escalation process (1 document) The Escalation Policy (2020) describes an escalation path to a "Senior CS Manager" role that was restructured in 2023. The current escalation path is not documented anywhere in the KB.

Documents: 1 | Consistency: N/A (single document) | Most recent update: 2020 Issue: Critically outdated — describes a org structure that no longer exists; current escalation path is undocumented

GAPS — WHAT ISN'T DOCUMENTED

• Current escalation path (the 2020 policy is obsolete; new path exists in practice but not in writing)
• Renewal process at end of first contract term — referenced in the Overview but not documented anywhere
• How to handle onboarding when a customer's primary contact changes during the onboarding period
• 4 of 8 FAQ questions are marked [TBD] — customer questions that are regularly asked but not yet answered in the KB

INCONSISTENCIES IDENTIFIED

• Account setup steps described in the Kickoff Call Guide (2024) conflict with the Account Setup Checklist (2022) — specifically, permission configuration sequence
• "Onboarding Overview" (2022) describes a 60-day onboarding period; the 30-Day Check-In Template implies a 30-day model — no document clarifies which is current

RECOMMENDATIONS FOR DOCUMENTATION WORK

• Update Account Setup Checklist immediately (or retire it and absorb into the Kickoff Guide)
• Rewrite Escalation Policy with current org structure — this is high-risk to have outdated
• Document current renewal process: interview the team lead who owns it and write it up
• Complete the 4 TBD items in the FAQ
• Resolve and document the 30-day vs. 60-day onboarding model question at the team lead level, then update the Overview

---

This review identified specific inconsistencies and gaps before the playbook rewrite — preventing the ops lead from writing new content that would conflict with 2024 guidance she didn't know existed, or leaving the critical escalation path undocumented.

---

Prompts to Reuse

Knowledge Base Literature Review

I'm reviewing our team's knowledge base on [topic].

Documents reviewed: [N docs, date range, KB sections]
Research question: What does our KB currently document about [topic]?

My theme groupings:
Theme 1: [Name] — [N docs] — Consistency: [C/PC/Contradictory] — 
Most recent update: [Date] — Issue: [If any]
Theme 2: [...]

Gaps identified: [Missing / dangling refs / outdated — by category]
Inconsistencies: [Document pairs that contradict]

Draft:
SCOPE (1 paragraph)
WHAT THE KNOWLEDGE BASE DOCUMENTS (3-5 themes: synthesis + consistency + date + issue)
GAPS (bullets by type)
INCONSISTENCIES (bullets with doc names)
RECOMMENDATIONS (3-5 action bullets)
DOCUMENTS REVIEWED (by theme with last-updated dates)

---

Key Takeaways

1. A knowledge base literature review audits what's documented, not just what exists: the output is a structured picture of what your KB covers, where it's consistent, and where it's missing.
2. Consistency is the most valuable thing to check: external literature reviews compare studies; knowledge base reviews compare your own documents — contradictions between internal documents are high-risk.
3. Last-updated dates are as important as content: a document that hasn't been updated in 2+ years in a changing area is a gap even if it once was accurate.
4. Dangling references are a specific type of gap: "see the policy" with no link is a knowledge base failure — find and close these during the review.
5. Don't reference specific clients or team members by name in shared versions: aggregate to role references and anonymize client identifiers.

---

Conclusion

A literature review from your knowledge base does for organizational documentation what external literature reviews do for published research: it surveys the landscape, identifies themes, surfaces inconsistencies, and makes gaps explicit. The result isn't a writing deliverable — it's a pre-writing audit that tells you what you can build on, what needs to be updated before you can rely on it, and what documentation work needs to happen before the new playbook, policy, or process document is written. Run the audit before writing the thing, not after.

To go deeper, check out AI Knowledge Management in 2025.