Catalogue › Copilot Adoption › adoption-reinforcement

Adoption reinforcement

Runs the always-on reinforcement cycle for Copilot after launch - a calendar of nudges and refreshers, scenario refreshes, manager follow-up prompts, re-engagement of teams whose use has faded and refreshers when Copilot changes - triggered by team-level signals, never individual tracking. Use when launch is over and use is plateauing, when teams drift back to old habits, or when a Copilot change must reach existing users.

Department

Copilot Adoption

Lifecycle

Launch, Measure, Improve

Maturity

adopter, scaler, ai-enterprise

Risk tiers

0, 1

Platforms

copilot-chat, m365-copilot, copilot-cowork

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Copilot Adoption plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Most people try Copilot after launch; far fewer keep using it once the novelty fades and deadlines return. This skill runs the reinforcement cycle that carries adoption from launch into habit: small, regular prompts to try something useful, refreshers when practice slips or the product changes, managers asking the right questions, and targeted help for teams where use has faded. It is driven by team-level signals and by what users say, not by watching individuals. Reinforcement usually goes wrong when it stops after the first month, when it repeats launch content to people who have moved on, or when "re-engagement" turns into chasing named people.

When to use

• Launch is complete and the programme needs an operating rhythm for the months that follow.
• Team-level indicators show use plateauing or falling in some parts of the organisation.
• Feedback shows people stuck on the same few scenarios and unaware of what else is useful.
• A significant Copilot change, new capability or updated approved-use guidance must reach people already onboarded.
• Managers have stopped mentioning Copilot and teams are drifting back to old routines.

When not to use

• Planning the launch and the reinforcement calendar for the launch window itself - use copilot-adoption:launch-plan.
• Embedding new behaviours into processes, roles and leadership routines as part of the wider change plan - use change-and-communications:behaviour-reinforcement-plan.
• Planning a time-boxed campaign around a scenario theme - use change-and-communications:adoption-campaign-plan.
• Running office hours and drop-in clinics as a service - use learning-and-skills:office-hours.
• Deciding what to measure and the reporting rules - use copilot-adoption:adoption-measurement.

Questions to ask first

1. Which team-level signals are available (usage at aggregate level, pulse results, support themes, Champion feedback), and how often are they refreshed?
2. Which teams or audiences have plateaued or faded, and what do their managers and Champions say is happening?
3. What new or under-used scenarios are ready to share, and who has tested them?
4. What channels do people actually read or attend, and which have become background noise?
5. Who will own the reinforcement calendar, and how much capacity do they have each month?

Required inputs

• Team-level adoption indicators and feedback themes from copilot-adoption:adoption-measurement.
• The scenario catalogue from copilot-adoption:scenario-discovery, including scenarios not yet promoted.
• The audience model from copilot-adoption:audience-segmentation, so nudges can be targeted by audience.
• The Champions community and office hours calendar, where they exist.
• Notice of upcoming Copilot changes from the owners of the Microsoft change process.

If no team-level signals exist, start with qualitative signals from managers, Champions and support themes and ask copilot-adoption:adoption-measurement to set up aggregate indicators. Never substitute individual usage lists.

Decision framework

Match the response to the signal. All signals are read at team or audience level above the minimum group size.

Choose mechanisms that fit the audience and the capacity available.

Practitioner approach

Treat reinforcement as an operating rhythm, not a campaign. Set a simple monthly cycle: review team-level signals and feedback, decide two or three reinforcement actions, run them, and note what changed. Put the cycle in the adoption lead's calendar with named contributors, so it survives the end of the launch project.

Keep nudges small and useful. One prompt that saves someone time today is worth more than a newsletter of tips. Write each nudge around a task the audience does, include the verification step, and send it through the channel the audience actually reads. Vary the channel and format over time, because any single channel becomes background noise.

Refresh scenarios rather than repeat launch content. People who have been using Copilot for months need the next useful thing, not the getting-started session again. Work with business owners and Champions to promote scenarios that are tested but under-used, and retire ones that no longer reflect how the product works.

Give managers one question a month. "What is one thing Copilot helped with this month, and what didn't work?" asked in an existing team meeting does more than any central message. Equip managers to ask without monitoring: the point is to surface practice and obstacles, never to check who has used it.

When a team's use fades, investigate before acting. Speak to the manager and the local Champion, look at support themes and pulse comments for the team, and check whether something has changed: a reorganisation, a busy season, a poor early experience, an access problem. Then agree one or two targeted actions with the manager, such as a refresher on the team's real work or a Champion pairing. Re-engagement is offered to the team, not imposed on individuals.

Make product change part of the rhythm. Copilot changes frequently, and existing users learn of changes late or not at all. Ask whoever tracks Microsoft change notices to flag changes that alter user experience or guidance, and turn each into a short audience-specific refresher.

Report reinforcement by what it changed: scenarios newly in use, teams re-engaged, support themes resolved. Hand lasting behavioural changes, such as altered routines and templates, to the wider change plan so they are embedded beyond the adoption team.

Outputs

• A reinforcement calendar recorded in the reinforcement section of the adoption-plan template: mechanisms, audiences, rhythm, owners and the monthly review.
• A signal-to-response playbook at team level, with the checks to make before acting.
• A bank of nudges and scenario refreshes by audience, drawn from the scenario-catalogue.
• A monthly reinforcement note to the sponsor: signals, actions taken and what changed.

Microsoft platform considerations

Aggregate usage reporting from Microsoft can show broad trends by group, but definitions, availability and privacy settings change; confirm them against references/sources.md and use reporting through m365-copilot:copilot-usage-reporting. Refreshers must match current Copilot behaviour and naming, which changes often, so review material against the current source records before each cycle.

Adoption considerations

This skill is where adoption is sustained or lost. Keep the cycle light enough to survive competing priorities, and share credit with managers and Champions, whose involvement matters more than central communications.

Knowledge considerations

Fading use is often a knowledge problem in disguise: people stop asking about policies or procedures because the answers were poor. Note these patterns and pass them to knowledge-management:knowledge-gap-analysis.

Security and privacy considerations

Signals are read only at team or audience level above the minimum group size. Reinforcement material repeats the approved-use guidance where relevant and the route for reporting suspected data exposure. Data protection questions about usage data end with the organisation's DPO.

Responsible AI considerations

Reinforcement promotes useful, verified practice, not volume of use. Never set targets that reward indiscriminate use, and keep reminding people that they remain accountable for what they send.

Evaluation requirements

Not applicable as solution evaluation, because reinforcement is an adoption practice rather than an AI solution. Each monthly cycle records which actions were taken and what changed in the signals, so ineffective mechanisms can be dropped.

Value measures

Owned by the adoption lead, with baselines from the end of launch: sustained use at team level over successive months, breadth of scenarios in use, teams re-engaged after fading, and repeat support themes resolved. Reported above the minimum group size, never for individuals.

Scale notes

Starter

A fortnightly nudge, a monthly scenario refresh and one manager question each month, reviewed by the adoption lead in a short monthly slot.

Scale

A monthly cycle with Champions and managers, audience-targeted nudges, triggered re-engagement for faded teams and product-change refreshers.

Enterprise

Regional reinforcement cycles on a shared playbook, a central bank of nudges and refreshers, and signals reported consistently across divisions to the CoE.

Hand-offs

• To change-and-communications:behaviour-reinforcement-plan for changes that must be embedded in processes and routines.
• To champions:champion-community-design for peer showcases and Champion-led refreshers.
• To copilot-adoption:adoption-measurement to refine the signals behind the cycle.
• To copilot-adoption:adoption-support-model when repeat support themes point to a support gap.

Reviewer gates

Not applicable as a formal gate, because reinforcement of approved Copilot experiences at tiers 0 and 1 does not release an AI solution.

Failure modes

• Reinforcement stops when the launch project closes, and use fades over the following quarter.
• Launch content is repeated to experienced users, who stop paying attention.
• Re-engagement turns into chasing named individuals, and trust in the programme collapses.
• Product changes reach users months late, so guidance and reality diverge.
• A single channel is overused until every nudge is ignored.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Use individual usage data to target, chase or judge people.
• Set targets that reward volume of use over useful, verified practice.
• Act on a team's faded use before speaking to its manager and Champion.
• Let reinforcement end with the launch project without a named owner.