We bought Claude seats and nobody uses it. What now?

Why the announcement did not change anything

The first thing worth accepting is that buying seats did not ask anyone to work differently. An announcement adds an option. It does not remove the path people are already on, and that path has a property Claude does not have yet: they know exactly how long it takes and exactly what the output looks like when they are done. Choosing the new thing means paying a real switching cost this afternoon against a payoff they cannot size. Most people, most weeks, decline that trade. That is not resistance to change. It is an accurate read of the incentives you handed them.

Anthropic says roughly the same thing in its own adoption material. The opening line of its Claude Code champion kit is that adoption of a new tool rarely happens because of a rollout announcement, and that it happens when someone on the team starts using the tool well, talks about it openly, and makes it easy for others to follow. The kit also names the objection you are probably already hearing, which is that people believe they are faster without it. Anthropic's answer is that this is likely true for the work a person does routinely, and that the gain sits in the work they tend to avoid: unfamiliar material, legacy detail, the tedious task they keep postponing.

Here is a ten minute test. Ask three people what they were supposed to stop doing when the seats arrived. If none of them can name a thing, you did not roll out a change, you announced availability. Availability is a far weaker instruction than it feels like when you send it, because it moves the work of designing the change onto the person least equipped to design it and least rewarded for trying.

A blank chat box is a worse starting point than a form

A form tells you what it wants. It has labels, it has a submit button, and it fails loudly when you get something wrong. A chat box asks you to invent the task, phrase it yourself, and then judge the result with no signal about whether you asked a good question or a bad one. That is a genuinely harder interface, and the difficulty lands hardest on the people with the least slack in their week and the least appetite for looking foolish inside a tool their employer can see.

Which is why the useful fix is almost never more encouragement. It is putting something in front of the blank box. On Team and Enterprise plans a Project is a self contained workspace with its own instructions and its own knowledge base, and it can be shared with named colleagues by email, with a group, or with the whole organization, at either view or edit permission. Somebody opening a shared Project is not staring at nothing. They are inside a scoped space that already carries the format, the tone, and the reference documents.

Skills go a step further, because they encode a repeatable workflow rather than a workspace. Anthropic documents organization wide skill management as available on both Team and Enterprise: an owner uploads a zip containing a SKILL.md file under Organization settings and Skills, and it is provisioned to everyone immediately and enabled by default, though members can toggle it off. To give a skill to one department only, the documented route is to bundle skills into a plugin and assign that plugin to a group. Two cautions from that same article are worth reading before you conclude nobody wanted them. Skills require code execution, so if Code execution and file creation is toggled off, skills do not function at all. And organization wide sharing between members has no approval step, so if you enable it, any member can publish a skill to the directory without review.

Enterprise admins have one more surface worth knowing about. Org Preferences inject standing guidance into every conversation across the organization, and Anthropic's stated reason for recommending it is exactly the point of this section: the guidance shows up in the product at the moment of use rather than in documentation users have to go find.

The difference between a found use and an assigned tool

There are two populations in every rollout and they behave nothing alike. Someone who found a use arrived with a problem, got a result that beat their previous method, and now comes back without being asked. Someone who was assigned a tool arrived with an instruction, produced something defensible, and has no particular reason to return. Both appear in a first week usage report. Only one of them is still there in week six, which is why first week numbers reliably overstate how well a rollout is going.

Anthropic's champion kit is organized around that distinction, and its success signals are the ones I would borrow. The week three signal is repeat usage, described as the same colleagues returning rather than trying once and stopping. The week four signal is questions in the shared channel being answered by people other than the champion. Neither one is a count of who logged in. Both measure whether use survived after the push stopped.

Two honest caveats about that kit. It is written for Claude Code and for engineers, and I have not found an equivalent published kit in Anthropic's Help Center for a chat, Projects, or Cowork rollout, so translating it to a finance team or a client services team is work you will be doing yourself. The kit also warns that adoption which depends on a single person is fragile, which happens to be the failure mode of naming one enthusiastic champion and treating that as a program.

The practical move is to stop recruiting and start looking. Somebody in your organization is already using this without being told to. Your analytics reports top members by chats, top members by project usage, and top users by artifacts generated. That list is your starting team, and it beats volunteers, because those people have already paid the learning cost you are trying to get everyone else to pay.

Diagnose it before you do anything else

Low usage has a small number of real causes and the recovery for each is different, so guessing is expensive. Anthropic's Enterprise consumption guide tells admins to review individual usage monthly and to treat users consuming very little as people who may not be activated yet. That is the right instinct. The work is figuring out which kind of not activated you actually have.

The Analytics page is the fastest read available to you. Anthropic documents it as available to Team plan Owners and Primary Owners, and to Enterprise Owners, Primary Owners, and Admins, with Enterprise Admins able to see everything except Spend. It reports active members against assigned seats, an adoption level, product stickiness, the percentage of users with one or more chat, the percentage of users with one or more project, per skill uses and cost per use, and connector usage including read and write counts.

One warning about that dashboard. It also reports estimated time saved, and the Claude Code view reports estimated productivity lift and annual time recovered. Anthropic is straightforward that every formula on that Value tab is shown inline and that you can adjust the inputs to match your organization's assumptions. Those figures are therefore a model you configured, not a measurement of what happened. Do not carry them into a budget conversation as evidence. Use the plain counts, which are harder to argue with.

There is also a place where Anthropic's own pages do not line up, and it matters if you are trying to compare notes with a peer. The Enterprise consumption guide describes the Analytics page as showing total spend month to date, quarter to date and year to date, spend by model, and a top ten users by spend leaderboard, with no conditions attached. The analytics support article adds a condition the consumption guide does not mention: on a seat based Enterprise plan, spend reports appear only if the organization has enabled usage credits, and that data covers overage spend only rather than usage inside the seat allotment. The same article is titled for Team and Enterprise plans without stating which panels are Enterprise only, while the Enterprise plan article lists the Analytics API as an Enterprise addition. Read all three against your own plan type instead of assuming the dashboard someone showed you is the one you have.

• ·No named workflow: nobody can tell you which recurring deliverable was supposed to change. Test by asking three people what they stopped doing. The fix is to pick one artifact, not one category of work.
• ·No owner: the rollout belongs to whoever signed the invoice, and nobody's performance review depends on an outcome it produces. Test by naming the single person whose next review is affected. If you cannot name them, that is your cause.
• ·Access was never actually granted: the surface you think someone has is switched off for their group or their role. Test by sitting with one person and watching them open it. Anthropic explicitly recommends gating higher intensity surfaces such as Claude Code and Cowork by group and rolling them out in waves, so someone genuinely may not have what you assume they have.
• ·Unclear data rules: usage is near zero and you have received no questions and no policy incidents. Silence in both directions at once is the tell, and it is covered in the next section.
• ·Genuine poor fit: the person tried it more than once, on real work, and their honest report is that their job is mostly physical, mostly a regulated live interaction, or mostly one system of record with almost no writing in it. Test by asking them to describe a task they did try. A person with a bad fit can describe one. A person who never started cannot.

Unclear data rules produce silence, not questions

This cause hides better than the others because it generates no complaints. Put yourself in the seat of a billing coordinator with a real question about whether a client's name can go into the box. Asking makes her the person who wanted to put client data into the AI. Not asking costs her nothing today. So she does not use it and she does not ask, and your compliance dashboard shows zero incidents while your usage dashboard shows zero usage. Both of those look like the system working.

The fix is a short published list rather than a policy document. These categories are fine, these are not, this is the person you ask when you are unsure, and here is what happens to what you type. The last item is the one most rollouts skip, and it is the one people are actually wondering about.

You can be concrete there, because Anthropic is. For its commercial products, which include Claude for Work, Anthropic states that by default it will not use your inputs or outputs to train its models. The documented exception matters for a rollout: if someone uses the thumbs up or thumbs down button, Anthropic stores the entire related conversation in its back end for up to five years, and a Primary Owner or Owner can disable that for the whole organization with the Rate chats setting under Organization settings and Data and privacy. Saying that plainly to staff removes the most common unspoken objection, and any employee can check it against Anthropic's page rather than taking your word for it.

Two things to keep straight. That commercial default does not apply to a personal Free, Pro, or Max login, which falls under Anthropic's separate consumer article and under that individual's own model improvement setting. So if the stall has quietly pushed people into personal accounts in order to get work done, you no longer have an adoption problem. You have work happening outside your agreements, and that is the thing to find first.

The recovery sequence, and when to stop

Do not relaunch. A second announcement carries less weight than the first and confirms to everyone that the first one did not work. Start much smaller than feels proportionate to what you spent.

If nobody was ever actually taught anything, close that gap before drawing any conclusions about fit. Anthropic Academy publishes courses covering AI Fluency, Claude Code, and an introduction to Cowork, along with a Claude for work track, and it issues certificates on completion. An hour of structured instruction is a smaller intervention than anything else on this page, and it removes a cause you would otherwise misread as disinterest.

Now the part most vendors will not say out loud. Some roles do not have work Claude improves. A scheduler who lives inside one system of record all day, a field technician, a receptionist whose job is being present at a desk: these people can be given a seat, trained properly, handed a named workflow, and still correctly conclude there is nothing here for them. That is a finding, not a failure. Writing it down is worth more than another push, because it protects the credibility of the workflows that did land.

Then reclaim the seat, and know what that actually saves, because the two plans work differently. On the Team plan you pay per seat whether or not it gets used, and Anthropic documents Team as requiring a minimum of two members and supporting up to 150 seats before you have to move to Enterprise. An idle Team seat is straightforward waste you can remove. On the current usage based Enterprise plan, Anthropic states that the seat fee covers access only, that all usage across Claude, Claude Code, and Cowork is billed separately at standard API rates, and that there is no included token allowance, so an unused seat costs you its access fee against almost no consumption. Enterprise has seat minimums of 20 self serve and 50 sales assisted, which is worth checking before you cut deeply. Some organizations are still on older Enterprise seat types, which Anthropic says will not continue past the next contract renewal. All of this moves, so confirm the current numbers on Anthropic's live pricing page before you build a business case on them.

• ·Pick one recurring deliverable with a name and a cadence: the Monday pipeline summary, the monthly client report, the intake packet for a new account. Not a department and not a use case. One artifact somebody produces on a schedule.
• ·Give it one owner whose actual job includes shipping that artifact. Not IT, and not the person who bought the seats.
• ·Have that owner produce it with Claude for three cycles themselves before anyone else is involved. If it has not beaten the current method by the third cycle, you learned something cheaply. Stop and pick a different deliverable.
• ·Encode what worked so the next person is not facing a blank box: a shared Project carrying the instructions and reference documents, or a skill provisioned to that group. Anthropic's own guidance is to test a skill on your own account before provisioning it to anyone.
• ·Add two more people from the same team, and have the owner answer their questions somewhere other people can read the answer.
• ·Check whether it landed rather than whether it installed. Anthropic's Analytics API can break skill, plugin, and connector usage down per user, and Anthropic frames that capability in exactly these terms: confirming a plugin rollout actually landed with the team it was distributed to, rather than just checking that it was installed.
• ·Budget a month or two per workflow. Anthropic's champion kit is a thirty day playbook, and its Enterprise AI Transformation Guide page describes choosing pilots that demonstrate value in thirty to sixty days and measuring across adoption, efficiency, quality, and satisfaction. Plan against that, not against a week.

What people ask next

• Will Claude pass our IT security review?
• Should I hire someone to implement Claude, or do it ourselves?
• How do I roll out Claude to my whole team?
• What is the difference between Claude Team and Enterprise?

Worked examples