Claude Projects: your new knowledge management system

Shut down our Confluence workspace last month.

Archived Notion entirely. Everything now lives in Claude Projects. The difference? When I need to know something, I ask. The knowledge answers back.

This is not another storage system. This is conversational knowledge that evolves through use. Projects turn documentation into an expert you can question.

Why wikis fail your team

Research pegs knowledge management failure rates between 50-70%. That is not a typo. Most knowledge systems never deliver their promised value.

The problem is simple. Traditional wikis and knowledge bases are graveyards. You dump information in, organize it carefully, maintain taxonomies, and then what? People search. They scroll. They give up and ask someone directly.

I have watched this pattern for years at Tallyfy. Teams spend weeks building comprehensive documentation in Notion or Confluence. Six months later, the same questions keep getting asked in Slack because searching documentation feels harder than interrupting a colleague.

The core issue is not the information. It is the interface. Static documentation requires users to hunt rather than ask. But humans are wired for conversation, not keyword search.

And the maintenance burden. Someone needs to keep pages current, remove outdated content, reorganize as the business changes. This rarely happens. Documentation degrades into noise.

How Claude projects knowledge management transforms this

Projects give Claude a 200,000 token memory. That is roughly 500 pages worth of context. Upload your documentation once, and Claude can reference all of it in every conversation.

The shift is fundamental. Instead of “Where did we document the onboarding process?” you ask “What are the first three steps for onboarding a new client?” Claude answers using your actual documentation, synthesizing across multiple sources if needed.

This is active knowledge. It responds to questions. It connects related information you would not have thought to link. It adapts its explanations based on who is asking.

And here is what sold me: the knowledge improves through use. Every conversation where someone asks about a process or policy becomes a test of whether the documentation is clear. Gaps become obvious immediately.

No more “check the wiki.” Just answers.

Organizing Projects without overthinking it

The instinct is to recreate your current folder structure in Projects. Resist this.

Best practices suggest breaking knowledge into focused Projects based on how teams actually work, not theoretical organization charts. I use:

One Project per major business function. Sales playbook. Product documentation. Operations procedures. Customer success knowledge. Each gets its own Project with relevant team members.

Functional Projects over comprehensive archives. Rather than one massive company wiki Project, create focused spaces. The sales team does not need to wade through engineering specs to find pricing guidelines.

Custom instructions per Project. Tell Claude the perspective to take. The sales Project has instructions to answer like a sales leader. The technical Project responds like a senior engineer. This context shaping is powerful.

Within each Project, organization matters less than you might think. Claude is handling 200K tokens of context simultaneously. Dump in your existing documentation. The model finds connections without needing your careful folder hierarchies.

The main advice from implementation guides is to start private and expand access deliberately. Knowledge with sensitive information should not be in shared Projects until you have governance sorted.

Real patterns from teams using Projects

Talked to several operations leaders using Claude projects knowledge management over the past few months. Patterns are emerging.

Sales playbooks work especially well. Upload positioning documents, competitive analysis, pricing guides, objection handling. Sales reps ask “How do we handle pricing questions for enterprise deals?” and get consistent answers based on your actual methodology.

Technical documentation becomes accessible. Engineering teams put API docs, architecture decisions, deployment procedures into Projects. New developers ask clarifying questions in natural language rather than parsing dense technical specs. Onboarding time drops significantly.

Process documentation finally gets used. Operations teams report their standard procedures are now being followed because people can ask “How do I process a refund?” instead of hunting through 47 pages of process docs.

Training materials scale better. Rather than scheduling training sessions or assigning reading, new team members ask questions of the Project. They get answers tailored to their context, referencing the training materials but not requiring them to read everything first.

The shift is from “here is where we keep information” to “ask what you need to know.”

Moving from wikis to Projects

Do not try to migrate everything at once. Start with the documentation people reference most. For most teams, this is:

Pick your most painful knowledge gap. The thing people keep asking about in Slack. Gather those documents, upload them to a Project, and direct the next question there.

Watch how people use it. You will learn what is missing faster than any documentation audit would show you. Knowledge that actually gets questioned reveals its gaps immediately.

Give Claude custom instructions about tone and perspective. If this is customer support knowledge, tell Claude to answer like your best support rep. If it is technical documentation, specify the level of detail to provide.

Share the Project with relevant team members gradually. Start with people who are comfortable testing new tools, then expand as the value becomes obvious.

Keep your existing systems running in parallel initially. Some teams will want the safety net. As confidence builds, archive the old wikis.

The goal is not a perfect knowledge base from day one. The goal is knowledge that improves through actual use rather than theoretical maintenance.

Traditional knowledge management assumed the problem was storage and organization. The real problem was always interaction. Claude projects knowledge management fixes that.