Onboarding a Team to Claude Basics
10 examples to get you started with onboarding a team to Claude - 7 basic and 3 intermediate.
Prerequisites
- Access to Claude.ai for the people in your pilot group, on whichever plan your organization has approved (Free through Max, or a Team/Enterprise workspace).
- A specific team and a short list of use cases already in mind - onboarding works far better with a scope than with an open-ended "try it and see."
- Someone willing to act as pilot lead for the first week, even informally, to answer questions and notice how usage is going.
Basic Examples
1. Picking the pilot group before picking a launch date
Before scheduling a kickoff, decide exactly who is in the pilot and who isn't.
- A pilot group should be small enough that a pilot lead can pay real attention to it, often a single team rather than a cross-section of the whole company.
- Choose people who have real, recurring work Claude can plausibly help with, not just whoever happened to ask for access first.
- Write the group down explicitly, by name, so there's no ambiguity later about who was part of the first-week pilot and who joined afterward.
- A clear group also makes it possible to measure adoption later, since you know exactly whose usage you're looking at.
Related: Steps to Run a Successful Claude Pilot Group - the fuller process this basics guide previews.
2. Scoping two or three starting use cases, not ten
Pick a small, concrete set of tasks for the pilot to try in week one.
- Two or three use cases (drafting a recurring report, summarizing meeting notes, first-pass copy editing) is enough to generate real usage without overwhelming a new group.
- Choose use cases people already do regularly, so trying Claude on them doesn't require inventing new work just to test the tool.
- Avoid starting with the hardest or most unusual task in the team's workflow - an early frustrating experience can sour the whole pilot before it gets going.
- Write the use cases down and share them with the group, so everyone starts from the same starting point instead of guessing what they're supposed to try.
3. Running a short kickoff session instead of sending a link
A five-minute Slack message with a login link isn't onboarding, it's just access.
- Hold a short kickoff, even 20-30 minutes, where the pilot lead shows Claude actually being used on one of the chosen use cases.
- Live or recorded, seeing a real example beats reading a description, since it shows what a good prompt looks like and what a useful answer looks like.
- Leave time for questions at the end - the first ones people ask usually reveal what the rest of the group is also wondering but hasn't said yet.
- Record the session if possible, so people who join the pilot later, or miss the first meeting, have something to refer back to.
4. Matching the model to the task from day one
Not every task in the pilot needs the same model tier.
- Claude Haiku 4.5 is fast and well suited to quick, high-volume tasks like a first-pass summary.
- Claude Sonnet 5 is the current default and handles most everyday pilot use cases well.
- Claude Opus 4.8 and Claude Fable 5 are built for deeper reasoning, useful if one of the pilot's use cases involves more complex analysis or writing.
- Introducing this distinction in week one, rather than letting people discover it by accident, saves confusion later about why answers vary in depth or speed.
5. Setting one simple ground rule about sensitive data
Decide, before the pilot starts, what should never be pasted into Claude.
- A single clear rule (no customer records, no unreleased figures, no credentials) is enough for week one - a full policy can come later, once the pilot has run for a while.
- State the rule explicitly in the kickoff session rather than assuming it's obvious to everyone.
- This is a placeholder for the fuller usage policy your team will need before expanding past the pilot, not a substitute for it.
- Getting this habit right from day one is far easier than correcting it after people have already built the opposite habit.
Related: Usage Policy Checklist for Team-Wide Claude Rollouts - the fuller policy to draft before expanding past the pilot.
6. Creating a place to share what's working
Give the pilot group a shared channel or thread to post examples in.
- A simple running thread ("here's a prompt that worked well for X") does more for spreading good usage than any single training session.
- Ask people to share both wins and confusing moments - the confusing moments often reveal a gap in the kickoff session worth addressing for the next group.
- The pilot lead should check this channel daily during week one, since it's the fastest signal of how the pilot is actually going.
- This channel is also where a future champion usually becomes visible first, through the quality and frequency of what they share.
Related: Identifying Champions and Power Users for Your Claude Rollout - how to spot that person once they show up.
7. Checking in at the end of week one, not just at the start
Close the first week with a short, deliberate check-in rather than letting the pilot run silently.
- A 15-minute sync or a short written recap works - the point is to hear directly how the chosen use cases actually went.
- Ask what people tried that wasn't on the original use-case list, since that often points to where real value is hiding.
- Note anything that felt confusing or slow, since those are the first things to fix before the pilot continues.
- This check-in is also the first real data point for measuring adoption later, so treat it as the start of that habit, not a one-off.
Intermediate Examples
8. Extending the pilot before declaring it finished
A single week is rarely enough to judge whether Claude is genuinely useful for the team.
- Plan for at least two to four weeks of pilot usage before deciding whether to expand, extend the use cases, or wrap it up.
- Use the extra time to let people move past the original two or three use cases into ones they discover on their own.
- Keep the shared channel from example 6 running throughout, since the richest examples usually appear after the first week's novelty wears off.
- A longer pilot also gives real engagement metrics time to accumulate, which matters once you're ready to measure adoption formally.
Related: How to Measure Adoption Across a Team - the metrics to start tracking once the pilot has run long enough to generate them.
9. Connecting Claude to one existing tool, deliberately
Once the pilot group is comfortable with Claude on its own, connect it to one tool the team already uses.
- Slack is usually the lowest-effort, highest-visibility place to start, since it's where most day-to-day team communication already happens.
- Pick one integration, not several at once - adding Slack, email, and a document system simultaneously makes it hard to tell which connection is actually driving usage.
- Treat this as a deliberate, planned step for week two or three of the pilot, not something to rush into during the first week's kickoff.
- A successful single integration also gives you a template for the next one, once the pilot is ready to expand further.
Related: Integrating Claude into Slack, Email, and Existing Docs Workflows - the fuller procedural guide for this step.
10. Drafting the first version of a usage policy before the pilot ends
Before deciding whether to expand past the pilot group, put the informal ground rule from example 5 into writing.
- Cover what Claude is approved for, what it isn't, and how sensitive data should be handled, based on what the pilot actually revealed about real usage.
- Involve whoever will need to sign off on a wider rollout (a manager, IT, or a compliance contact) while the pilot is still small enough to iterate quickly.
- A policy drafted from real pilot experience is more useful than one written in the abstract before anyone has actually used the tool.
- This draft becomes the starting point for the fuller usage-policy checklist once the team is ready to move beyond the pilot group.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.