Five Claude Projects that finally remember your context
You open Claude to write today’s email. Before you type a word about the actual email, you’re pasting in your offer, your voice, your list size, the same three paragraphs you pasted yesterday, and the day before that. By the time the context is loaded, you’ve spent longer briefing the assistant than you would have spent just writing the thing yourself.
Here’s the part that stings: your outputs aren’t bad because your prompts are bad. They’re bad because you’re dumping your entire business into one conversation and asking Claude to guess which facts matter for which question. Content rules sitting next to your refund policy, sitting next to half-finished product notes. Ask for a blog post, get something that reads like a policy memo. Ask for a support reply, get something that sounds like ad copy. The mud isn’t Claude’s fault. It’s the setup.
Claude Projects fix this, but not the way most people build them. A project holds its own instructions and its own files, and every chat you open inside it starts already knowing the job. Set one up right, and Claude shows up understanding your business before you type a word. Set one up wrong, one giant project trying to hold everything, and you’ve just built a slower version of the same mess.
The fix is in how you split the work. Here’s how I broke my business into Claude projects, and how to stand up the first one today.
How Do You Split Your Business Into Claude Projects?
Most online businesses land on four to six Claude projects, grouped by the kind of work rather than the topic. Start with a blank page and list every job you already hand to Claude: writing emails, drafting posts, answering buyer questions, planning products. Group the jobs that lean on the same background information. Those groups become your projects, usually Content, Email, Support, Products, and sometimes Affiliate or Client Work.
That grouping test matters more than it sounds like it should. Everything in your email project needs to know your offers, your voice, your list. Everything in your support project needs your policies and product details. When two jobs draw on the same files to come out right, they belong in the same room. A one-off task, like writing your About page, doesn’t earn its own project; drop it into the closest lane or just run it in a plain chat.
Write the names down before you build anything. Four clear lanes beat ten vague ones. And watch for a project quietly doing two jobs at once; if your content project keeps getting asked for sales pages, that’s the output telling you sales copy wants its own home. Split along the seam it shows you.
How Do You Set Up Your First Claude Project?
Open Claude, go to Projects, and create one. Name it in plain words — Email, Support, whatever you’d reach for in a hurry. The real work happens in the instructions box: brief Claude the way you’d brief a new hire on their first morning. Cover who you serve, what you sell, your voice, and what you never do. Then load two or three knowledge files and run one real test task before you trust it.
Length counts for less than clarity here. Five sharp lines beat a page of soft ones, and each rule should be something you could actually check the output against later. “Sound professional” fails that test; you can’t point at a sentence and prove it did. “Never start two paragraphs in a row with the same word” passes, because you can.
If the empty instructions box makes you freeze, hand the job to Claude first. Open a normal chat, outside any project, and ask it to draft the brief for you:
Prompt: I want to set up a Claude Project for [the part of my business you’re starting with]. I sell [what you sell] to [who you sell it to]. My voice is [three words that describe it]. Write a clear set of project instructions I can paste in, covering my audience, my offers, the tone I want, and three rules you should always follow.
Cut whatever doesn’t sound like you, paste the rest into the instructions box, then add your files, past work, your offer list, your policies, anything you want treated as settled fact instead of a guess. Two or three good files beat ten mediocre ones. Test the project on a real job, not a practice one. If the result needs heavy fixing, the instructions are almost always the problem, so go back and sharpen them before you touch anything else.
How Do You Build a Content Project That Actually Sounds Like You?
A content project needs writing samples, not adjectives. Load three or four real posts that show range, one teaching piece, one story-driven post, one short punchy caption, so Claude learns how your voice bends across formats instead of memorising one trick. Point it at a real topic you need this week, read the draft against your own work line by line, and turn every miss into a new instruction.
Telling Claude you’re “witty and warm” means almost nothing on its own. Pasting three posts where you actually were witty and warm shows it exactly what that looks like coming from you, which is a completely different kind of instruction, one it can copy instead of interpret.
Over a few weeks, the instructions box fills in with the small rules you keep wishing it followed. No semicolons. No three-item lists. Open with a question sometimes. By the end, you’ve taught it your style once, and, unlike a regular chat, it holds onto the lesson instead of forgetting it the second you close the tab. The same project handles repurposing for free, too: paste in a finished post and ask for five captions pulled from it, and because the project already knows your voice, the spin-offs sound like you, not like a flat summary of your own writing.
How Do You Set Up an Email Project Claude Can Actually Use?
An email project earns its own room because the job is genuinely different from content. A blog post can wander and still work, but an email has a few seconds to earn a click. Cover the kinds of emails you send, your sign-off, your usual length, and your subject-line habits in the instructions. Load your best past sends as files, and when you need a sequence, ask for the whole arc in one chat rather than one email at a time.
Small preferences do a lot of work here. If you like short lowercase subject lines, say so. If you never touch emoji in the inbox, write that down too; these are the details standing between a draft you can send and one you rewrite from the subject line down.
Drafting a launch sequence in a single chat keeps it connected: email five can point back at a promise email one made, which is hard to fake when you write them in separate chats on separate days. Save your winners back into the project as they prove themselves. When a send earns a strong open rate, drop it into the knowledge files and label it a proven one. Over a few months, new drafts start leaning on your real results instead of generic advice pulled from nowhere in particular.
How Do You Build a Support Project That Answers in Your Voice?
A support project needs your refund policy, your product details, and your most common buyer questions loaded as files, with instructions written in your warmer, more patient support voice. Set a hard limit inside those instructions: anything touching a chargeback, a legal threat, or a genuinely angry buyer gets flagged for you, not answered automatically. Everything else, it drafts straight from your real policies instead of inventing something you’ll have to walk back later.
The day-to-day rhythm is simple: a question lands, you paste it in, and you ask for a reply grounded in the files the project already holds. The easy ninety per cent go out after a quick read. The rare hard one still hands you a head start instead of a blank page.
Never let a reply leave without reading it first, no matter how good the draft looks. Claude can write a kind, clear answer in seconds, but it doesn’t know this particular buyer the way you do. Treat every draft as a starting point you approve, not a message that sends itself, and on the days you’re tired or annoyed, that pause is what keeps your worst mood from ever reaching a paying customer.
Content, Email, Support, that’s three lanes running. Standing up the first project is the only hard part; the second one takes half the time because you already know the rhythm: name it, write the instructions, load a few files, run a real test.
For creators and solo business owners who are tired of Claude sounding like five different people depending on which chat they’re in, subscribe for the rest of this breakdown: Products, Affiliate, drawing clean borders between projects, and the ten-minute monthly check that keeps all of them from going stale.