In this article
The right expansion decision may be a narrow rollout, a revised pilot or a pause. Decide from evidence about the work rather than pressure to increase usage.
Translate Copilot lessons into local questions
Use vendor experience to identify questions, not to predict your own results. Your documents, responsibilities, permissions and working conditions may differ.
Microsoft's account of a year with Copilot describes its experience. Read it as a first-party account with a commercial perspective, then test the relevant assumptions in your organisation.
In a hypothetical operations team, a pilot user produces useful summaries from tidy project notes. The expansion question is whether colleagues can do the same when records are incomplete, naming conventions differ and approvals are unresolved.
Write down those conditions before choosing additional users.
Check the environment people will actually use
Confirm account access, approved applications, source availability and administrative controls. Do not assume everyone receives the same experience.
Microsoft's current Copilot overview explains that licensing and grounding differ. Ask the administrator to confirm the relevant configuration for the proposed users.
Check information access as part of the workflow. A summary cannot be reliable if the source material is outdated or inaccessible. Equally, AI adoption should not become an excuse to grant unnecessary access to sensitive material.
Use your normal permission-review process. The team lead should not improvise security decisions to make a demonstration work.
Assess four kinds of evidence
Look beyond the first draft. Inspect output quality, full-task effort, repeatability and the consequences of mistakes.
| Evidence | Practical question |
|---|---|
| Quality | Does the result preserve the important facts and exceptions? |
| Effort | What preparation, checking and correction are required? |
| Transferability | Can a second user follow the documented method? |
| Consequence | What happens if an error reaches the next person? |
Include examples that did not work. A pilot report containing only its strongest outputs gives an incomplete basis for expansion.
Ask reviewers to explain how they checked the work. If they simply accepted it because the original pilot user was confident, the review process needs attention.
Identify who will maintain the practice
Assign an owner for the procedure, someone for technical issues and a route for information-handling questions. These may be different people.
Give users a clear way to report an unsupported claim, missing source or unexpected access request. Define when they should stop rather than attempt a workaround.
Do not leave the enthusiastic pilot participant responsible for every support request indefinitely. Expansion needs time, resources and a realistic account of ongoing work.
Set a review date. Instructions, source documents and product behaviour can change after the initial pilot.
Decide the rollout boundary in advance
Specify which tasks are included and excluded. “Use Copilot wherever helpful” may be too vague for colleagues who are still learning the information and review requirements.
For the hypothetical team, a narrow rollout might cover draft summaries from approved project notes, with the project owner checking every factual statement. It would not automatically include performance assessments, customer commitments or external sending.
Describe the approval point in the procedure. A draft remaining inside the team and a message sent to a client require different decisions.
Run a readiness conversation with one ordinary user
Choose someone who understands the job but did not create the pilot. Ask them to complete a representative task using the proposed instructions, then explain how they decided the result was acceptable.
Observe where they need help. They may not know which source file is current, whether a suggested action is approved or how to handle conflicting information. Those are implementation gaps, not evidence that the person lacks interest in AI.
Ask what they would do if the output looked plausible but contradicted their knowledge. A useful answer should identify a checking or escalation route. “I would trust the tool because the team approved it” suggests the scope and responsibility were not communicated clearly enough.
Include the reviewer in the same conversation. If the reviewer expects a full reconstruction of every draft, allocate that effort or revise the workflow. Do not count the generator's time saving while treating review as free.
Use the observation to make the rollout decision more precise. You may be ready to expand one well-documented task while retaining other use cases in a pilot. There is no need to classify the entire team as either ready or unready.
Make the decision reversible
Expand in a way that allows you to pause, revise instructions and return to the previous method. Keep an appropriate record of why the team adopted the workflow and what would trigger reassessment.
If the pilot has not yet demonstrated transferable value, extend the investigation rather than announcing success. A smaller, well-supported use case can be more useful than broad adoption with unclear responsibilities.
Before your next expansion meeting, prepare one page answering the four evidence questions. Include a failure example and the proposed scope.
Explore PiOfAI, the AI procedure guide and leading through change to support a rollout that people can understand and maintain.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.