Catalogue › Copilot Adoption › adoption-support-model

Adoption support model

Designs the user support model for Copilot - self-help, Champions as first-line peer guidance, office hours, the IT service desk, admin escalation to Microsoft, the security route for suspected data exposure and the intake route for ideas - with triage categories, capacity and a feedback loop. Use when Copilot is about to launch, when Champions or the service desk are overwhelmed, or when nobody knows where Copilot questions go.

Department

Copilot Adoption

Lifecycle

Mobilise, Launch, Improve

Maturity

explorer, adopter, scaler, ai-enterprise

Risk tiers

0, 1

Platforms

copilot-chat, m365-copilot, copilot-cowork, m365-agents

Editions

starter, scale, enterprise

Reviewers

security-privacy

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

People using Copilot ask questions that do not fit a traditional service desk: "how do I", "why did it say that", "is it allowed to use this file", "could we build an agent for this". This skill designs a support model that sends each kind of need to the right place, from self-help and peers through the service desk to security and opportunity intake, with enough capacity and a feedback loop that improves guidance over time. Support models usually go wrong in one of two ways: everything lands on the service desk, which cannot answer usage questions, or everything lands on Champions, who become an unpaid help desk and burn out.

When to use

• Copilot is about to launch to a new audience and the support route must be ready first.
• The service desk receives Copilot "how do I" questions it cannot answer, or closes them unhelpfully.
• Champions report that most of their time goes on support rather than on spreading capability.
• Users do not know where to report a worrying answer, a suspected data exposure or an idea.
• A readiness assessment has rated the support route as not ready.

When not to use

• Support, monitoring and incident handling for deployed agents and AI solutions - use ai-operations:ai-support-model.
• Managing an AI incident or harm once reported - use ai-operations:ai-incident-management.
• Running office hours and drop-in clinics as a learning service - use learning-and-skills:office-hours.
• Setting the Champions' role and boundaries in the programme charter - use champions:champion-programme-design.
• Sequencing the launch the support model serves - use copilot-adoption:launch-plan.

Questions to ask first

1. What types of Copilot need are arising or expected - how-to, access, faults, answer quality, data concerns, ideas - and roughly in what proportion?
2. What can the service desk handle today, what knowledge articles does it have, and who can escalate to Microsoft on its behalf?
3. What time have Champions agreed to give, and what is outside their boundary?
4. What is the agreed route for suspected data exposure, and who owns it out of hours?
5. Where do ideas for shared prompts, Cowork tasks or agents go, and who responds?
6. How will repeated questions reach the owners of guidance, scenarios and training?

Required inputs

• The approved-use guidance and the readiness assessment from copilot-adoption:adoption-readiness.
• The service desk's current scope, tooling and escalation routes, from the IT service owner.
• The Champions boundary and time commitment from champions:champion-programme-design, where a programme exists.
• The security route for suspected data exposure, agreed with security-privacy.
• The opportunity intake route from opportunity-management:problem-framing or the CoE.

If no data exposure route exists, the support model cannot be signed off and the launch is blocked. If no intake route exists, record it as a gap; otherwise ideas will accumulate with Champions and the service desk.

Decision framework

Design tiers by type of need, not by seniority of the person answering.

Triage each contact into one category and route it. Answer-quality reports need particular care.

Practitioner approach

Start from the needs, not the org chart. List the questions people are likely to ask in their first months, using support logs from pilots, Champion feedback and the readiness findings. Group them into the categories above and decide where each should go. Most organisations find that the largest category is how-to, which the service desk is least able to answer.

Build self-help first, because it scales and is available at three in the morning. A short getting-started page, the approved-use guidance in plain words, starting scenarios by audience, a known-issues list and the routes for everything else will deflect many contacts. Give it an owner and a review rhythm; stale self-help creates more contacts than it prevents.

Agree the service desk's part explicitly. Give the desk knowledge articles for access and common faults, a triage script that recognises how-to questions and routes them to self-help or office hours, and clear escalation to administrators. Agree that "Copilot gave a wrong answer" is not closed as user error: the desk explains verification, records the pattern and passes repeated themes on.

Use Champions as first-line peer guidance within a boundary. They answer how-to questions in their own teams and model good practice, inside the time their managers agreed. They do not handle faults, access, data concerns or approvals. Make the boundary visible to users as well as Champions, so people know what to ask whom.

Make the security route unmistakable. Every user should know, from onboarding onwards, how to report something they should not have seen. The route must be fast, owned out of hours where needed, and connected to whoever manages permissions remediation. Test it before launch with a walk-through.

Size capacity for the launch peak, then for steady state. Contacts are highest in the weeks after each wave. Add office hours during those weeks rather than stretching Champions, and agree with the service desk how it will flex.

Close the loop. Review contact themes regularly with the adoption lead, guidance owners and the service desk. Repeated how-to questions mean the self-help or onboarding is weak; repeated answer-quality reports may point to knowledge problems or unsuitable scenarios. Publish what changed, so users see that reporting helps.

Outputs

• An adoption support model on the adoption-support-model template: tiers, triage categories, routes, owners, hours, capacity plan, Champion boundary and feedback loop.
• A self-help content list with owners and review dates.
• Service desk knowledge articles and a triage script for Copilot contacts.
• A tested security route for suspected data exposure, recorded with its owner.
• The support row of the adoption-plan template completed for each wave.

Microsoft platform considerations

The service desk and administrators need to know which Copilot experiences each audience has, where tenant settings are managed, and how to raise a support request with Microsoft. Admin roles, reporting and support routes change; confirm current details against references/sources.md. Support for agents built in Agent Builder or Copilot Studio follows each agent's own support route, set through ai-operations:ai-support-model.

Adoption considerations

Good support is an adoption lever: people experiment more when help is easy to find and does not make them feel foolish. Point every onboarding message and reinforcement nudge at the same simple set of routes.

Knowledge considerations

Self-help content and service desk articles are knowledge assets that need owners, versions and review dates. Repeated answer-quality reports on organisational content should go to knowledge-management:knowledge-gap-analysis.

Security and privacy considerations

The data exposure route is the critical part of this model. It must be known to every user, fast, owned and connected to permissions remediation. Contact records may contain personal data or sensitive content; keep only what is needed and restrict access. Data protection questions end with the organisation's DPO.

Responsible AI considerations

Reports of harmful, biased or misleading output are taken seriously and routed to the right owner, never dismissed as user error. Users are reminded that they remain accountable for output they use, and support staff explain verification rather than promising accuracy.

Evaluation requirements

Not applicable as solution evaluation, because this skill designs a support service rather than an AI solution. The model is tested before launch by walking sample contacts from each category through their routes.

Value measures

Owned by the adoption lead with the IT service owner, with baselines from the first wave: contacts by category, share resolved through self-help or peers, time to resolve access issues, data concerns handled within the agreed time, and repeat themes fixed at source. Reported at team or audience level, never for individuals.

Scale notes

Starter

A one-page self-help guide, the service desk briefed with a few knowledge articles, a named security contact, a weekly office hour and a simple route for ideas.

Scale

Tiered model with triage script, Champions inside a published boundary, office hours flexed around waves, a tested security route and a monthly theme review.

Enterprise

A consistent model across regions with local self-help, service desk integration, follow-the-sun security handling, admin escalation to Microsoft and theme reporting to the CoE.

Hand-offs

• To ai-operations:ai-support-model for the support of individual agents and AI solutions.
• To learning-and-skills:office-hours to run office hours as a service.
• To champions:champion-programme-design when the boundary or time commitment needs revisiting.
• To copilot-adoption:adoption-reinforcement with repeated themes that need a refresher.
• To security-privacy for the data exposure route and its testing.

Reviewer gates

security-privacy reviews the data exposure route and the handling of contact records before the first launch wave. Its absence is blocking for launch at any tier; other findings are advisory unless they leave sensitive content exposed.

Failure modes

• Every Copilot contact goes to the service desk, which closes how-to questions as out of scope.
• Champions become the default help desk, burn out and leave the programme.
• Users cannot find the route for suspected data exposure, so incidents surface late or not at all.
• Answer-quality reports are dismissed, and genuine knowledge or scenario problems persist.
• Self-help goes stale and creates more contacts than it prevents.

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

• Launch without a known, tested route for suspected data exposure.
• Make Champions responsible for faults, access, data concerns or approvals.
• Close answer-quality reports as user error without recording the pattern.
• Report support contacts by named individual.