How to set up Claude for your whole company
You've been asked to "get Claude set up for the team." Here's exactly what that means, what decisions you need to make, and what to do in what order.
Someone — probably a founder, a department head, or your IT manager — has asked you to set up Claude for the team. Here's what that actually involves.
What "setting up Claude" means
There are two things to set up: access and context.
Access is the easy part: everyone needs a Claude account. Anthropic's Team plan handles billing and user management centrally. You provision seats, people log in with their work email.
Context is what makes Claude useful versus just available. Without it, everyone on your team is starting from zero every conversation — explaining who you are, what you do, and what they need each time. With it, every conversation starts with Claude already knowing your company, your tone, and your use case.
That context lives in Claude Projects.
What a Project is and why admins care
A Project is a shared workspace where you can:
- Set persistent instructions (the system prompt) that apply to every conversation in that Project
- Upload documents that Claude can reference — product docs, style guides, SOPs, templates
- Invite team members so everyone works from the same starting point
You'll typically create one Project per team or use case, not one per person.
The four decisions to make before you build anything
1. Which teams get their own Project?
Start with the teams that have the clearest, most repetitive use cases. Customer success (ticket responses), marketing (content), and sales (prospect research) are usually the first three. Operations comes next. Create separate Projects — don't mix teams, they have different contexts and tone requirements.
2. Who writes the Project instructions?
This is the most important decision you'll make. The instructions define how Claude behaves for everyone in the Project. The person who writes them needs to understand both the team's work and what good output looks like. Don't delegate this to the most junior person. For each Project, work with the team lead to draft the instructions together.
3. What documents go in each Project?
For each team, identify the 3–5 documents Claude would need to give accurate, on-brand answers. For CS: your product FAQ and support tone guidelines. For marketing: your brand voice guide and ICP description. For sales: your product one-pager and objection-handling notes. Upload these to the Project.
4. What's the rollout sequence?
Don't roll out to everyone at once. Start with one enthusiastic person on each team. Let them work out the rough edges for 2–3 weeks. Then expand. The early adopter's learnings — what the instructions should say, what prompts work, what to watch out for — are more valuable than any training doc you could write upfront.
Step-by-step: building a Project
Go to Projects in the Claude sidebar and create a new one. Name it clearly: "CS Team" not "Project 1."
Write the system prompt. For a CS team, something like:
You are a customer support assistant for [Company]. You help draft responses to customer tickets. Always acknowledge the customer's frustration before addressing the issue. Be concise and specific. If you're unsure about a product detail, say so rather than guessing. Tone: professional and warm, not robotic.
Upload your key documents. Product FAQ, tone guide, known bugs list, escalation guide. Anything a new support rep would need to read before handling tickets.
Test it before sharing. Run 10 representative ticket types through it. Does Claude get the tone right? Are there accuracy gaps? Fix the instructions before the team sees it.
Invite the team. Share the Project link. Run a 20-minute walkthrough showing one or two concrete prompts that work.
What to monitor in the first month
- Are people actually using it? (If not, the workflow isn't clear enough — talk to users, not the manager)
- Are there consistent output quality problems? (Fix the Project instructions, not the users)
- Is anyone using it in ways that produce risk? (Customer-facing outputs should have human review in the workflow)
The admin mistake to avoid
Creating one giant "All Teams" Project with a generic system prompt. This produces mediocre outputs for everyone. The leverage is in specificity — a tight CS Project that knows your product, your tone, and your escalation criteria will produce dramatically better outputs than a general one.
One focused Project per team is worth ten generic ones.