AI Writing & Creator Studio
How to write a literature review from your knowledge base — a step-by-step guide for remote team leads and ops people who want to audit what their team's documentation actually covers, find knowledge gaps before creating new processes, and synthesize institutional knowledge into structured reference documents.
Remote team leads and ops people who maintain team knowledge bases — Notion workspaces, Confluence wikis, shared Google Drive folders, internal playbooks — often find themselves in a specific bind when writing new documentation or redesigning a process: they don't know what their existing knowledge base actually contains.
It's not that the documentation doesn't exist. It's that it was written incrementally, by different people, at different times, for different purposes. The onboarding section was written 18 months ago. The process docs were updated by three people over two years. The retrospectives live in a folder no one looks at. No single person has read all of it recently enough to know what it currently says, what's consistent, and what's missing.
A literature review from your knowledge base is the answer: a systematic survey of what your existing documentation says about a topic, organized by theme, with explicit coverage gaps identified. It's a knowledge audit that tells you — before you write new documentation or redesign a process — what your current knowledge base covers, where it's consistent, where documents contradict each other, and what it doesn't address at all.
This is the most internally-focused of all the literature review formats: you're surveying your own organization's documented knowledge rather than external published sources.
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.
| 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 |
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.
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]
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:
List every document in your scoped sections:
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.
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.
For each theme group, write 2-4 sentences describing what the documents say about that topic. Then add a consistency rating:
Partially consistent and contradictory ratings are the most actionable findings in a knowledge base literature review.
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.
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)
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:
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
INCONSISTENCIES IDENTIFIED
RECOMMENDATIONS FOR DOCUMENTATION WORK
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.
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)
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.
More WebSnips articles that pair well with this topic.
How to write a literature review from your bookmarks — a step-by-step guide for knowledge workers and consultants who want to triage a large bookmark library, extract key findings with targeted re-reading, and produce a structured topic survey before writing a white paper or client deliverable.
How to write a literature review from your meeting notes — a step-by-step guide for product managers and strategists who want to synthesize findings from multiple customer conversations, stakeholder sessions, or user research calls into a structured thematic analysis.
How to write a literature review from your reading notes — a step-by-step guide for students who want to turn their notes from multiple sources into a structured thematic review that synthesizes what the literature shows, identifies gaps, and prepares them to write grounded academic papers.
How to write a literature review from your web clippings — a step-by-step guide for knowledge workers and consultants who want to turn a curated clippings collection into a structured topic survey that orients client deliverables, white papers, and internal strategy documents.
How to write a literature review from your clipped articles — a step-by-step guide for marketers and SEOs who want to survey existing content on a topic, map what angles have been covered, and find the content gaps before creating their next piece.
How to write a literature review from your saved research — a step-by-step guide for writers and journalists who want to survey existing coverage on a topic, identify what angles have been taken, and find the gaps before writing their own piece.