Templates › Microsoft 365 Copilot rollout plan
Microsoft 365 Copilot rollout plan
Template id: copilot-rollout-plan
Responsible skill: m365-copilot:m365-copilot-rollout. Technical gates are evidenced with m365-copilot:copilot-technical-readiness and work context gates with m365-copilot:work-context-readiness. People-side launch activities for each wave sit in the adoption-plan, owned by copilot-adoption:launch-plan.
Use this plan for one rollout of licensed Microsoft 365 Copilot, in waves. Every fact the organisation must supply is marked [To confirm: ...]; replace the marker when the fact is confirmed, and never fill it with a guess. Example rows are fictional and are there to be replaced or deleted. Licence quantities, entitlements and prerequisites come from the licence owner and the current source records, never from memory. Usage in this plan is reported at team, role or wave level only, never for named individuals.
1. Summary
| Field | Entry |
|---|---|
| Rollout name | [To confirm: name] |
| Rollout owner | [To confirm: name and role] |
| Executive sponsor | [To confirm: name and role] |
| Licences available now and later | [To confirm: quantities and dates, confirmed by the licence owner] |
| Scope (business units, regions) | [To confirm] |
| Link to adoption plan | [To confirm: location of the adoption-plan] |
| Plan status | Draft / Agreed / In progress / Closed |
| Last reviewed | [To confirm: date] |
2. Candidate groups and scoring
Score each candidate group High, Medium or Low on each criterion. Start with groups strong on all four.
| Group (role or team) | Approximate size | Scenario strength | Work context condition | Leadership and support | Risk profile | Proposed wave |
|---|---|---|---|---|---|---|
| Fictional example: Regional operations managers | Fictional example: 40 | High | Medium | High | Low sensitivity | 1 |
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
Reasons for any group placed early despite a Low score: [To confirm]
3. Wave plan
| Wave | Groups | Licence assignment group | Planned start | Planned review | Wave owner |
|---|---|---|---|---|---|
| 1 | [To confirm] | [To confirm: directory group name] | [To confirm] | [To confirm] | [To confirm] |
| 2 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
4. Entry gates per wave
A wave does not start until every gate is Ready, or Ready with conditions accepted in writing by the rollout owner.
| Gate | Evidence | Wave 1 | Wave 2 | Owner |
|---|---|---|---|---|
| Technical readiness for the wave's segment | Readiness record and settings decision log | [To confirm: Ready / Conditions / Not ready] | [To confirm] | [To confirm] |
| Work context readiness for each group | Readiness record per team | [To confirm] | [To confirm] | [To confirm] |
| Sensitive content and oversharing findings closed or accepted | Reviewer outcome or written acceptance | [To confirm] | [To confirm] | [To confirm] |
| Priority scenarios tested with the group | Scenario cards marked usable | [To confirm] | [To confirm] | [To confirm] |
| Onboarding sessions booked and managers briefed | Adoption plan entries | [To confirm] | [To confirm] | [To confirm] |
| Service desk briefed on scenarios and known limits | Briefing record | [To confirm] | [To confirm] | [To confirm] |
Open conditions:
| Condition | Wave | Fix | Owner | Due date | Accepted by |
|---|---|---|---|---|---|
| Fictional example: Two project sites shared with all staff | 1 | Site owners restrict access | Fictional example: Operations site owner | [To confirm] | [To confirm] |
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
5. Licence allocation and reallocation rules
| Rule | Entry |
|---|---|
| Allocation basis (role, scenario, readiness) | [To confirm] |
| How people request or release a licence | [To confirm] |
| How uptake is reviewed (team or role level) | [To confirm] |
| Position on person-level activity data, agreed with the data protection lead and HR | [To confirm: agreed position and date, or "not used"] |
| Approved by | [To confirm: names, roles and dates] |
Person-level data is never used to judge performance. Licence entitlement and commercial questions go to the Microsoft licensing guide or a licensing partner.
6. Exit criteria per wave
Agree these before the wave starts.
| Criterion | Measure and level | Target | Result at review |
|---|---|---|---|
| Priority scenarios in use across the group | [To confirm: measure, team level] | [To confirm] | [To confirm] |
| Support questions stabilised | [To confirm: ticket trend for the wave] | [To confirm] | [To confirm] |
| Feedback reviewed and guidance updated | [To confirm: evidence] | [To confirm] | [To confirm] |
| No open blocking findings | Reviewer record | None open | [To confirm] |
7. Wave review record
| Wave | Review date | Exit criteria met? | What changed for the next wave | Decision | Decided by |
|---|---|---|---|---|---|
| [To confirm] | [To confirm] | Yes / Partly / No | [To confirm] | Proceed / Proceed with conditions / Pause | [To confirm] |
8. Risks and dependencies
| Risk or dependency | Effect on rollout | Mitigation | Owner |
|---|---|---|---|
| Fictional example: Oversharing remediation backlog not cleared before wave 2 | Wave 2 delayed | Prioritise sites used by wave 2 groups | Fictional example: SharePoint service owner |
| [To confirm] | [To confirm] | [To confirm] | [To confirm] |
9. Approval
| Role | Name | Decision | Date |
|---|---|---|---|
| Rollout owner | [To confirm] | [To confirm] | [To confirm] |
| Executive sponsor | [To confirm] | [To confirm] | [To confirm] |
| IT lead | [To confirm] | [To confirm] | [To confirm] |
| Security and privacy reviewer | [To confirm] | [To confirm] | [To confirm] |
Credit: Template from CopilotForge by Simon Foote (https://github.com/SimonFoote-greensparx/CopilotForge), licensed under CC BY 4.0. Keep this credit when you share or adapt the template; in your own completed document you may keep it as a footer or remove it.