I once rolled Claude out to a sales team with an all-hands demo, a Project loaded with our positioning, and a pre-call brief prompt I was genuinely proud of. Sixty percent of the team signed up that week. By week four, three people were still using it, and one of them was me. The usage view was the first honest conversation I had about that rollout, and it was not flattering.
The prompt was fine. The plumbing was the problem: to run the brief, a rep had to export the account from HubSpot, paste it in, and copy the result back into the calendar note. I had built a tool and asked reps to be its courier. This is the playbook I wish I had run instead: one play, a pilot cohort, the data wired so nobody carries anything, and metrics that measure work rather than logins.
Rollouts die at the desk, not in the deck
Every failed AI rollout I have seen, mine included, had a great deck. The demo works because the person demoing built the thing and knows where the bodies are. The desk is different. At the desk it is 8:52, the call is at 9:00, the CRM is open, and the rep does whatever costs the fewest clicks. I call the distance between those two moments the deck-to-desk gap, and it is where adoption goes to die.
Sales teams are also uniquely good at routing around process. Reps are paid on outcomes and measured weekly, so anything that adds friction without a same-day payoff gets quietly dropped, no matter how good the kickoff felt. I built the required fields nobody filled and the stage definitions nobody honored; Claude is just the latest thing that can join that pile if you launch it like a tool instead of running it like a change.
The reframe that fixes most of it: you are not rolling out Claude. You are changing how a specific piece of work gets done by specific people, and Claude happens to be the engine. Change management has a boring, well-known shape. Pilot, prove, expand. The rest of this guide is that shape, applied to a sales floor.
TipBefore you announce anything, sit next to one rep at 8:52 and watch them prep a call. Whatever they actually do in those eight minutes is the workflow you are changing. The deck is fiction until it survives that.
Roll out a play, never a tool
A tool is a login. A play is a piece of work with a shape: a trigger (a call lands on the calendar), an input (the account URL and the CRM record), an engine (a skill or a Project prompt), an output (a one-screen brief), and a destination (the calendar note, a Slack thread, a CRM field). When I write those five lines down for a play, I call it the play card, and the play card is the unit of rollout. If you cannot fill in all five lines, you do not have a play yet, you have a hope.
Pick the first play by pain and by frequency. Pre-call research is my default: every rep does it, most do it badly under time pressure, and the output is judged in the next thirty minutes, so the payoff is same-day. Post-call follow-up is the other strong candidate. Avoid anything where the value shows up in a quarter (forecasting, territory planning); reps will not carry a habit for ninety days on faith.
One play also gives you a clean measurement. Ten reps running one play produce a number you can compare against the week before. Ten reps each doing their own thing with a chatbot produce anecdotes. Anecdotes are how the second all-hands gets booked and the budget gets cut.
- Trigger: the moment in the rep's day that starts the play (a meeting appears on the calendar).
- Input: what the engine needs, and where it lives (account URL, the HubSpot record, the last call transcript).
- Engine: the skill or Project prompt that does the work, versioned and owned by one person.
- Output: the exact artifact the rep gets (a brief under 300 words, three talking points, one risk).
- Destination: where it lands so nobody copies anything (the calendar note, a Slack DM, a CRM field).
Pick the pilot cohort like you mean it
Five to eight reps and one frontline manager, for three weeks. Small enough that you can sit with every one of them, big enough that one person's vacation does not zero out your data. The manager matters more than any rep: if the manager asks to see the brief in the 1:1, the brief gets made. If the manager never mentions it, the brief stops being made by Thursday.
Put a skeptic in on purpose. Volunteers are lovely and they lie to you, kindly, because they want the thing to work. The rep who thinks this is a fad will tell you within a day that the brief is too long, that the connector missed the custom deal stage, that step three takes four clicks. That is the feedback that survives the rollout to the other forty people. (My skeptic was also the first person to ask for a second play. I have stopped predicting who converts.)
Set the pilot up as an experiment with an end date and a decision at the end: expand, fix and rerun, or kill. Saying the word kill out loud at the start is what makes the cohort honest. A pilot that cannot fail is a launch with a smaller audience.
TipAsk the cohort manager to open every pipeline 1:1 for three weeks with 'show me the brief.' That one sentence did more for adoption than any training I ran.
Adoption is a plumbing problem
Here is the part I got wrong and most rollouts get wrong. The rep should never be the courier between systems. If the play needs the HubSpot record, Claude should read HubSpot through a connector the rep authorized once, with their own permissions. If it needs the last call, it reads the transcript from the call tool. If the output belongs in the CRM, it writes there, behind an approval. Every export, paste, and copy-back you leave in the play is a place the habit will break.
That means the plumbing gets built before the pilot, by whoever runs systems (that is me, and probably you). The admin layer first, seats, SSO, and usage visibility, which I covered in the teams and admin guide. Then the connectors the play needs, a Project that carries the positioning and ICP so nobody re-pastes it, and the play itself packaged as a skill so it runs the same way for every rep and can be fixed in one place when the deal stages change.
A useful test: count the clicks from trigger to output. My original brief was eleven, including two application switches. The version that stuck was three: open the meeting, click the brief, read. Adoption tracked that number almost perfectly, which is humbling for someone who spent weeks on the prompt.
Train on the play, at the moment of the play
A webinar about Claude is entertainment. Enablement that works is a 30-minute working session where every rep runs the play on a real account they have this week, with you in the room, and leaves with a brief they will use tomorrow. Do it twice in week one. The second session is where the real questions come out, because by then they have tried it alone and hit the edges.
Then stand up a place for the edges to land: a Slack channel for the cohort, office hours twice a week for three weeks, and a habit of fixing the skill within a day when someone finds a gap. Speed of fix is itself an adoption signal. When a rep says the brief keeps missing the renewal date and it is fixed by lunch, they tell the next rep. When it is fixed in a sprint, they stop reporting things.
Capture what the cohort writes. Reps will improvise prompts around the play ("now draft the follow-up," "what did the competitor do here"), and those improvisations are your second and third plays. Save them in the Project, credit the rep by name, and you have started a shared library without calling a meeting about it.
TipRun the working session on live accounts, never on demo data. A brief about a fake company teaches nothing; a brief about the account they are nervous about tomorrow teaches everything.
Measure weekly active plays, not weekly active users
The Team and Enterprise usage analytics dashboard gives owners and admins weekly active members, feature usage (chats, Projects, skills, connectors with read and write counts), and spend by model, with CSV export. Use it, and do not run the rollout on it. Weekly active users measures curiosity. What you want is weekly active plays: how many times per rep per week the play ran end to end and produced the output. Skills usage and connector reads get you most of the way there; a lightweight log in the destination (the brief always lands in the calendar note) gets you the rest.
Pair that with two numbers you collect by hand in the pilot: minutes per play before and after, timed with a stopwatch on ten real instances, and a one-question quality check from the manager ("would you have gone into this call with this brief?"). Plays per rep per week, minutes per play, and a manager's yes rate. Three numbers, on one page, weekly. That is the whole adoption dashboard, and it fits in a Slack message.
The number I stopped reporting was hours saved. It is real and it is also the number everyone rounds their eyes at, because saved time is spent on something and nobody can show you what. Report plays and minutes; let the ROI guide do the money math with the appropriate humility.
- Plays per rep per week (from skills usage, connector reads, and the destination log).
- Minutes per play, before and after, timed on ten real instances rather than surveyed.
- Manager yes rate: would you have gone into the call with this brief?
- Active plays across the team once you expand, tracked by cohort so you can see a wave stall.
From cohort to team: the second wave
At the three-week mark you have a decision, not a vibe. If plays per rep are climbing and the manager yes rate is above roughly 70%, expand. If plays are flat and the yes rate is fine, the plumbing is the problem; fix the clicks and rerun two weeks. If the yes rate is low, the play is the problem; rewrite the skill with the skeptic before you touch another cohort. Kill is also a legitimate outcome, and saying so out loud is what earns you the budget for the next play.
When you expand, the pilot reps teach. Not you. A rep showing a peer the brief on a real account they closed carries more than any enablement deck from systems (I have the attendance numbers to prove it). Go one team at a time, keep the manager rule ("show me the brief" in every 1:1), and make the second wave opt-out: everyone gets the seat, the Project, and the skill on day one, and the default calendar workflow includes the brief.
Add the second play only after the first is boring. Boring is the goal. When nobody mentions the brief anymore because it is just how calls get prepped, you have room for post-call follow-up, and the cohort you already trained becomes the pilot for it. The first play takes a quarter. The second takes a month. The third, a week.
Where it goes wrong
The failures are predictable because they are all the same failure: launching a tool instead of running a change. The all-hands launch with no cohort, so you learn nothing and everyone's first impression is unsupervised. The courier play, where the rep exports, pastes, and copies back, and quits by week three. The volunteer cohort that loves everything and tells you nothing. The manager who was informed rather than enlisted, so the play never comes up in a 1:1.
Then the measurement failures. Reporting logins, which peak in week one and make the decline look like a disaster. Reporting hours saved, which finance politely does not believe. And skipping the admin layer, so half the team is on personal accounts and you cannot see any of it, which is the sprawl story from the teams guide, replayed with a sales floor. Each of these has a one-line fix, and every one of them is cheaper before the launch than after.
- Launching to everyone at once, so the first impression is unsupervised and unmeasured.
- Courier plays: any export, paste, or copy-back left in the workflow.
- A cohort of volunteers and no skeptic, so the feedback is kind and useless.
- A manager who was told about the pilot instead of running its 1:1s.
- Reporting logins or hours saved instead of plays, minutes, and a yes rate.
- No admin layer, so adoption happens on personal accounts you cannot see or govern.
The GTM version
For a RevOps or enablement lead, this is the sequence: admin layer, one play card, five to eight reps and one manager for three weeks, plumbing so nobody carries anything, three numbers on one page, then expand by cohort with the reps teaching. It is slower than an all-hands and it is the only version I have seen still running a quarter later. The role hubs, starting with the RevOps hub and the GTM funnel page, are where I keep the plays that make good first cards.
My week-four number was three people. The rerun, with a cohort, a connector, and a manager who asked for the brief every Tuesday, had eleven of twelve reps running the play at week six, and the twelfth was on leave. Same prompt. Different rollout. Which play would you put on the first card, and who is the skeptic you would put in the room?
How to set it up
Stand up the admin layer before you say the word pilot
Get the team onto a Team or Enterprise plan, tie it to SSO, and confirm you can see usage analytics as an owner or admin. If the cohort is on personal accounts you will have no data and no offboarding, and the pilot will teach you nothing you can repeat.
TipProvision the whole eventual team's seats now, even if only eight people are in the pilot. Reclaiming and re-adding seats mid-rollout is how people end up back on personal logins.
Write the play card for one play
Fill in the five lines. For the pre-call brief at a B2B SaaS team on HubSpot: trigger, a meeting with an external attendee appears on the rep's calendar; input, the attendee's company domain plus the HubSpot company and deal record over the connector; engine, the account brief skill running inside a 'Sales' Project that carries the ICP and positioning; output, a brief under 300 words with three talking points and one risk; destination, the calendar event's notes field.
Then the rep's actual prompt is one line, and the output should read like this: 'Brief me for the 2pm with Meridian Freight.' Claude reads the company record, the open deal (Stage: Evaluation, $48k ARR, last touch 11 days ago), and the domain, and returns: who is on the call and what they own; the two initiatives on their site that match our positioning; the fact that a competitor was named in the last call note; and one question to open with. If the brief needs anything a rep has to paste, the card is not done.
Recruit five to eight reps, one manager, and a skeptic
Pick a single team so the manager rule works. Ask the manager to open every pipeline 1:1 for three weeks with 'show me the brief.' Tell the cohort the pilot has an end date and three possible outcomes: expand, fix and rerun, or kill.
Run two working sessions in week one, on live accounts
Thirty minutes each. Every rep runs the play on an account they have this week and leaves with a brief they will use. Open a cohort Slack channel and hold office hours twice a week. Fix skill gaps within a day and say so in the channel.
TipTime ten real briefs with a stopwatch in session one, before anyone has used Claude, and ten more in week three. That before-and-after is the only time number you will ever need to defend.
Read three numbers weekly, then decide
Plays per rep per week from skills and connector usage, minutes per play from your stopwatch, and the manager's yes rate. Post them in the channel every Friday. At week three: climbing plays and a yes rate above 70% means expand to the next team with the pilot reps teaching; flat plays means fix the clicks and rerun; a low yes rate means rewrite the skill with the skeptic first.
Frequently asked questions
How do you drive AI adoption on a sales team?
Treat it as change management, not a tool launch. Pick one play with a clear trigger and output, pilot it with five to eight reps and one manager for three weeks, wire the data so the rep never exports or pastes anything, and measure plays completed per rep per week. Expand by cohort with the pilot reps teaching.
What is the best first play to roll out?
Pre-call research. Every rep does it, most do it badly under time pressure, and the payoff shows up in the next thirty minutes. Post-call follow-up is the second. Avoid plays whose value only shows up in a quarter; reps will not carry a habit that long on faith.
How big should the pilot cohort be?
Five to eight reps on one team, plus their frontline manager. Small enough to sit with everyone, big enough that one vacation does not wipe out your data. Include at least one skeptic on purpose; volunteers tell you kind, useless things.
Why do Claude rollouts fail on sales teams?
Usually plumbing. If the rep has to export a CRM record, paste it, and copy the result back, the habit breaks by week three. The other common causes are launching to everyone at once, a manager who was informed rather than enlisted, and measuring logins instead of work.
What adoption metrics should I track?
Three: plays completed per rep per week (from skills and connector usage in the analytics dashboard plus a log in the destination), minutes per play before and after (timed, not surveyed), and the manager's yes rate on the output. Weekly active users measures curiosity, not work.
Do I need the Team or Enterprise plan for a rollout?
Yes, in practice. You need seats you control, SSO for onboarding and offboarding, and the usage analytics that show plays, skills, and connector activity. A pilot on personal accounts gives you no data and a governance gap you will clean up later.
How long does a rollout take?
About a quarter for the first play to become boring across a team: a three-week pilot, a decision, then one team at a time. The second play takes a month because the cohort is already trained. Faster than that usually means you skipped the pilot and will pay for it in week four.
How do I handle reps who refuse to use it?
Put one in the pilot and listen. Most refusal is friction in disguise: too many clicks, a brief that misses their custom stages, output they do not trust. Fix those in a day and say so. The remaining holdouts usually convert when a peer, not systems, shows them a brief on a deal they recognize.
Sources & further reading
- View usage analytics for Team and Enterprise plans (Claude Help Center)
- Team and Enterprise plans (Claude Help Center collection)
- Claude Enterprise plan
- Claude pricing and plans
Claude ships fast. This page was last reviewed Sep 4, 2026; verify time-sensitive details against the official docs above before relying on them.