Setting up Claude for a business: the full stack

A working Claude installation is a stack of small configurations, not one clever prompt. Organisation-level instructions carry company context and boundaries into every conversation; each user's individual instructions carry their role and output preferences; projects hold workflow context and approved documents; skills capture repeatable procedures; connectors bring live data in under existing permissions; and governance rules plus structured first weeks make the whole thing stick. Each layer answers a different question, and each has a different owner. Firms that configure only the top layer get a chatbot that impresses in week one and drifts by week six. Firms that build the stack get something closer to a reliable colleague.

This guide is for the managing director, operations lead or internal champion rolling Claude out beyond a single enthusiast. It describes what belongs at each layer and who should own it. Product capabilities are taken from Anthropic's current Help Center documentation, accessed July 2026 and listed under Sources; for the decision of which plan to buy in the first place, start with our guide to rolling out ChatGPT or Claude in a UK SME.

Why is setting up Claude more than writing one prompt?

Because the product gives a business several distinct places to put configuration, and each is built for a different kind of context. A single mega-prompt pasted into every chat mixes durable company facts, personal preferences and one-off workflow steps into a blob nobody maintains: it decays as it is copied between staff, disagrees with itself within a month, and leaves with the person who wrote it. The stack separates concerns, which is what makes an installation survive staff churn, audits and growth.

Layer	What it holds	Who sets it	What goes wrong without it
Organisation instructions	Company identity, tone, formatting standards, data-handling reminders, applied to every conversation	Admins and above (Team and Enterprise plans)	Every user reinvents the basics; output is inconsistent across the firm
Individual user instructions	Each person's role, outputs and format preferences	Each user	Claude answers a finance manager and an apprentice identically
Projects	One workflow's context: instructions, chat history and an approved knowledge base	The workflow owner; shareable on Team and Enterprise	Context re-pasted into every chat; documents scattered and unapproved
Skills	Repeatable procedures that load when relevant and work everywhere	Users, or provisioned org-wide by owners	The same checklist pasted into chats forever, with drift each time
Connectors	Controlled access to live systems such as email, files and calendars	Admins, under IT sign-off	Copy-paste of stale data, or worse, uncontrolled access
Governance	Data classification, human sign-off rules, acceptable use	Leadership, recorded in policy	Sensitive data in the wrong place and nobody accountable
Training and adoption	Structured first weeks against each person's real work	The rollout owner	Licences paid for, tool unused by month two

The rest of this guide walks the stack top to bottom. None of it requires technical skill; all of it requires deciding who owns what, and writing those ownership decisions down where the next person can find them.

What belongs at the organisation level?

Company-wide facts and rules that should apply to every conversation: who the firm is, the house tone, formatting standards, and standing data-handling reminders. On Team and Enterprise plans these live in organisation instructions, which Admins, Owners and Primary Owners can set for the whole workspace. Anthropic's documentation gives them a 3,000 character maximum, notes that changes can take up to an hour to propagate, and states that where organisation and individual instructions conflict, the organisation instruction wins; individual instructions still apply for anything the organisation level does not address. They cannot override Claude's built-in safety behaviours.

The discipline that matters here is separation. Stable facts about the firm belong at this level; procedures do not (they belong in skills), and reference documents do not (they belong in project knowledge bases). A good organisation instruction is short, specific and testable: state the firm's name and sector, require UK English, set formatting defaults, and include one or two standing reminders such as keeping client identifiers out of generated documents. A poor one is a page of aspirations that reads like a values statement. Anthropic's own guidance is blunt on this point: concise and specific beats lengthy and vague, and instructions should be tested in a fresh conversation after saving.

Treat the organisation instruction as a maintained document with an owner, not a set-and-forget field. Give it a named owner (usually whoever owns the rollout), a review date, and a change habit: when the firm renames a product, enters a new sector or changes a policy the instruction references, the instruction changes the same week. Because only Admins and above can see or edit it, it also pays to publish the current wording somewhere staff can read it; people write better personal instructions when they know what the organisation layer already covers.

How should each user's profile be set up?

Each person's individual instructions should tell Claude three things: who they are professionally, what work products they produce, and how they want output structured. A finance lead might specify that figures are never to be estimated and that summaries take a table-first format; a client-facing manager might specify email drafting in the firm's tone with a plain-English reading level. Preferences about length, bullet points versus prose, and UK date and currency formats all belong here, as does the person's own reminder of what they must not paste in.

Two principles keep this layer useful. First, it complements rather than repeats the organisation level: the interaction model means anything the organisation instructions already cover is settled, so the personal layer should add role context, not restate house rules. Second, it should name behaviour for missing information: a sentence like "if information is missing, say what is missing rather than guessing" changes the character of everything Claude produces for that person. Writing good instructions is a learnable skill, and our guide to prompt engineering for UK business teams covers the technique in more depth.

When should work live in a Claude Project?

When a workflow has its own recurring context: reference documents, a consistent output, and history worth keeping together. Projects are self-contained workspaces with their own chat histories and knowledge bases, plus project-level instructions that tailor Claude's behaviour inside them. On paid plans the knowledge base scales through retrieval augmented generation when it outgrows the context window, and on Team and Enterprise plans projects can be shared with named colleagues or the whole organisation, with "can use" and "can edit" permission levels separating consumers of a workflow from its maintainers.

The working rule is one project per distinct workflow, named in the team's own language: "Monthly board reporting", "Tender responses", "Complaint handling". Projects named "General", "AI experiments" or "Team stuff" are a sign the workflow was never defined, and they collect exactly the unstructured mess the stack exists to prevent. The knowledge base carries its own discipline: only documents someone has approved for AI use go in, which is a governance decision (below), not a technical one. Hygiene matters as much as approval. A knowledge base with last year's price list or a superseded policy is worse than an empty one, because Claude will use what it is given with complete confidence. The workable habit is to name a document owner per project, date-stamp what goes in, and sweep each knowledge base whenever the underlying material changes, removing superseded versions rather than adding new ones alongside them. For firms whose main ambition is asking questions of their own document estate, our guide to Claude for internal knowledge management covers that workflow end to end.

Where do Skills and connectors fit?

Skills hold procedures; connectors hold access. A skill is a folder of instructions and resources that Claude loads dynamically when a task calls for it: Anthropic's documentation draws the distinction cleanly, with projects providing "static background knowledge that's always loaded" in their workspace while skills provide "specialized procedures that activate dynamically" and work everywhere. Skills are available on every plan (they require code execution to be enabled), and on Team and Enterprise plans an owner can provision an approved skill to every member centrally, so a firm can distribute its house method for, say, meeting notes or proposal formatting once rather than per person. The moment a team notices the same checklist being pasted into chats for the third time, that checklist is a skill candidate; the fuller build-or-not decision is covered in our guide to when to build a Claude Skill.

Connectors are the live-data layer, linking Claude to systems such as Google Workspace, Microsoft 365, Slack and GitHub so it can retrieve context without copy-paste, and the Model Context Protocol extends this to other business systems. Anthropic's comparison is again useful: MCP connects Claude to external services, while skills teach it how to use them. The governance posture matters more than the plumbing: connect only systems the business has confirmed, under IT sign-off, respecting existing permissions, and prefer read-only access where the connector offers it. In practice that means starting with retrieval, letting Claude read calendars, files and mail threads to build briefings and drafts, and treating anything that writes to a live system as a separate, later decision with its own approval. It also means teaching staff one habit early: information a connector returns is input to be checked against the source, not a fact to be forwarded. We cover the connector landscape in our MCP guide for UK leaders.

What governance and training make the setup stick?

Four things, and none of them is software. First, a data classification staff can actually remember, deciding which kinds of information may enter which layer of the stack; the ICO's accountability principle expects organisations to be able to demonstrate this kind of by-design thinking under UK GDPR, and our guide to whether Claude is GDPR compliant covers the retention and training settings behind it. Second, named human sign-off for anything regulated, client-facing or financial: Claude drafts, a named person approves. Third, a short acceptable-use policy so the rules survive beyond the rollout meeting; our AI acceptable use policy guide includes the one-page format. Fourth, structured first weeks: each person trained on their own workflows rather than generic demonstrations, completing one genuine piece of their own work in the first session, with blockers collected and fixed while attention is still high, and usage reviewed honestly after a month. Unused projects tell you where the workflow was misunderstood; heavily used ones tell you where the next skill is worth building. The National Cyber Security Centre's guidance on AI and cyber security makes the same point from the security side: managing AI risk is as much about organisational culture, process and communication as it is about technical measures.

Set up in this order, the stack also becomes auditable: a reviewer can see what the organisation instructs, what each project knows, which procedures are provisioned, and which systems are connected. That is what turns "we use AI" into an answer a client, insurer or regulator will accept.

The AI Consultancy is an Anthropic Consulting Partner and builds this stack as its standard Claude deployment for UK organisations, from organisation instructions through projects, skills and connector governance to the adoption weeks that follow. If you would rather not derive the layers yourself, our Claude consulting and Claude implementation services exist for exactly this, and the Knowledge Hub training section collects the supporting guides.

Sources

• Claude Help Center, "Set organization instructions", accessed July 2026 (Team and Enterprise availability, Admin-and-above roles, every-conversation scope, 3,000 character maximum, propagation time, precedence over individual instructions, safety non-override, best practices).
• Claude Help Center, "What are projects?", accessed July 2026 (self-contained workspaces, knowledge bases, project instructions, RAG scaling on paid plans, Team and Enterprise sharing and permission levels).
• Claude Help Center, "What are skills?", accessed July 2026 (dynamic loading, plan availability, code execution requirement, organisation-provisioned skills, the projects-versus-skills and MCP-versus-skills distinctions).
• Claude Help Center, "Provision and manage skills for your organization", accessed July 2026 (owner provisioning to all members on Team and Enterprise plans).
• Information Commissioner's Office, accountability principle and data protection by design guidance under UK GDPR, accessed July 2026.
• National Cyber Security Centre, "AI and cyber security: what you need to know", accessed July 2026.