Every operations team that deploys Claude has the same decision to make: does each team member start from a blank session every time, or from a shared workspace that already contains the company’s communication standards and workflow specifications?
The blank session is faster to set up. The workspace is faster to use.
The blank session is faster to set up. The workspace is faster to use — because the context is already loaded and the output reflects the company rather than the AI’s defaults.
This article walks through the specific steps to build a shared Claude workspace for an operations team: creating the Projects structure, uploading the context documents, configuring the custom instructions, and training the team on the workspace versus the blank session.
The build takes two to three days for a team with a completed context pack. The payoff is operational AI outputs that are company-specific from the first sentence.
Pre-publication note: verify current Claude Projects feature availability, file upload limits, custom instruction character limits, and team sharing mechanics at docs.claude.com before publication.
Step 1: Create the Project structure
How many Projects
For a 20 to 50 person operations team: typically two to three Projects.
Option A: One comprehensive Operations Project
All operations functions (customer service, compliance, scheduling, supplier management, management reporting) share a single Project. Context documents cover all functions. Custom instructions specify the most common workflows across functions.
Best for: teams of 8 to 15 where the COO or operations director wants one shared environment and functions are not highly specialised.
Option B: Function-specific Projects
Each sub-function has its own Project: Customer Service Project, Compliance Project, Scheduling and Operations Project, Management Reporting Project. Each Project’s context is focused on its function’s specific needs.
Best for: teams of 20 or more where different functions have distinct vocabulary requirements, different regulatory contexts, or where context document overlap would create confusion.
The naming convention
Name each Project so team members immediately know which one to open.
| Clear naming | Not clear |
|---|---|
| ”[Company name] — Customer Service" | "Operations AI" |
| "[Company name] — Compliance" | "Team Workspace" |
| "[Company name] — Management Reporting" | "Project 1” |
The naming convention also signals to the AI system owner what each Project is for when reviewing the workspace structure.
The access configuration
When creating the Project (or configuring via the admin console for Teams accounts), set the access level:
- Full access: team members who run AI workflows in this Project regularly
- View access: managers who need to review outputs but do not run workflows themselves
- Admin access: the AI system owner who maintains the context documents and custom instructions
Verify current access configuration options at docs.claude.com.
Step 2: Upload the context documents
What to upload
The context documents from the Phase 1 Foundation build: structured documents built during the context pack sprint, not raw company documents.
Into every operations Project:
- Company overview (150 to 200 words): what the company does, who its customers are, what makes it distinctive
- Brand voice guide (200 to 250 words): how the company communicates, including tone, vocabulary, and relationship conventions
Into the Customer Service Project:
- Customer communication standards (250 to 300 words): tier-based communication conventions, common situation framing
- Exception and delay vocabulary (150 to 200 words): the specific language for the most common disruption types
Into the Compliance Project:
- Regulatory vocabulary guide (250 to 350 words): precise regulatory terminology, citation format, documentation requirements
- Compliance report format standards (150 to 200 words): required sections, narrative conventions, submission format
Into the Management Reporting Project:
- Operations briefing format (150 to 200 words): the sections, metrics, and narrative structure of the weekly or monthly briefing
- Management communication standards (100 to 150 words): how the operations team communicates with the leadership team
If you have not yet built these context documents, see what an AI context pack is for the structure and how to give AI full business context for the drafting approach.
What not to upload
- Entire policy manuals or employee handbooks: too long, dilutes context focus
- Raw client contracts or confidential third-party documents: data handling risk. Often not necessary for workflow purposes.
- Historical examples without editing: examples of past work without quality filtering produce outputs at the average quality of historical work, not the best quality
- Documents in formats Claude does not process cleanly: verify supported formats at docs.claude.com
How to organise the uploads
Name each uploaded document descriptively: “Customer Communication Standards [Company Name],” “Regulatory Vocabulary Guide [Company Name].”
The document name appears in the Project’s file list. Clear names help the AI system owner identify which document to update when a revision is needed.
Upload documents one at a time rather than in a batch. Verify that each document processed correctly by checking that it appears in the Project’s file list.
Step 3: Configure the custom instructions
What custom instructions are for
Custom instructions tell Claude how to behave in every conversation in the Project, without the team member specifying it each time. For an operations team, custom instructions specify:
- Which workflows to expect (what inputs trigger what outputs)
- What format to use for each output type
- What quality standards to apply
- What to always check before producing an output
The custom instruction format that produces consistent results
WHEN I PROVIDE: [description of the input the team member will paste or type]
PRODUCE: [description of the output format, structure, and quality standard]
ALWAYS: [specific rules that apply to every output in this Project]
NEVER: [specific things to avoid — banned words, incorrect formats, imprecise language]Example for a Customer Service Project:
WHEN I PROVIDE back-order exception data (customer name, order number,
product, original date, revised date, exception reason):
PRODUCE: a customer notification in the following format:
[Opening acknowledgment in tier-appropriate tone]
[Specific order details and revised timeline]
[What the company is doing to resolve the issue]
[Next contact point and timeline]
Calibrate the tone based on the customer tier specified.
If no tier is specified, use standard commercial tone.
ALWAYS: use the communication vocabulary from the Customer Communication
Standards document. Reference specific commitments with dates, not vague language.
NEVER: use passive voice for the apology.
Use "We delayed your order" not "Your order has been delayed."
Never promise a specific resolution before confirming with the operations manager.How long the custom instructions should be
| Project type | Recommended length |
|---|---|
| Single-function Project | 200 to 400 words |
| Multi-function Project | 400 to 600 words |
Long enough to specify the primary workflows clearly. Short enough that the instructions themselves do not consume a significant portion of the context window.
Verify the custom instruction character limit at docs.claude.com.
The test before going live
Before granting team member access to the workspace, run three test sessions as a team member would:
- Paste a typical input for the primary workflow. Does the output match the expected format and quality standard?
- Paste an atypical input (an edge case the team will encounter). Does the output handle it correctly?
- Paste an input that is slightly different from the typical format. Does the output still work, or does the workflow break?
Adjust the custom instructions based on what the test sessions reveal. The most common adjustment: the input format is too rigid, and the custom instruction assumes a specific input structure that the team does not always provide.
Step 4: Train the team on the workspace
The critical difference from general AI training
The blank session training teaches: how to describe your task to Claude, how to structure a prompt, how to evaluate what comes back.
The workspace training teaches: how to provide the specific inputs this Project’s workflows expect, how to evaluate the output against the Project’s quality standards, and when to update the AI system owner about output quality issues.
These are different skill sets.
The team member trained on blank sessions will revert to over-describing their task in the workspace, adding context that the workspace already has.
The team member trained on the workspace will under-describe in a blank session, providing inputs without the context that is not automatically loaded.
The workspace training session (20 to 25 minutes per person)
Minutes 1 to 3: Show the contrast
Show the team member the difference between the blank session output and the workspace output for the same input. Use a real example from the team’s actual work.
The blank session produces a generic output. The workspace produces a company-specific output. The visual contrast is the training’s most effective moment.
Minutes 4 to 8: Walk through the primary workflow
Walk through the primary workflow for this team member’s role:
- What inputs to provide
- Where to paste them in the Project
- What the output will look like
Use a real current task, not a training example.
Minutes 9 to 20: The team member runs the workflow
The team member runs the workflow on a real current task. The trainer watches and coaches the input structure only, not the AI operation generally.
Minutes 21 to 25: Cover two specific situations
- What to do when the output is not quite right (the specific input adjustment that usually helps)
- How to notify the AI system owner when something is consistently wrong: not “it doesn’t work” but “the X output is always missing Y, here is an example”
The workspace habit to build
Embed this specific behaviour: “When I need to do [workflow type], I open the [Project name] Project and provide [specific input type].”
This is more specific than “when I need AI help, I open Claude.” The specificity is what makes workspace adoption faster than general Claude adoption.
Step 5: Run the improvement loop
The weekly improvement loop (30 to 45 minutes per week for the AI system owner)
Review three to five conversations from the week’s Project history
Look for:
- Outputs that required significant editing (what was missing from the context or custom instructions?)
- Outputs that were excellent (what inputs and approach produced them?)
- Any workflow the team used differently from how it was intended (what does this reveal about how the custom instructions should be adjusted?)
Update one to two context documents or custom instructions
Based on the review findings.
The smallest useful update: adding a specific vocabulary term to the vocabulary guide that the team consistently had to add manually to AI outputs.
The most impactful update: refining a custom instruction to handle an edge case that consistently produced inadequate outputs.
Distribute the update to the team when relevant
If a context document or custom instruction update changes what inputs the team should provide or what outputs they should expect, a brief Slack message describing the change prevents the team from being confused by unexpected output changes.
The quality signal to watch
The editing time per workflow output should decrease over the first six months of operation as the improvement loop runs.
If the team is consistently spending the same amount of time editing outputs in month six as in month two, the improvement loop is not running. The AI system owner should identify which context documents or custom instructions need updating.
Common questions on building the shared workspace
”What if team members are in different time zones — does the shared workspace handle this?”
Yes. The shared Project context (uploaded documents, custom instructions, accessible conversation history) is available to all team members with Project access regardless of time zone.
There is no synchronous session requirement. A team member in Sydney and a team member in Chicago can both access the Operations Project and run workflows independently.
”How do we handle a Project whose context is confidential to certain team members?”
Create a restricted-access Project for the sensitive function. Do not include the sensitive context in the shared organisation-wide Project.
Claude Projects on Team plans support both public (organisation-wide) and private (specific-access) Projects. The AI system owner manages access configuration from the admin console.
”What if the custom instructions conflict with the uploaded documents?”
Custom instructions take precedence over uploaded document content in most cases. If a custom instruction says “never use passive voice” but an uploaded document contains passive voice examples, the instruction governs.
For this reason: review the uploaded context documents and custom instructions together before going live, specifically looking for any contradictions.
”How do we know when the context documents are outdated?”
The signal is quality degradation: the team is consistently editing specific elements out of AI outputs that used to be correct. This indicates the uploaded context no longer reflects current practice.
The AI system owner’s monthly review of each Project’s context documents is the systematic mechanism for catching this before it becomes a widespread problem.
Want the five-step workspace build completed for your operations team?
Building a shared Claude workspace for an operations team is a five-step process: create the Project structure, upload the Phase 1 Foundation documents, configure the custom instructions, train the team on the workspace, and run the improvement loop.
The workspace that is built and maintained correctly produces outputs that are measurably more operationally specific than blank session outputs from the same team on the same tasks. The workspace that is built and not maintained stagnates at the initial build quality. The difference is the AI system owner and the improvement loop.
Path one: start with Step 1 this week. Create one Project for your most AI-active function. Name it clearly. Set the access level. You will have the structure in place in under 30 minutes, and you can begin uploading context documents the same day.
Path two: bring in a partner. Phos AI Labs runs the five-step workspace build sprint: Projects configured, context documents uploaded, custom instructions tested, and team trained within two weeks. Thirty minutes, no deck. Start here.
Related articles