Team & OrgHow It Works

Your manager said yes. Now what? The first 48 hours of a Claude rollout

In brief

Approval is not adoption. What to do in the window between 'we can use this' and 'we actually use this' — before momentum stalls and inertia wins.

6 min read·Projects

Contents

♡Sign in to save

Approval is the easy part. The hard part is the 48-hour window between "we got sign-off" and actually having your team using Claude in their daily work. Most rollouts stall here — not because of resistance, but because the person who pushed for approval suddenly has no script for what comes next.

This is that script.

Why the window matters

The same week you announce Claude to your team, three things compete for their attention: their existing workload, their skepticism about whether this will stick, and the vague fear of doing it wrong. If you do not move quickly and concretely, inertia wins. People file it under "interesting thing to try eventually" and never return.

The first 48 hours set the frame. Get one person using it for one real task before the week is out, and it becomes something your team does. Let it sit, and it becomes something your company approved in theory.

Before you announce: the 30-minute setup

Do not announce until you have these three things in place:

1. A shared Project with a base system prompt.
Create a Claude Project for your team with a system prompt that covers: who you are, what the team does, key terminology, and what good output looks like. Even a rough version of this is better than nothing — it means the first time someone uses it, they get an answer calibrated to your context, not a generic one. This takes 20 minutes.

A minimal starting point:

You are assisting the [team name] team at [company].

Context: [2–3 sentences about what your team does and who your stakeholders are]

Our terminology: [any acronyms or terms that are specific to your company or team]

When helping with written communication, match our company's tone: [professional/casual/direct/etc.]

Do not: make up names, figures, or internal references you don't have.

2. One concrete use case for the first session.
Pick one task your team does regularly that takes 20-40 minutes of writing or thinking. Email drafts, meeting summaries, research briefs, status updates — anything where a first draft exists to react to is better than a blank page. Do not ask people to use Claude for everything at once. One specific thing.

3. A 30-minute team session on the calendar within 48 hours.
Not a demo. Not a training. A working session where people actually try it on the real task you identified. If you have more than 6 people, break into smaller groups. The goal is for every person to produce something they actually send or use before the session ends.

The announcement message

Short. Concrete. Time-bounded. Something like:

I got approval for us to use Claude, and I've set up a shared Project with our context already loaded. I want to run a 30-minute session [day/time] where we each try it on [specific task]. No prep needed — just show up.

That's it. Do not explain what Claude is. Do not send an article about AI. Do not promise it will change everything. You are asking for 30 minutes to try one thing.

The working session

Open with one demonstration yourself — show the Project, show the system prompt, run one realistic query. Keep it under 5 minutes.

Then give everyone 15-20 minutes to try it on their own version of the task. Circulate. When someone gets a good result, ask them to share their screen.

Close by asking two questions: "What would you actually use this for in your work?" and "What felt broken?" Capture both. The first builds individual commitment. The second gives you your improvement list.

Do not end the session without a next step. "Try it once on your own this week before we check in on Friday" is sufficient.

The follow-up

Three days later, send a short message asking who has used it since the session. Ask one person to share what they made — not the whole group, just one person. This creates social proof without pressure. It also tells you who your early adopter is; that person becomes your internal advocate for the next phase.

If fewer than half the team tried it since the session, the task you chose was probably too abstract or too different from their daily work. Ask them what they actually spend time on, pick something from that list, and try again.

What to resist

Resist sending a guide. Written instructions create homework. Homework creates procrastination. A 30-minute working session creates a result.

Resist covering everything at once. Claude Code, integrations, advanced prompting — all of that comes later. Right now you need adoption, not sophistication.

Resist making it optional. "Try it if you want" means "half the team won't." Frame the session as the thing you're doing, not the thing that's available.

Resist waiting for the perfect setup. The system prompt will be wrong. The use case will be suboptimal. That is fine. You improve from there. A rough session that happens beats a polished one planned for next month.

Related: Setting up Claude for your team — the two-layer model for team configuration. Claude for your team's first week — individual onboarding for new users.