Building an AI Knowledge Base for a 30-Person Company — Full Walkthrough

Every company has a knowledge problem. The 30-person marketing agency I worked with last month had a particularly painful one.

Their CEO told me: "Every time someone goes on vacation, three projects stall. When someone quits, we lose six months of institutional knowledge. And onboarding a new hire takes three weeks because everything they need to know is trapped in someone else's head."

I'd heard some version of this story a hundred times. Tribal knowledge is the silent killer of growing companies. When you're five people, everyone knows everything. At ten, it starts getting spotty. By thirty, you're running on collective memory and hope.

They'd tried a wiki. It lasted about two months before it went stale. They'd tried a shared Google Drive. It turned into a digital junk drawer with 4,000 documents and no organization. They'd tried Notion. Three people used it enthusiastically. Everyone else ignored it.

What they needed wasn't another documentation tool. They needed a system that could answer questions — even when the answer was buried across five different documents that nobody remembered existed.

What We Built

The system has three layers:

Layer 1: Document ingestion. We built a pipeline using n8n that automatically pulls content from their existing sources — Google Drive, Notion, Slack (pinned messages and bookmarked threads), their project management tool (Asana), and even their email templates. Every time a document is created or updated, the pipeline re-indexes it.

Layer 2: Vector search with Claude. The ingested content gets chunked, embedded, and stored in a vector database (we used Pinecone for this project, though Supabase with pgvector works well for smaller deployments). When someone asks a question, the system finds the most relevant chunks and passes them to Claude, which synthesizes an answer.

Layer 3: Conversational interface. We deployed the whole thing as a Slack bot. No new tools to learn, no new apps to open. People ask questions in Slack the same way they'd ask a coworker. The bot responds with an answer and cites which documents it pulled from.

The entire build took about three days — one day for the ingestion pipeline, one day for the search and synthesis layer, and one day for the Slack integration and testing.

How It Works in Practice

A new hire on their second day types in Slack: "How do we handle client onboarding for enterprise accounts?"

The bot responds in about four seconds with a structured answer: the standard onboarding process, which templates to use, who the point person is, where the project brief template lives in Google Drive, and what the typical timeline looks like. It cites three sources — an onboarding checklist from Notion, a process document from Google Drive, and a Slack thread from six months ago where the VP of Client Services outlined an updated process.

That question would have previously required interrupting at least two people and waiting for someone to dig through their files. Now it takes four seconds and nobody gets pulled away from their work.

The Tricky Parts

The hardest challenge was conflicting information. When you index thousands of documents, you inevitably find documents that contradict each other. An old process doc says one thing, a recent Slack message says another. Which one is right?

We handled this with recency weighting — newer documents get priority over older ones. But we also built a flagging system. When the bot detects conflicting information, it presents both versions and notes the dates, so the person asking can make a judgment call. Over time, this actually helps the company clean up its documentation because conflicts get surfaced instead of silently causing confusion.

Another challenge: sensitive information. Not everyone should have access to everything. HR documents, financial data, client contracts — the bot needed to respect access controls. We built a permissions layer that checks the Slack user's role against document access levels before returning results. If someone asks about salary bands and they don't have HR access, the bot says "I found some information on this topic, but you'll need to check with HR for access."

The third challenge was quality control. AI can hallucinate, and in a knowledge base, a wrong answer is worse than no answer. We implemented a confidence threshold — if the bot isn't confident in its answer, it says so and suggests who to ask instead. We also log every question and answer for weekly review. In the first month, the accuracy rate was about 91%. By month two, after tuning the prompts and improving the document indexing, it was 97%.

The Results

After 60 days:

- New hire onboarding dropped from 3 weeks to 4 days - The bot handled an average of 85 questions per day - "Hey, do you know where..." Slack messages to senior staff dropped by roughly 60% - The CEO estimated the company saved about 120 hours per month in interruptions and knowledge-sharing overhead - Employee satisfaction scores for "I can find the information I need to do my job" went from 3.2/5 to 4.6/5

The system also created an unexpected benefit: it revealed gaps in their documentation. When the bot couldn't answer a question, it logged it. After the first month, they had a clear list of topics that needed documentation — which made their knowledge base better over time.

Lessons Learned

1. Meet people where they work. A knowledge base nobody opens is worthless. Putting it in Slack — where the team already lives — was the single most important design decision. 2. Stale documentation is worse than no documentation. The auto-indexing pipeline is critical. If the knowledge base doesn't update automatically, it'll go stale within a month. 3. Confidence calibration matters. An AI that says "I don't know" when it's unsure is infinitely more trustworthy than one that confidently makes things up. 4. Start with the most-asked questions. We seeded the system by interviewing five team leads about the questions they got asked most. That gave us a test suite and ensured the highest-value queries worked from day one. 5. The data cleanup is the real work. Building the AI layer took three days. But auditing, cleaning, and organizing the existing documentation was an ongoing process that took weeks. Budget for it.

FAQ

What happens when the knowledge base doesn't have an answer? The bot responds with "I don't have a confident answer for this. You might want to ask [relevant team lead based on topic]. I've logged this question so we can add it to the knowledge base." This turns unknown questions into documentation tasks automatically.

How does it handle updates when documents change? The n8n pipeline runs on a schedule — Google Drive and Notion are re-indexed every 6 hours, Slack channels are monitored in real time. When a document is updated, the old chunks are replaced with new ones. There's typically a 1-6 hour delay before changes appear in answers.

Is this just RAG (Retrieval Augmented Generation)? At its core, yes — it's a RAG system. But the devil is in the details: the permissions layer, the conflict detection, the confidence thresholding, the automatic gap detection, and the Slack-native UX are what make it actually useful versus a basic chatbot that hallucinates.

How much does it cost to run? For this 30-person company, about $150 per month — Pinecone hosting, Claude API usage, and n8n infrastructure. That's $5 per employee per month for a system that saves each person several hours per week.

Can this replace our wiki entirely? Not exactly. The AI knowledge base is a read layer — it helps people find and synthesize information. You still need somewhere to author and store documents. But most companies find that once the AI layer makes everything searchable, the pressure to maintain a perfect wiki structure disappears.