Brianna Bates

Notes — AI Enablement

How to Build a Company Knowledge Base with NotebookLM and Google Docs SOPs

The step-by-step approach — and why the SOP format matters as much as the AI tool.

Published: June 2026

Every company has institutional knowledge that lives in one person's head. Not in a document, not in a wiki — in the memory of the dispatcher, the senior engineer, the customer success lead who's been there since year one.

That knowledge is irreplaceable until the person retires, leaves, or just isn't available when a new hire needs an answer at 2am. And by the time the problem is visible, it's already urgent.

Here's how to fix it before it becomes urgent — using Google Docs and NotebookLM, both free, both in your company's stack right now.

Step 1: Write SOPs in the right format for AI retrieval

NotebookLM cites its answers from the source documents you upload. That means the quality of the answers it gives is determined entirely by the quality of the documents you put in.

Most SOPs fail the AI-retrieval test because they're written for compliance, not for use. Long paragraphs, buried procedures, passive voice. When a new hire asks NotebookLM "what do I do if a customer smells gas?", the answer is only as good as what the relevant SOP actually says — clearly, specifically, in that exact section.

Write SOPs with this structure:

SectionWhat to include
PurposeOne sentence. What does this SOP cover and why does it exist?
Applies toWho uses this, under what conditions.
StepsNumbered. One action per step. Imperative voice ("Call the customer" not "The customer should be called").
ExceptionsWhat changes for specific cases — urgent situations, specific customer types, edge conditions.
EscalationWhen and how to escalate. Who gets the call, what information to have ready.
Common mistakesSpecifically what new hires get wrong. This section alone is worth 40% of the ramp reduction.

Write them in the voice of the person whose knowledge you're capturing. "Dale's notes" in Dale's tone — as if a senior colleague is speaking directly to a new hire — are more useful than a policy manual written in the third person.

For the Enderby Gas project, I wrote five SOPs covering: Will-Call Order Procedure, No-Heat Emergency Triage, New Customer Onboarding, DOT Inspection Pre-Check, and Auto-Fill Eligibility Rules. Five documents. Five Google Docs. That's the entire knowledge base corpus.

Step 2: Load everything into NotebookLM

  1. Go to notebooklm.google.com — free with a Google account.
  2. Create a new notebook. Name it something employees will recognize: "Operations Library," "CS Playbooks," "[Your Company] Knowledge Hub."
  3. Add sources: upload your Google Docs directly. NotebookLM processes them and indexes the content.
  4. Test it immediately. Ask a question a new hire would actually ask: "What do I do if a customer is on a will-call account and they haven't ordered in 60 days?" If the answer is wrong or vague, the SOP has a gap. Fix the SOP first, not the AI.

NotebookLM's key behavior: it cites every claim it makes with numbered chips that link back to the exact source document and passage. Employees can verify every answer. That's what makes it trustworthy instead of just convenient.

Step 3: Build a Gemini Gem as the second layer

NotebookLM is the searchable knowledge base — you give it your documents, employees ask questions, it cites answers from the source.

A Gemini Gem is a custom AI assistant you configure with a specific persona and rules. The two work together: NotebookLM for research and verification; the Gem for fast, conversational answers, especially in high-pressure situations like emergency calls.

The critical configuration for a Gem used in operations:

  • Restrict the scope. "Answer only from the SOPs in the attached documents. If the answer isn't in the documents, say so — do not improvise."
  • Lead with the critical action in emergencies. "For any no-heat, gas odor, or safety call, start with the immediate action required, not with background context."
  • Flag out-of-scope questions. "If a customer asks about something outside your documented procedures, say 'That's outside what I have documented — escalate to [supervisor]' rather than guessing."

The Enderby Gem, named "Dale," answered a test question about a no-heat emergency — elderly customer, oxygen-dependent husband, no gas smell — by leading immediately with the priority protocol, then walking through the escalation steps in the exact order the No-Heat Triage SOP specifies. No hallucination. No generic advice. The documented procedure, surfaced in the right order.

The outcome

Five SOPs, one NotebookLM notebook, one Gemini Gem. Built in under two weeks on free-tier tools.

Projected impact for the Enderby engagement: new-hire ramp from 6 months to 6–8 weeks. Senior-staff interruptions down 40–60%. Every emergency protocol documented and queryable, not dependent on who answers the phone.

The most important outcome isn't on that list: the knowledge is no longer at risk. One retirement doesn't create an operational crisis anymore.

Read the full case study — the complete SOP list, the "Dale" demo, and the benchmarked impact figures

Back to notes

Brianna Bates builds searchable knowledge systems, SOP libraries, and practical AI-assisted workflows for service businesses. Discuss a knowledge system.