Keep Your Work Organized and Accessible

Claude Projects and organization

The Agency That Lost Three Hours Every Monday Morning

Meridian Content, a 12-person marketing agency in Bristol, was doing everything right with AI, or so they thought. Every team member had Claude Pro. They were using it daily for client briefs, campaign copy, social media calendars, and competitor analyzis. The problem surfaced during a Monday standup in February 2024. The account manager for their largest client, a national gym chain, had spent 45 minutes re-explaining the client's tone of voice to Claude before she could get a single usable email draft. The week before, a colleague had done the exact same thing. And the week before that. Nobody had written any of it down in a way Claude could actually use.

The agency was treating Claude like a search engine, open a tab, type a question, close it, repeat. Every conversation started from zero. There was no memory of the gym chain's brand guidelines, no record of the campaign strategy they'd spent six weeks developing, no awareness that the client hated exclamation marks and preferred British English. Three account managers were each rebuilding the same context from scratch, multiple times a week. The total wasted time across the team was somewhere between 8 and 12 hours every week. That's a full working day, every single week, spent re-teaching Claude things it had already been told.

When the agency's operations director discovered Claude Projects, a feature that had been sitting in their Claude Pro subscription unused, everything changed within a fortnight. They created a dedicated Project for each client. Inside each one, they uploaded brand guidelines, tone of voice documents, campaign briefs, and a one-page client overview. Claude read all of it once and remembered it across every conversation inside that Project. The Monday morning re-briefing ritual disappeared. Output quality jumped because Claude was always working with full context. The agency reclaimed those 8-12 hours per week and redirected them toward pitching two new clients.

The principle here isn't really about AI. It's about context. Any skilled colleague, a new hire, a freelancer, a consultant, does better work when they understand the full picture. The difference with Claude is that you can give it that full picture once, permanently (within a Project), and it never forgets, never gets distracted, and never needs you to repeat yourself. Claude Projects is essentially the mechanism that turns Claude from a smart stranger you keep meeting for the first time into a knowledgeable colleague who already knows your clients, your standards, and your goals before the conversation even starts.

Why Your Conversations Keep Starting From Zero

Most professionals use Claude the same way Meridian did before their breakthrough: open a new chat, type a question, get an answer, close the tab. This works fine for one-off tasks, looking something up, rephrasing a sentence, brainstorming quickly. But professional work isn't mostly one-off tasks. It's recurring, layered, context-heavy work. A sales manager isn't writing one proposal, she's writing 15 proposals a quarter, all for the same product, to the same types of buyers, following the same qualification criteria. An HR director isn't drafting one job description, he's building a consistent hiring process across six departments. Without Projects, every one of those tasks forces Claude to re-learn the same background information again and again.

The technical reason for this is something called a context window, the amount of information Claude can hold in its working memory during a single conversation. When you start a new chat, that window is empty. Anything Claude knew from a previous conversation is gone. This isn't a flaw; it's simply how the system works by default. Claude Projects solves this by giving you a persistent layer that sits above individual conversations. Documents you upload to a Project, and instructions you write in the Project's system prompt, are loaded into Claude's context automatically at the start of every conversation inside that Project. You stop re-briefing. Claude starts ready.

Here's the analogy that makes this click for most people: imagine you manage a brilliant but extremely literal assistant. Every morning, that assistant walks in with no memory of previous days, blank slate. You could spend 20 minutes each morning explaining who your key clients are, what your company's priorities are, and what standards your work needs to meet. Or you could hand them a well-written briefing pack on day one and say: 'Read this. It covers everything you need to know to work with me. I'll update it when things change.' Claude Projects is that briefing pack, except Claude reads it in milliseconds and never loses it.

Click to enlarge

How a Secondary School Department Head Used Projects to Reclaim Her Evenings

Rachel Osei heads the English department at a large secondary school in Manchester. She manages nine teachers, oversees curriculum planning for Years 7 through 13, and is responsible for ensuring every scheme of work meets Ofsted's updated inspection framework. Before Claude Projects, she used ChatGPT Plus occasionally for drafting, lesson plan templates, parent communication letters, staff meeting agendas. It was useful enough, but she was always starting from scratch. Every time she drafted a parent letter, she'd explain the school's communication style. Every time she built a lesson plan template, she'd re-enter the curriculum objectives for that year group. It was faster than doing it entirely manually, but still slower than it needed to be.

Rachel switched to Claude Pro and built three Projects: one for curriculum planning (containing the full English curriculum framework, her department's progression maps, and Ofsted's subject-specific guidance), one for staff management (containing her department's CPD priorities, performance review criteria, and a template library), and one for parent and student communications (containing the school's communication policy, tone guidelines, and a glossary of terms she needed to avoid for accessibility reasons). Within those Projects, her prompts became dramatically shorter and her outputs dramatically better. A lesson plan that used to take 40 minutes of back-and-forth now takes 12. She estimates she's saving 5-6 hours per week, time she's redirected toward one-to-one coaching with her less experienced teachers.

Projects vs. Regular Chats vs. Custom Instructions: What's the Difference?

The Sales Director Who Stopped Losing Institutional Knowledge

James Whitfield is a regional sales director at a B2B software reseller in the Midlands. His team of seven account executives each manages 20-30 accounts. The perennial problem in sales teams isn't effort, it's consistency and knowledge retention. When a deal is being negotiated, the account exec holds all the nuance in their head: the client's objections, the pricing history, the decision-maker's priorities, the competitive threats. When that account exec is on holiday, or leaves, or gets pulled onto another deal, that knowledge evaporates. James had tried CRM notes, shared documents, and team debriefs. None of it stuck reliably.

James built a Claude Project for each major account, the top 15 that represented 80% of revenue. Inside each Project, he stored the account's full history: key contacts and their roles, deal history, known objections and how the team had handled them, the client's procurement process, and current renewal timeline. When any team member needed to prepare for a call with that client, they opened the Project and asked Claude to help them prepare. Claude could pull together a pre-call briefing, suggest talking points based on the account history, or draft a follow-up email that referenced the right context. The knowledge was no longer locked inside one person's head, it lived in the Project, available to the whole team.

Building Your First Project the Right Way

Most people set up a Claude Project the wrong way on their first attempt. They create a Project, give it a name, and start chatting, without uploading any documents or writing a system prompt. That's like creating a folder, labeling it with a client's name, and leaving it empty. The Project structure exists, but Claude still has no more context than it would in a regular chat. The power of Projects comes entirely from what you put into them: the documents you upload and the instructions you write in the Project's system prompt field. Both matter, and they serve different purposes.

Documents you upload to a Project are reference material, the raw information Claude draws on when answering questions or producing outputs. These might be a client's brand guidelines (PDF), your company's pricing sheet (PDF or Word doc), a competitor analyzis you've already written, a set of email templates, or a strategy document. Claude can read these and refer to them in every conversation inside the Project without you having to paste the content in manually. Claude Projects currently supports PDFs, Word documents, plain text files, and several other common formats. You can upload up to 20 files per Project on Claude Pro, with each file up to 10MB.

The system prompt, sometimes called the Project instructions, is different. This is where you tell Claude how to behave inside this Project, not just what to know. This is where Rachel the department head wrote: 'You are assisting the Head of English at a secondary school. Always align lesson plan suggestions to the AQA specification. Use formal but approachable language in all parent communications. Never suggest activities that require more than £5 of materials per student.' This is where James the sales director wrote: 'When preparing call briefings, always lead with the client's most recent interaction and flag any open commitments we made in the last meeting.' The system prompt shapes Claude's judgment, not just its knowledge.

Click to enlarge

Key Principles From Part 1

1. Claude's default state is no memory, every new chat starts from zero, which is fine for one-off tasks but costly for recurring, context-heavy professional work.
2. Claude Projects solves the re-briefing problem by storing documents and instructions that Claude reads automatically at the start of every conversation inside that Project.
3. The difference between Projects and regular chats isn't just convenience, it's the difference between a knowledgeable colleague and a smart stranger you keep meeting for the first time.
4. Projects are scoped: each one is a separate workspace with its own context, so your gym chain client's guidelines never bleed into your retail client's work.
5. Two things make a Project powerful: uploaded reference documents (what Claude knows) and a system prompt (how Claude behaves). You need both.
6. Start with your most repeated work, not your most complex work, the ROI on a well-built Project compounds every time you use it.
7. The professionals getting the most from Projects, account managers, department heads, sales directors, share one habit: they invested 30-45 minutes setting up the Project properly before expecting results.

How a Marketing Agency Stopped Losing Context. And Started Winning Pitches

Bright Signal, a mid-sized digital marketing agency in Austin, was drowning in context. Every time a team member opened Claude to work on a client account, they spent the first five to ten minutes re-explaining the client's brand voice, target audience, competitors, and campaign history. Junior account managers were pasting the same brand guidelines document into every single conversation. Senior strategists were rewriting the same background paragraphs from memory. The work itself was good, but the setup was eating hours every week, across every client, across every person on the team.

The agency's operations director, Priya, noticed the pattern during a workflow audit. She calculated that her eight-person team was collectively spending roughly three hours per day just re-establishing context with AI tools. That's fifteen hours a week of pure overhead, context that evaporated the moment someone closed a browser tab. When Priya discovered Claude's Projects feature, she saw immediately what it could do. Within a week, she had built a separate Project for each of their twelve active client accounts. Each Project held the brand guidelines, tone-of-voice examples, target persona descriptions, and a running summary of recent campaign performance. Suddenly, every conversation started at full speed.

Three months later, Bright Signal had cut their AI setup time by roughly 80%. More importantly, the quality of their outputs improved. Claude wasn't just faster, it was more accurate, because it had the full picture every single time. Their pitch win rate climbed. Client feedback on content quality improved. The change wasn't about using a different AI tool. It was about using the same tool in a fundamentally smarter way. The principle Priya unlocked is the one this section is built around: persistent context is not a convenience feature. It is the difference between an AI assistant that helps occasionally and one that becomes genuinely embedded in your work.

The Principle: Context Is the Product

Most professionals treat each AI conversation as a fresh transaction, ask a question, get an answer, move on. That mental model made sense in the early days of these tools. But Claude Projects breaks that model entirely. A Project is a persistent workspace where everything Claude needs to know about a specific area of your work lives permanently. The context you build inside a Project doesn't disappear when you close the tab. It doesn't need to be re-entered next Tuesday. It accumulates. It deepens. Over time, a well-maintained Project becomes something closer to a knowledgeable colleague than a search engine, one who already knows your clients, your tone, your constraints, and your goals before you say a word.

Building a Project That Actually Works: The Three Layers

When Priya built Bright Signal's first client Project, she made a mistake that most people make initially. She dumped everything into the Project instructions, brand guidelines, campaign history, competitor notes, team preferences, legal disclaimers, all in one enormous block of text. The outputs were better than before, but something was still off. Claude was occasionally contradicting itself or missing nuances buried deep in the instructions. After some experimentation, Priya discovered that Projects work best when you think in three distinct layers: what Claude should always know, what Claude should reference when relevant, and what Claude should produce in a specific style.

The first layer is the Project Instructions, a focused, well-structured briefing that tells Claude who it's working for, what the core objectives are, any non-negotiable rules, and the tone or style it should always use. For Bright Signal's client accounts, this meant: the client's business in two sentences, the target audience in three bullet points, the brand voice in specific descriptive terms (not vague words like 'friendly' but concrete ones like 'conversational but never casual, confident without being arrogant'), and a short list of topics or phrases to always avoid. Tight and specific beats long and comprehensive every time.

The second layer is uploaded documents, files that Claude can pull from when they're relevant without needing to process them constantly. Previous campaign reports, competitor analyzis documents, product spec sheets, example emails or copy that represents the right tone. These act like a reference library. The third layer is the conversation history within the Project itself, the accumulated record of what you've asked, what Claude produced, what you refined, and what decisions you made. Over weeks and months, this history becomes genuinely valuable. A new team member joining an account can read through recent Project conversations and get up to speed faster than any handover document would allow.

Click to enlarge

A School Principal Runs an Entire Academic Year From One Project

Marcus is a primary school principal in the UK. He manages a staff of thirty-two, communicates with hundreds of parents, writes Ofsted-readiness documentation, handles safeguarding correspondence, and still tries to be present in classrooms. When he started using Claude, he initially created a new conversation for every task, a letter to parents here, a staff meeting agenda there. The results were decent but generic. The tone didn't sound like him. The letters didn't reflect his school's specific values. He had to edit everything heavily before it was usable.

Marcus built a single Project called 'St. Clement's. Academic Year 2024/25'. Inside it, he uploaded his school's communication policy, a set of previous letters he considered excellent examples of his voice, the school's current development priorities, and a brief description of his community (mixed urban catchment, high proportion of EAL families, strong parental engagement culture). He wrote Project Instructions that told Claude to always write in his voice, warm but professional, never condescending to parents, always assuming positive intent from families. Now when Marcus needs a letter about a trip, a safeguarding reminder, or a response to a difficult parent email, he opens the Project and gets a first draft that sounds like him, reflects his school's values, and requires maybe two minutes of editing rather than twenty.

Projects vs. Standard Conversations: What You're Actually Choosing Between

How a Sales Director Uses Projects to Coach a Distributed Team

Diane manages a sales team of fourteen across four time zones at a SaaS company selling HR software. Coaching consistency has always been her biggest challenge, her team members have different experience levels, different communication styles, and different gaps. When she discovered Claude Projects, her first instinct was to use it for her own work: drafting call scripts, preparing for QBRs, writing pipeline commentary. That worked well. But her second use case turned out to be more powerful: she built a Project specifically designed to help her team members self-coach between one-on-one sessions.

Diane's 'Sales Coaching' Project contains their ICP (ideal customer profile) in detail, their top three objection-handling frameworks, anonymized examples of strong and weak discovery call transcripts, and instructions telling Claude to always respond in a coaching tone, asking questions rather than just giving answers, pushing the team member to think through their own reasoning before offering a perspective. Any team member can open the Project, paste in a call they're unsure about, and ask Claude to help them diagnose what went well and what to do differently next time. Diane reviews the conversations during their one-on-ones. The quality of those sessions has noticeably improved because her team arrives having already done some of the reflective work.

Putting It Into Practice: Designing Your First Project Architecture

The most common mistake professionals make when first setting up Projects is using them the same way they used folders on a shared drive, organizing by document type or department rather than by workflow. A Project called 'Marketing Documents' is almost useless. A Project called 'Q3 Product Launch. Horizon Software' is immediately actionable. The distinction matters because Claude's persistent context is only valuable when it's specific. Broad Projects create broad outputs. Specific Projects create work you can actually use. When you're deciding how to structure your Projects, start with your recurring work: the clients you return to weekly, the reports you produce monthly, the campaigns that run across a quarter.

Once you've identified your recurring work streams, think about what Claude would need to know to help you effectively with each one, and only that. Resist the urge to over-document. A Project with crisp, relevant context outperforms one stuffed with every document that might conceivably be useful. A good test: if you were handing this Project to a smart new colleague and asking them to pick up the work, would reading the Project Instructions and uploaded files give them everything essential? Would it take them less than fifteen minutes to feel oriented? If yes, your Project is well-structured. If no, it probably needs trimming rather than expanding.

The third practical consideration is maintenance. Projects aren't set-and-forget. A client's priorities shift. A campaign ends and a new one starts. Your team's tone preferences evolve. Build a habit of reviewing your most-used Projects once a month, updating the instructions to reflect current reality, archiving documents that are no longer relevant, and adding new examples of strong outputs that Claude should emulate. This fifteen-minute monthly habit is what separates professionals who get compounding value from Claude Projects over time from those who find the tool gradually drifting out of alignment with their actual work.

Key Lessons From This Section

1. Persistent context is not a convenience, it's the mechanism that transforms Claude from a one-off tool into an embedded workflow partner.
2. Projects work in three layers: core instructions, reference documents, and accumulated conversation history. Each layer serves a different purpose.
3. Name Projects specifically. 'Client Name. Purpose' beats 'General Work' every time, because specificity shapes the quality of every output inside it.
4. Project Instructions should read like a Day One briefing for a smart new hire, focused, specific, and anchored in concrete examples rather than vague descriptions.
5. The same tool serves radically different professional contexts: a marketing agency, a school principal, a distributed sales team. The structure adapts to the work.
6. Over-stuffing a Project with documents reduces quality. Tight, relevant context consistently outperforms comprehensive but unfocused context.
7. Projects require light, regular maintenance, monthly reviews keep them aligned with your actual current work rather than drifting toward obsolescence.

Making Claude Projects Work Across Your Whole organization

Shopify's solution was deceptively simple: they built a small library of shared Project setups, one for campaign briefs, one for customer research synthesis, one for executive reporting. Each Project had a consistent system prompt that established brand voice, output format, and context about the team's priorities. New team members got onboarded by being given access to the relevant Project. Senior marketers stopped re-explaining context every session. Output quality became predictable. The team wasn't just using AI individually, they were using it as a team, with shared standards baked in.

The principle here is straightforward: Claude Projects aren't just a personal productivity tool. They're an organizational asset. When you invest time building a well-structured Project, with clear instructions, relevant documents, and a defined purpose, that investment pays off every time anyone uses it. The Project becomes institutional knowledge, made reusable.

The Knowledge Problem Claude Projects Actually Solve

A mid-sized law firm in Chicago had a recurring problem with client intake. Junior associates were spending 45 minutes per new client pulling together background context, jurisdiction, case type, relevant precedents, before they could even begin drafting. Senior partners had all this knowledge in their heads, but it wasn't written down anywhere useful. When the firm built a Claude Project specifically for client intake, they uploaded their standard intake questionnaire, a glossary of firm-specific terminology, and a document outlining the five most common case types they handled. Junior associates started getting first drafts of intake summaries in under five minutes.

The partners hadn't done anything technical. They'd done something curatorial. They decided what Claude needed to know, wrote it down clearly, and put it in one place. The Project became a container for expertise that previously lived only in senior people's heads, and that expertise became accessible to everyone on the team, every time they opened the Project.

This is the real organizational value of Projects: they externalise expertise. When a senior consultant builds a Project for proposal writing that includes the firm's pricing rationale, typical objections, and preferred narrative structure, that Project transfers knowledge that would otherwise take months of mentorship to pass on. It doesn't replace mentorship, but it accelerates it dramatically.

A School District That Turned One Teacher's Work Into Everyone's

A curriculum coordinator at a K-8 school district in Oregon spent three weeks building a Claude Project for lesson planning. She uploaded the district's learning standards, a style guide for how teachers were expected to write objectives, and examples of high-quality lesson plans from the past two years. She wrote a system prompt that told Claude the grade bands, subject areas, and the district's philosophy around differentiated instruction. Then she shared the Project setup instructions with every teacher in the district.

Within a month, teachers reported spending 40% less time on lesson plan drafting. More importantly, the plans were more consistent with district standards, not because anyone was policing them, but because Claude was already working within those standards every time a teacher opened the Project. The coordinator's three weeks of upfront work multiplied across 60 teachers. That's the compound return on a well-built Project.

Click to enlarge

The Sales Director Who Stopped Losing Deals to Bad Prep

A regional sales director at a B2B software company noticed that her team's win rate dropped on deals where reps had less than 48 hours to prepare. The prep work, researching the prospect, anticipating objections, tailoring the pitch, was taking too long. She built a Claude Project that contained the company's product positioning documents, a list of common objections with approved responses, competitor comparison notes, and a template for pre-call briefs. Reps could now generate a solid pre-call brief in 15 minutes instead of two hours.

The win rate on short-notice deals improved by 18% over the following quarter. The director hadn't changed the product, the pricing, or the team. She'd changed how knowledge flowed to the people who needed it, exactly when they needed it. The Project was the mechanism, but the insight was organizational: expertise shouldn't be bottlenecked by time or seniority.

The practical path to organizational Project use starts with one honest conversation: what does your team do repeatedly that eats time and produces inconsistent results? That's your first Project. It doesn't need to be ambitious. A Project that helps your team write better meeting agendas consistently is worth more than a sprawling Project that tries to do everything and does nothing well.

Once you've built that first Project, document what you put in it and why. Write a short 'README', even just a few bullet points, that explains what the Project is for, what files are uploaded, and what the system prompt is trying to achieve. This makes it maintainable. When your team's priorities shift, or new products launch, or the brand voice changes, you'll know exactly what to update and where.

Finally, treat your Projects as living documents. The best Project builders review their Project instructions every 60-90 days. They ask: is Claude still giving us the right outputs? Has anything changed that the Project doesn't reflect yet? Does the system prompt still describe what we actually need? A Project that gets reviewed and refined compounds in value over time. One that's set up and forgotten gradually drifts out of alignment with how your team actually works.

1. Claude Projects store your instructions and documents permanently, you never re-explain context from scratch.
2. A well-built Project is organizational infrastructure, not just a personal shortcut.
3. System prompts should define purpose, tone, format, and assumptions, not just topic.
4. Uploaded documents give Claude specific knowledge about your team, clients, or standards that the base model doesn't have.
5. Sharing Project setups (instructions + files) lets your whole team benefit from one person's careful setup work.
6. Projects externalise expert knowledge, making it accessible regardless of who built it or when.
7. Review and update Project instructions every 60-90 days to keep them aligned with how your work actually evolves.
8. Start with one high-frequency, high-inconsistency workflow, then expand once that Project is solid.

Click to enlarge