Sylvie owns a nine-person insurance agency in Tampa. When she rolled out AI tools to her team last year, she trained everyone at the same time in a two-hour group session and declared the job done. Three months later, two staff members used the tools daily and thought they were essential, four used them occasionally, and three had not opened them since the training. The split was not random. The two daily users had something in common: they were naturally curious about new technology, they had already been helping colleagues troubleshoot small problems, and they had quietly become the people the rest of the team asked when they had an AI question. Sylvie had created AI champions by accident. Once she saw the pattern, she understood how to do it deliberately.

Why the Split Was Not Random

Sylvie's group session gave nine people identical information on the same afternoon, and three months later it had produced three completely different outcomes. That is worth sitting with, because it rules out the explanation most owners reach for first. The training was not too short or too technical for some people and not others; everybody got the same two hours. What differed afterwards was whether a person had somewhere to take the small question that came up on the Tuesday they actually needed the tool.

The two daily users had that, because they were each other's somewhere, and the four occasional users had it intermittently. The three who stopped had a question at some point, did not have an obvious person to ask, and quietly went back to the method that already worked. Adoption failed in the gap between the training and the first real attempt, which is a gap no training session can cover because it happens on a different day.

What a Champion Actually Does

An AI champion is not a trainer. They are not a technical expert, and they do not need to understand how any of it works underneath. They are a trusted peer: someone on your team who uses AI tools with enough confidence and enthusiasm that their colleagues trust their recommendations and ask them for help without it feeling like an admission of anything.

The distinction matters more than it sounds. When you or an outside trainer tells the team to use AI, it lands as a directive from management, and directives get complied with rather than adopted. When a coworker at the same level says "let me show you how I did that in two minutes with AI," it lands as a tip from someone who understands the actual work, including the parts of it that are annoying. On this kind of adoption challenge, peer influence changes behavior faster than management mandates do.

Nothing about the role requires a title, a budget, or a slot on an org chart. What it requires is that the person is visibly using the tools on real work and is approachable enough that a colleague who feels slow will ask them rather than quietly give up. That combination is what turns a training session into an adoption curve.

One consequence of that is uncomfortable for owners: you cannot be your own champion. The mechanism depends on the exchange being peer to peer, and nothing said by the person who signs the paychecks is peer to peer, however good the working relationship is. You can be enthusiastic, model the behavior, and resource the role generously. The person colleagues ask when they feel slow has to be somebody else, which is why identifying that person matters more than any amount of enthusiasm on your part.

How Many Champions You Need

For a business with nine people, like Sylvie's, you need one to two champions. For a team of twenty, two to four. You do not need many, and appointing more does not accelerate anything. What you need is a few people who use the tools visibly and who make their colleagues feel less anxious about trying, which is a function of trust rather than of coverage.

Naming too many has a specific failure mode: the role stops meaning anything, nobody feels particularly responsible, and the people who were genuinely enthusiastic find themselves in a committee. One person who actually uses the tools every day and answers questions in the group chat does more than five people with the label.

How to Identify Your Champions

Champions are often not the people you would expect. Do not default to your most tech-savvy employee, and do not default to your assistant manager because the role sounds like a management responsibility. Technical fluency without patience produces someone who answers questions in a way that makes people stop asking. Look for three behaviors instead.

Early adoption without being pushed. Who tried the AI tool before you reminded them to? Who mentioned it in a meeting unprompted, or showed a colleague something they had worked out on their own? Enthusiasm that arrives before a management directive is a better signal than enthusiasm that arrives after one, though it is a signal rather than a guarantee, and it needs the other two behaviors alongside it.

Teaching instinct. Who explains things patiently to coworkers? Who notices when a colleague is struggling and offers to help before being asked? The willingness to teach matters more here than technical depth, because most of what a champion does is answer the same small question in a way that leaves the person feeling capable.

Credibility with peers. Does this person's opinion get listened to? If they say "this is actually useful," do others believe them? A champion whom peers distrust is not a champion, they are just a loud early adopter, and putting the role on them can make the resistance worse by attaching the tools to someone the team already discounts.

Sylvie found her two champions by asking a single question in a team meeting: "Who has used AI for something in the last two weeks and found it genuinely helpful?" Two hands went up without hesitation. She started there. The question works because it asks about behavior rather than about interest, and because the people who answer it honestly have already done the thing you are trying to spread.

Ask rather than appoint. The role only works if the person wants it, and someone who accepts it out of politeness will do the visible parts and none of the useful ones. Describe what you are asking for, say what you are protecting to make room for it, and let them decline without cost. A refusal is worth having early: it usually means either the workload is already too high, which is your problem to solve, or the enthusiasm you observed was narrower than it looked.

Developing Your Champions

Once you have identified them, invest in them. Not with a title, and not with a large new responsibility on top of the job they already have. Invest with time and access, which are the two things that actually determine whether the role works and the two things owners are most reluctant to give.

Give them dedicated exploration time

Two hours per week, specifically for trying AI tools on real work from your business. Not theory. Not training videos. Actual tasks: drafting a client email, summarizing a policy document, building a simple prompt template for something that recurs every week. Exploration on real work is what produces the hands-on experience a champion needs to help a colleague with a specific situation rather than offering general encouragement.

Because it is real work, it carries real data, and whatever rules already govern client information in your business apply during exploration time exactly as they do during production work. Say that out loud when you set the time aside. Champions are the people most likely to try something adventurous with a document, which is the point of them, and also the reason the boundary should be explicit rather than assumed.

Make them the first to try new tools

Before you roll out any new AI capability to the whole team, let your champions use it for a week. They will find the rough edges, develop workarounds, and form real opinions, including the opinion that it is not worth rolling out at all, which is worth hearing before you have announced it. When they then introduce it to the team, they are sharing genuine experience rather than repeating a vendor pitch, and their colleagues can tell the difference immediately.

Give them a clear scope

Define what you are actually asking of them. Something like: "I'd like you to be the go-to person for AI questions on the team. That means using AI tools daily in your own work, being available when a colleague asks for help, and flagging to me any tool that isn't working well or any task type where AI is really shining." That is specific enough to accept or decline. It is not "be the AI person," which is vague, sounds like extra work with no boundaries, and tends to expand until it is resented.

Be equally clear about what you are not asking. Champions are not responsible for building your training program, for onboarding new staff on AI tools, or for policing whether colleagues use them. Those are management tasks, and handing them over converts the peer into a supervisor, which is precisely the transformation that stops colleagues asking casual questions. The role is deliberately small: use the tools on real work, be available, and report back what you hear.

What Champions Need From You

Champions do not stay effective if they are invisible or unsupported. The role runs on goodwill, and goodwill runs out when helping people costs you something and gets you nothing. Three things keep it working.

Public acknowledgment. Mention in a team meeting that someone's use of AI on a specific task saved time or produced something good. Be specific about the task rather than praising the enthusiasm in general. This signals to the whole team that using these tools is valued rather than tolerated, and it reinforces the champion's credibility as the person to learn from.

Protection from cynics. In almost every team there is someone resistant to AI adoption, and resistance on its own is fine and often well founded. What is not fine is mockery directed at colleagues who are trying something new, because that stalls adoption faster than any technical problem. You do not need to pick a fight with the cynic. You do need to make it clear that experimenting with these tools is expected rather than optional.

Feedback loops. Ask your champions regularly what people are asking about, what is not working, and what would help the team adopt faster. They are your most valuable source of ground-level information about what is actually happening with AI in the work, and that information does not reach you any other way, because nobody tells the owner that they have quietly stopped using the tool.

The Difference This Makes

After Sylvie formalized her two champions and gave them exploration time, she ran a usage check at the sixty-day mark. Eight of the nine were using the tools. The one holdout was a part-time administrator who had a process concern she had never raised with management. One of the champions surfaced that concern, and the two of them solved it together in twenty minutes.

That detail is the whole argument for the role. The concern had existed for months, it was solvable in twenty minutes, and it never reached Sylvie because the administrator did not consider it worth raising with the owner. A peer heard it in the ordinary course of the day. No amount of additional group training would have produced that outcome, because the problem was never a training problem.

Notice what Sylvie actually changed. She did not run a better group session, buy different tools, or mandate usage. She identified two people who were already doing the thing, gave them two hours a week and first access to anything new, made their work visible in team meetings, and asked them regularly what they were hearing. The tools were the same ones that had sat unopened on three people's laptops for three months.

The champions did not run a formal session at any point. They showed colleagues specific tricks over lunch, answered questions in the group chat, and occasionally sat next to someone for ten minutes to get them unstuck. Informal, targeted, and peer to peer. That is what moves adoption in a small business team, and it is almost invisible from the outside, which is why it needs to be deliberately resourced rather than left to chance.

Anti-Patterns

Training everyone at once and calling it done. Sylvie's two-hour group session was not wasted, but on its own it produced three people who never opened the tools again. A single session teaches the interface; it does not create the conditions under which someone asks a question on the day they get stuck.

Appointing the most technical person by default. Technical fluency without patience or peer credibility produces someone who answers questions in a way that discourages the next question. The behaviors that matter are early adoption, teaching instinct, and credibility, in that combination.

Giving the title without the time. Naming a champion and expecting the role to happen in the gaps of an already full week is the most common version of this failure. Two hours a week on real work is the investment that makes the rest of it possible.

Turning the champion into an unpaid help desk. Without a defined scope, the role expands until the champion is doing other people's work rather than showing them how to do it. Write down what you are asking for, including where it stops.

Letting exploration time drift outside your data rules. Real work means real client information. If a document would not normally be pasted into an outside system, exploration time does not change that, and a champion who assumes otherwise will be modeling the behavior for everybody else.

Confusing enthusiasm with credibility. The loudest early adopter is not automatically a champion. If colleagues do not trust the person's judgment already, attaching the tools to them can attach the team's skepticism about the person to the tools.

Practice Prompts

Use these while you are setting up the role, not after adoption has already stalled.

• Candidate check: "Here is what I know about three people on my team: [describe their behavior with new tools, with colleagues, and how their opinions land]. Which of them shows early adoption, teaching instinct, and peer credibility, and where is my evidence thin?"
• Scope drafting: "Write a short, specific description of an AI champion role for a [size] business, covering what the person does daily, what colleagues can expect from them, and what they report back to me. Keep it to something a person could accept or decline."
• Exploration agenda: "Suggest tasks a champion in a [type of business] could try during two hours a week of exploration time, using real work rather than exercises, and note which of them involve sensitive information."
• Feedback questions: "Give me four questions to ask my AI champions regularly that would surface what colleagues are struggling with, phrased so the answers are specific rather than reassuring."

Reflection

• Who on your team has already helped a colleague with an AI question without being asked to? That person is probably your champion, whatever their job title says.
• Of the people you trained most recently, how many are still using the tools? If you do not know, what would it take to find out this week?
• What would a colleague on your team tell a peer about your AI rollout that they would not tell you?
• If you named a champion tomorrow, what would you take off their plate to make room for two hours a week?

Glossary

AI champion: A trusted peer who uses AI tools visibly on real work and helps colleagues, without being a trainer, a technical expert, or a manager.

Peer influence: The adoption effect produced when a colleague at the same level demonstrates something useful, which on this kind of change moves behavior faster than a management directive.

Exploration time: Protected hours set aside for a champion to try AI tools on genuine business tasks, as distinct from training videos or theory.

Scope statement: The short, specific description of what a champion is being asked to do daily, what colleagues can expect, and what they report back.

Adoption check: A point measurement of how many people are actually using the tools, taken at a set date rather than inferred from impressions.

Loud early adopter: Someone enthusiastic about the tools whose judgment peers do not trust, whose advocacy can attach existing skepticism about them to the tools themselves.

Related Lessons

• Addressing Resistance and Building AI Champions is the direct companion, covering the resistance side of the same adoption problem.
• Designing AI Training Programs for Your Team covers the formal training that champions supplement rather than replace.
• Measuring Training Effectiveness and Adoption develops the usage check into something you track rather than sample.
• Building Psychological Safety Around AI Adoption deals with why a holdout keeps a solvable concern to themselves for months.
• Scaling Integrations Across Your Team picks up when several AI workflows need to spread across the same small team at once.

Closing

Sylvie's mistake was not the group session. It was assuming that the session was the mechanism, when the mechanism was two people who already answered their colleagues' questions and would have done it whether or not anyone noticed. Adoption in a small business happens in the ten minutes somebody spends at a coworker's desk, in the group chat, over lunch. You cannot schedule that, but you can identify the people who do it, give them two hours a week and first access to anything new, and make sure everyone can see that it is valued. That is most of the work.

Key Takeaways

• A champion is a trusted peer who uses AI visibly and helps colleagues feel less anxious about trying. They are not trainers and do not need to be technical experts.
• Look for early adoption, teaching instinct, and peer credibility. Those three behaviors together predict champion effectiveness better than technical skill does.
• You need very few. One to two champions for a team of nine, two to four for a team of twenty. More labels do not produce more adoption.
• Give champions two hours a week of dedicated exploration time on real work. That hands-on experience is what lets them help with specific problems rather than offering general encouragement.
• Let champions try new tools a week before the team does. Genuine experience, including a genuine negative verdict, is more credible to peers than a vendor demo.
• Give them a specific scope, not a vague title. "Use the tools daily, be available for questions, flag what is and is not working" is actionable. "Be the AI person" is not.
• Acknowledge their contributions publicly and protect them from mockery. Visibility reinforces credibility, and resistance that turns into ridicule stalls adoption faster than any technical problem.
• Champions are your best source of ground-level adoption intelligence. Ask them regularly what peers are asking, what is not working, and what would help.

Frequently Asked Questions

What if nobody on my team is enthusiastic about AI? Then you do not have a champion yet, and appointing one anyway will produce a reluctant volunteer whose lack of conviction the team will read accurately. Start smaller: find the one task where somebody is visibly frustrated by repetitive work, help that person try a tool on it, and see whether interest follows a useful result. Enthusiasm that comes from a concrete win is more durable than enthusiasm about the category.

Should I pay champions extra or give them a title? The role is designed to run on time and access rather than on compensation, and a title tends to convert a peer into a junior manager, which removes the thing that made them effective. What matters is that the two hours a week are genuinely protected and that the work is visible. If the role grows into something substantially larger than described here, that is a different conversation about the job rather than about adoption.

My champion left the business. Now what? This is the risk of a role that lives in one person, and it is a reason to have two rather than one wherever the team is large enough. Identify the next candidate using the same three behaviors, and before the departure if you can, ask the outgoing champion what people ask them about most often. That list is the most useful handover document available, and it usually does not exist anywhere else.

How do I know whether it is working? Pick a date, count how many people are actually using the tools, and compare it with what you counted last time. Usage counts are crude but honest, and they are much harder to talk yourself out of than impressions gathered in a meeting where nobody wants to say they stopped. Sylvie's sixty-day check is the pattern: a fixed date, a simple count, and a conversation about whoever is not in it.