How to Set Up an Agency Knowledge Base That People Actually Use
Most agency knowledge bases are graveyards. Documentation from three years ago sits next to process changes nobody updated. The search function barely works.
Links are broken. Nobody can find anything, so they just ask each other instead.
Then the person who knows the answer leaves and suddenly nobody knows how to do it anymore. The knowledge walks out the door. You end up recreating the wheel, training the same processes over and over, and watching experienced team members repeat mistakes that were already solved.
A useful knowledge base requires more than creating it. It requires structure, maintenance, and habit. It's not a one-time project.
It's an ongoing system that needs an owner and regular care. But the payoff is enormous. A good knowledge base compounds over time.
As your team grows, new people get productive faster. Processes don't disappear when people leave. Institutional knowledge actually stays institutional.
Where to Put It - Pick One Tool and Stick With It
Use one place. Not scattered docs across three different tools.
Not a mix of Google Drive folders, Slack threads, and email attachments. One tool so people always know where to look.
Notion, Confluence, Google Drive, a wiki - the tool itself doesn't matter as much as consistency. If it's scattered, it might as well not exist.
People will stop looking and start asking. Then you're the knowledge base, and you'll burn out.
Whatever tool you choose, keep it organized like a book with a clear structure. New team members should be able to find the onboarding docs immediately.
Project managers should know exactly where to find client onboarding templates. Designers should know where the design process lives.
A solid structure looks like this: Getting Started covers onboarding docs and first week checklists. How We Work covers your processes, standards, and how decisions get made. Tools and Tech covers how to use your software, access guides, and account management.
Project Delivery covers templates and best practices broken down by project type. FAQ covers the questions you answer repeatedly.
What Actually Gets Used - Be Specific, Not Theoretical
The docs that get used are short and specific. Not long guides about abstract concepts. Not ninety-page strategy documents.
"How to reset Slack password" is useful. "Effective communication" is too broad and nobody remembers it.
"Client onboarding checklist for retainer clients" is useful. "Best practices for client relationships" is too vague.
For processes, write in steps. Not "We believe in thorough documentation" and then rambling paragraphs. Steps are scannable and memorable.
"Step 1: Schedule kickoff call. Step 2: Send client brief template.
Step 3: Collect responses. Step 4: Schedule design kickoff." People can follow that.
For best practices, use actual examples. Not theory. Don't write "We believe in clear deliverables." Write "When we onboard a client, here's the template we use and here's how we customized it for a recent e-commerce project." Examples stick with people more than principles.
Include screenshots for tool documentation. If you're explaining how to do something in Asana or Jira or wherever your team tracks work, show it. Don't just describe it.
Make docs skimmable. Use headings, bullet points, and bold text so people can scan in 30 seconds.
If they need more detail, they'll read deeper. But most people want the quick answer first.
The Maintenance System - Assign an Owner
Documentation dies because nobody maintains it. Six months pass and your processes have changed but the docs haven't.
People stop trusting the knowledge base because it's outdated. Then they stop using it.
Assign an owner. Someone responsible for accuracy and updates. Not the manager.
Managers are busy. Someone who's curious, organized, and likes systems. Someone on the team who actually enjoys this kind of work.
The owner doesn't have to create all the documentation. Other people can write docs about their areas.
But the owner is responsible for making sure the docs are organized, current, and actually useful. The owner is the keeper of the system.
Do a quarterly review. Every three months, the owner asks: "What changed in the last three months? What processes did we iterate on?
What new templates did we create? What docs are outdated?" Then they update. Quarterly is enough.
You don't need to review monthly. You don't want to update continuously. Once per quarter creates a sustainable rhythm.
When you change a process, document the change immediately. That same week. Before people forget how it used to work and start mixing old and new.
Fresh changes are easy to document. Three months later you won't remember why you changed it.
Search and Organization - Structure for Your People
Organize by user type, not by topic. Different people need different things.
New team members look in "Getting Started." They don't need to know about advanced project management. They need onboarding and basics.
Designers look in "Design Process." They don't care about finance or account management.
Project managers look in "Project Management." Account managers look in "Account Management."
Not everyone needs everything. But everyone should know where to look for their thing. This prevents information overload and makes the knowledge base feel simpler than it actually is.
Add tags so search works better. Tag docs with "SEO," "client onboarding," "retainers" so people find docs three different ways - by category, by tag, or by search. Good tagging makes a knowledge base 10 times more useful.
Include a search function that actually works. If your tool has search, make sure it's enabled and working. If people can't find things, they won't use it.
The Minimum Viable Knowledge Base - Start Small
Start small. Don't try to document everything and burn out in the process.
You'll never finish. You'll create a monster.
Document the things that matter: your onboarding process because new people need it immediately. Your main processes because people do them repeatedly and you don't want to explain them each time.
Your tools because people need to know how to access accounts and use your software. FAQ because you answer the same questions again and again.
Four sections. Forty pages.
That covers 80% of what people ask. Everything else is nice to have.
Add more as you grow. After a year, you'll know what docs are actually missing.
You'll hear the questions people keep asking. Document those.
FAQ
Should we require people to use the knowledge base? No. But make it good enough that they want to. A bad knowledge base is worse than no knowledge base because it trains people not to trust documentation. If people think docs are outdated, they'll ask instead.
What if someone writes documentation that's not great? Thank them and offer to refine it. "This is solid. Let me reorganize slightly and add examples." Get them in the habit of contributing. Most people's documentation improves over time.
How often should we update docs? When something changes, update immediately. Quarterly review to check everything's current overall. Don't create a maintenance burden that's unsustainable.
Should we have video documentation? Some. For complex processes or tool tutorials, video helps people learn faster. But start with written. Video is harder to keep current when processes change.
What if nobody reads the documentation? The documentation isn't working for them. Ask people: "What would make this useful?" Maybe it's the format, maybe it's the organization, maybe the content is wrong. Ask directly.
Can we use the knowledge base for client documentation? Separate it. Client-facing docs are different from internal docs. They have different audiences, different purposes, different tone. Keep them apart so you don't accidentally share internal stuff or bore clients with stuff they don't need.
How do we prevent outdated documentation? Owner reviews quarterly. When something changes, update immediately. Archive old versions instead of deleting them so you have history. Consider adding a "last updated" date so people know if something's current.