How do I roll out Claude to my whole team?

Buying seats is not a rollout

The most common version of this goes like so. Leadership decides Claude is worth trying, buys a block of seats, sends an announcement with a link and maybe a lunch and learn, then opens the usage dashboard six weeks later. A handful of people are active daily. Most logged in once. Nobody can name a process that changed. The licenses renew or they do not, and either way the organization learned nothing it can act on.

The reason is not that people are resistant. It is that a seat is capability without assignment. Handing someone a login is like putting a new piece of equipment in the break room with no instruction about which job it replaces. The people most likely to work it out unaided are the ones with slack in their week, and in a company of 50 to 800 doing service delivery, almost nobody has slack in their week.

The billing mechanics quietly reward the wrong behavior here. On Team plans a pending invitation occupies a seat the moment you send it, whether or not the person ever accepts, and invitations expire after 21 days. So you can be paying for a fully allocated plan where a real share of the seats belong to people who never signed in. Removing a member frees that seat for reassignment but does not reduce your total seat count or your bill; reducing the allocation is a separate deliberate step in organization settings.

So the first decision is not how many seats to buy. It is which specific piece of work you are trying to change.

• ·Seats were sized to headcount rather than to a named piece of recurring work
• ·The launch artifact was an announcement or a link, not a worked example built on your own documents
• ·There is no named owner, or the owner is a committee, or the owner is the phrase it is on IT
• ·No standardized prompts, projects, or skills, so every person reinvents the same instructions badly
• ·Success is being measured in logins and message counts rather than in a deliverable that visibly changed
• ·Six weeks in, the person who can best describe the value is the executive who approved the spend, not anyone doing the work

Start from one named workflow, not a tool announcement

A workflow, for this purpose, is a specific recurring deliverable with a named owner, a known input, and a known cadence. Not marketing. Not use AI for documentation. Something like the monthly client status report the account coordinator assembles from the project tracker and last month's version, due the third business day. Or the intake summary the scheduler writes after every new patient call. Or the past performance section the proposal lead rewrites for each bid.

Naming it that precisely buys you three things a tool announcement cannot. It tells you exactly who the first users are. It tells you what a good result looks like, because the deliverable already exists and there are twenty prior versions to compare against. And it gives you a before, which is the only thing that makes a thirty-day test mean anything.

The launch itself is not training. It is sitting down with the two or three people who own that deliverable, doing it once together in Claude with real inputs from your business, and keeping whatever prompt and project setup produced the version they would actually send. That artifact, the one that worked on your documents and your formats, is what gets distributed. A link is not an artifact.

Expect the first attempt to come back mostly right and wrong in a way that matters. That is the useful part. The corrections made in that room are the content of the standard prompt, and they are almost always things no generic tutorial could have supplied, because they are about your clients, your templates, and your internal vocabulary.

Pick a first team where the work is repetitive and written

Two properties matter more than enthusiasm. The work has to be repetitive, meaning the same shape of task recurs weekly or more often, and it has to be written, meaning the output is text or a document rather than a physical act or a live conversation. Repetition gives you enough attempts inside thirty days for a habit to form or visibly fail to form. Written means Claude can produce the actual deliverable instead of advice about the deliverable.

In a service business those two properties tend to point at the same handful of functions regardless of industry.

• ·Client reporting and account updates: recurring, templated, assembled from sources you already hold
• ·Proposals, bids, and RFP responses: heavy reuse of prior language, always against a deadline
• ·Intake, triage, and call summaries: high volume, short, formulaic, and painful to write at the end of a long day
• ·Internal SOPs and documentation: written once, permanently out of date, and nobody's actual job
• ·Recruiting and onboarding material: job descriptions, screening questions, first week plans, repeated per role
• ·Billing and collections correspondence: the same six letters, varied by circumstance

What to standardize centrally, and what to leave alone

The instinct is to standardize everything or nothing. Both fail. Standardize the places where variation costs you something real, and leave the rest to individuals, because that is where your next workflow comes from.

Worth standardizing centrally: the prompt and instructions for each named workflow, so the monthly report is not assembled six different ways by six people. Shared projects holding the reference material for that workflow, which on Team and Enterprise plans can be shared with specific members or the whole organization at view or edit permission. Organization skills, which an Owner uploads once in organization settings and which then appear for everyone, enabled by default, with members free to switch an individual one off; when a skill is only relevant to one team, Anthropic's guidance is to bundle it into a plugin and assign that plugin to a group rather than pushing it to everyone. The list of what must not be pasted, written in your own nouns rather than as an abstract policy. And which connectors and capabilities are on at all, which is an Owner or Primary Owner decision, not a member one.

Worth leaving alone: personal prompts and personal projects, how someone likes to phrase a request, whether they work in the web app or the desktop app or an Office add-in, and experimentation on their own work. Policing that produces resentment and tells you nothing.

One governance detail to read before you switch sharing on. Organization-wide skill sharing has no approval step. Anthropic states plainly that if you enable Share with organization, any member can publish a skill to the organization directory without review, and that the audit log records the share event but not the contents of the skill, with no admin dashboard for inspecting what members shared with each other. If you want review, keep organization-wide sharing off and have members submit skills to an Owner to provision instead. That is a real policy choice and an easy one to enable by accident.

Also worth internalizing: a default is not the same as ready. The Ask Your Org enterprise search project is enabled by default for Team and Enterprise organizations, but an Owner has to complete setup before any member can use it, and then each user has to authenticate their own connectors before results are complete. Several other capabilities can only be enabled by an Owner or Primary Owner. Somebody has to actually sit in the admin settings for an hour, and that hour should be on a calendar with a name against it.

Team or Enterprise for a rollout this size

Both plans can host a rollout at 50 to 800 people, and the deciding factor is usually identity and audit rather than anything you see in the chat window. Anthropic describes Enterprise as everything in the Team plan plus additional security and compliance features.

One correction before the feature list, because it changes the math more than anything else here: a seat cap is not a headcount cap. At 50 to 800 staff you are not buying a seat for everyone. Seats go to the roles whose work is written, which is usually the back office: operations, administration, billing, intake, scheduling, marketing, and client communications. Field crews, clinical staff on the floor, drivers, technicians, and hourly floor staff typically get none, because nothing in their day is a writing task. A four hundred person company can sit well inside Team on forty seats. So Team supports up to 150 seats, and above that number of licensed seats the choice is made for you, but for most companies this size the decision is driven by identity and audit requirements rather than by how many people work there.

The differences that actually bite: Team includes single sign-on with just-in-time provisioning and domain capture, but SCIM directory sync, the thing that actually deprovisions someone the day they leave, is an Enterprise feature. Audit logs, custom data retention controls, the Compliance API, the Analytics API, customer-managed encryption keys, US-only inference, and custom roles scoped to groups are Enterprise. Usage analytics exist on both, but on Team plans only Owners and Primary Owners can see them, while Enterprise also grants Admins access to everything except spend.

Billing works differently in a way that changes how you budget. Team is per seat per month in two tiers, Standard and Premium, with usage limits included in the seat, per member rather than pooled, resetting weekly, plus an option to purchase usage credits so people can keep working past their included limit. On Anthropic's Team plan article at the time of writing, Standard is listed at 25 dollars per member per month billed monthly or 20 billed annually, and Premium at 125 monthly or 100 annually, for US customers before tax. On the current usage-based Enterprise plan the seat fee covers access only: Anthropic states there are no per-seat usage limits and no included token allowance, and that every token consumed in Chat, Claude Code, or Cowork is billed separately at standard API rates, with admins able to set spend limits at the organization and individual user level. Enterprise carries seat minimums, 20 for self-serve and 50 for sales-assisted. Anthropic notes prices and plans are subject to change at its discretion, so confirm all of it on the live pricing page before you build a budget on it.

If you think you will move from Team to Enterprise later, plan the cutover rather than discovering it. Anthropic recommends upgrading the existing organization rather than creating a new one, because that preserves chat history, projects, and memberships and roles, and it states the self-serve Team to Enterprise path is not reversible. Several capabilities that are on by default on Team are off by default on Enterprise, including skills and skill creation and sharing, code execution and file creation, interactive content in artifacts, Claude Design, and Claude in Chrome. The underlying content is retained and comes back when an admin re-enables the capability, but on cutover morning it will look to your users like features vanished. Some users can also land in a No seat assigned state and have no access until an admin corrects it, and Anthropic advises checking your highest-usage members first. One more trap from the same article: if the organization-level spend limit is reached, every user loses access immediately until it is raised or the month turns over.

One place Anthropic's own documentation disagrees with itself, and it matters for who you hand which role. The roles and permissions article lists Provision new seats as a Primary Owner permission with the Owner column blank, while the article on purchasing and managing seats on Team plans says only Owners and Primary Owners can purchase seats and walks through the steps under the instruction to log in with your Owner or Primary Owner account. Both pages are live. Plan for the narrower reading, meaning make sure your Primary Owner is a reachable human or a service account somebody actually controls, and verify the behavior in your own organization before you build a month-end process that assumes an Owner can add seats.

Who owns it after launch, and how to tell in thirty days

The answer cannot be nobody, and in practice it is on IT is a version of nobody. IT can own identity, provisioning, capability toggles, and the audit posture, and it should. What IT cannot own is whether the monthly client report now starts from a draft, because IT does not write that report and has no standing to change how it gets written.

Ownership needs to sit with someone who has three things: standing inside the function where the workflow lives, enough time carved out to be interrupted about it, and the authority to change the standard prompt when it turns out to be wrong. At this size that is usually an operations manager or a respected senior individual contributor on the pilot team, with an executive sponsor who is accountable for the outcome but is not the owner. Write down both names. If you cannot fill in the first name, you do not have a rollout, you have a purchase.

For the thirty-day read, be deliberate about which evidence you trust. Anthropic's admin analytics give you genuinely observable numbers: weekly active members, active members against assigned seats, percentage of users with one or more chat, percentage of users with one or more project, each project listed with the users, conversations, and messages attached to it, and top members by chats and by project use. Those answer whether people showed up and whether the work is landing in projects, which is where repeated work lives.

The same dashboard also reports Estimated time saved, and for Claude Code an Estimated productivity lift and Time recovered. Read those for exactly what they are. Anthropic shows every formula on the Value tab inline and lets you adjust the inputs to match your organization's assumptions, which means the output is a model built on numbers you supplied. That can be fine for a budget conversation. It is not evidence that the rollout worked, and presenting it as such is how a rollout gets defended for two quarters after it stopped mattering.

The test worth running is smaller and much harder to fake. Take the single recurring deliverable you chose in week one and ask whether it now starts from a draft rather than a blank page, in every recent instance, produced by the person whose job it is, without the pilot owner in the room. Look at the last four instances. That is a yes or a no.

• ·Working: the named deliverable started from a draft in every recent instance, and the person doing it can describe specifically what they changed
• ·Working: the standard prompt or shared project has been edited by someone other than its author, because it was wrong in a particular way and they fixed it
• ·Working: a second workflow has been requested by someone you did not ask, usually adjacent to the first
• ·Working: the share of pilot-team members with one or more project is rising, not just the chat count
• ·Stalling: activity is concentrated in two or three enthusiasts and flat everywhere else
• ·Stalling: usage exists but no deliverable has changed, which usually means people are asking general questions rather than doing their actual work in it
• ·Stalling: nobody has edited the standard prompt, which means nobody is relying on it
• ·Stalling: the owner has not been interrupted about it in two weeks

What people ask next

• What is the difference between Claude Team and Enterprise?
• How much does Claude cost for a team?
• Will Claude pass our IT security review?
• We already have Microsoft Copilot. Why would we add Claude?

Worked examples