How to structure Claude Projects across your whole organisation

Most Claude admins start by creating a Project. Then another one. Then three more. Six months later, they have 23 Projects with names like "Marketing v2", "New CS Project", and "Test - ignore", and nobody knows which one to use.

Org-wide Project architecture matters. Here is how to build it right from the start.

The core principle: one Project per distinct context

A Project is a shared context — a system prompt, a set of documents, a set of enabled Skills and Connectors. Create a new Project when the context meaningfully changes.

Create separate Projects for:

• Each team function with distinct work (CS, marketing, sales, ops, engineering, HR)
• Use cases with different audiences (internal vs. customer-facing)
• Use cases with different risk profiles (drafting emails vs. reviewing legal documents)

Do not create separate Projects for:

• Individual users within the same team
• Slight variations on the same use case ("CS - Tier 1" and "CS - Tier 2" probably don't need separate Projects)
• Experiments — use personal Projects for that, not the org's shared workspace

The naming convention that actually works

Bad names: "Marketing", "CS Team", "Operations v3", "New Project (Josh)"

Good pattern: [Function] — [Use Case]

Examples:

• Customer Success — Ticket Drafts
• Marketing — Content Creation
• Sales — Prospect Research
• HR — Policy Q&A
• Operations — Process Documentation
• All Staff — General Assistant

The function prefix lets people find their Project instantly. The use case suffix signals what it is for. When you have 15 Projects, this structure makes the list readable.

Ownership: who is responsible for each Project

Every Project needs an owner — one person who owns the system prompt, decides what documents to upload, and is accountable for the quality of outputs.

This is not the Claude admin. The Claude admin manages access, billing, and governance. The Project owner manages the context. These are different jobs.

Good Project owners:

• CS Project: CS team lead or senior CS rep
• Marketing Project: content lead or marketing manager
• Sales Project: sales enablement or top-performing AE
• HR Policy Project: HR business partner

The admin's job with Projects: create them, enforce the naming convention, set the initial framework for the system prompt, and make sure ownership is assigned. Then get out of the way.

System prompt governance

The system prompt is the most important decision you make per Project. It determines what Claude knows about your organisation, what tone it uses, and what it will and will not do.

Three rules for org-wide system prompt governance:

1. The admin writes a template; the owner fills it in. Do not let owners write system prompts from scratch. Give them a structured template:

You are a [role] for [Company]. Your job is to [primary function].
Audience: [who you are serving]
Tone: [2-3 tone descriptors]
Always: [2-3 behaviours you always do]
Never: [1-2 hard constraints]
Context: [key facts about the company/team/product]

2. System prompts are version-controlled. Keep the current system prompt for each Project in a shared document (Notion, Google Doc). When it changes, note what changed and why. If a Project starts producing bad outputs, you need to know what changed.

3. Treat the system prompt like a job description. Vague job descriptions produce confused employees. Vague system prompts produce inconsistent outputs. A tight 300-word system prompt beats a sprawling 2,000-word one every time.

What documents to upload per Project

Upload documents Claude needs to give accurate, on-brand answers. Not documents Claude might find useful someday.

For each Project, identify:

1. What factual questions will users ask? Upload the source of truth for those facts.
2. What tone or style standards apply? Upload the brand or communications guide.
3. What is off-limits to guess about? Upload the definitive reference.

For a CS Project: product FAQ, known issues list, escalation guide, support tone guidelines.
For a marketing Project: brand voice guide, ICP description, messaging house, product positioning doc.
For an HR Project: employee handbook summary, benefits overview, PTO policy, escalation contacts.

Do not upload everything. Upload what matters. Uploading a 200-page employee handbook to a CS Project creates noise, not value.

The full org Project map (starting point)

Here is a reasonable starting structure for a company with 20–100 people:

Project	Owner	Key documents	Skills
Customer Success — Ticket Drafts	CS Lead	Product FAQ, tone guide	File creation
Marketing — Content	Content Lead	Brand guide, ICP doc	Web search
Sales — Prospect Research	Sales Lead	Product one-pager, ICP	Web search
Operations — Process Docs	Ops Lead	Existing SOPs	File creation
HR — Policy Q&A	HR BP	Handbook summary, policies	None
All Staff — General	Admin	Company overview, org chart	Web search

Start with the teams that have the clearest use cases and the most to gain. You can always add Projects; it is harder to merge badly designed ones.

Project sprawl: what to watch for

Signs your Project architecture is breaking down:

• Duplicate Projects with similar names
• Projects whose owners have left the company
• Projects that haven't been used in 60+ days
• System prompts that say "you are a helpful assistant" — no real configuration

Do a quarterly Project audit. Consolidate duplicates, archive unused Projects, reassign orphaned ones. Fifteen well-maintained Projects are worth more than fifty neglected ones.