Buying the licences is the easy part. About three in a hundred Microsoft 365 users worldwide have a paid Copilot seat, and plenty of those are unused.
Copilot programmes rarely fail on technology. They fail because licences were distributed to whoever asked, people tried it twice with vague prompts, got mediocre answers and stopped, and at renewal nobody could demonstrate that anything had improved. Low prompt literacy, absent change management and invisible ROI are three of the four reasons adoption is reported to stall. All three are avoidable, and all three are much cheaper to address before deployment than after.
Eight things that decide whether people keep using it.
Adoption is a behaviour problem wearing a technology costume. These are the levers that matter, and the first two are worth more than the other six combined because they determine whether anybody has a good first week.
Choosing the cohort by workload, not by enthusiasm
The people who benefit most are those doing high volumes of document synthesis, meeting follow-up and drafting: bid and proposal teams, middle management, HR, legal, finance reporting and customer-facing roles with heavy written output. The engineering team who asked first frequently benefits least, because their work is already tool-supported. Selecting on workload rather than interest is the single highest-leverage decision in a rollout.
Scenario-based enablement, not a product demonstration
A generic demonstration produces polite interest and no behaviour change. What works is sitting with a cohort and building prompts for the specific recurring tasks they actually do, the weekly report, the meeting summary, the standard client update, the tender response section. People adopt a tool that solved something on their desk this week, not one that looked impressive in a session.
Prompt literacy as a taught skill
Low prompt literacy is a named reason adoption stalls, and it is the cheapest to fix. Most people ask a vague question, receive a generic answer and conclude the tool is overrated. Teaching context, specificity, iteration and the habit of giving it source material changes results immediately. It is perhaps an hour of instruction with a lasting effect, and skipping it wastes the licence.
A baseline captured before anyone starts
Decide which specific tasks you expect to get faster and measure them before deployment. Time to first draft of a recurring report, turnaround on a standard document, time to circulate meeting actions. This takes very little effort in advance and is impossible to reconstruct afterwards, because nobody remembers how long things used to take and self-reported savings are unreliable in both directions.
Champions inside each function
Adoption spreads laterally far better than it spreads downward. One credible person per function who uses it well, is willing to show colleagues, and can answer the small questions that stop people, outperforms any amount of central communication. Identify them during the pilot and give them a little extra time and access rather than announcing them as a programme.
Staged expansion with enablement attached to each stage
Expanding by handing out licences repeats the original mistake at scale. Each cohort needs the same scenario work the pilot got, which is why expansion should be paced to your capacity to enable rather than to procurement. A slower rollout with enablement reaches higher sustained usage than a fast one without.
Removing the small blockers that stop people quietly
Meetings not recorded or transcribed so there is nothing to summarise. Documents in formats Copilot handles poorly. Content scattered across personal drives rather than in SharePoint where it can be grounded. These are unglamorous and they are why an individual quietly stops after week two without ever raising a complaint.
A renewal case built from evidence
Invisible ROI is why programmes get quietly shelved. Usage telemetry alone is not a value case, because it shows activity rather than outcome. The credible case combines the baseline you captured, the measured change, and a small number of specific accounts of work that is now done differently. Assembled through the pilot, not written in the week before renewal.
What good looks like
Four rollouts, and what made the difference.
Anonymised patterns from adoption work, chosen because each one turned on a different lever. None of them turned on the technology, which is the point.
Professional services
Challenge
Licences went to the leadership team and the technology group. Usage was high in week one, negligible by week four, and nobody could say what had changed.
What we did
Reassigned the cohort to the proposal team and the client reporting function, and built prompts around their two recurring document types rather than demonstrating features.
Outcome
Sustained daily use in the new cohort, and a renewal case built on turnaround time for a document type the business already tracked.
Manufacturing
Challenge
Widespread reports that the answers were generic and unhelpful, and a growing internal view that the product was overhyped.
What we did
One hour of prompt literacy per team covering context, specificity, giving it source material, and iterating rather than accepting a first answer.
Outcome
The same people describing the same tool as useful within a fortnight, with no change to licensing or configuration.
BFSI back office
Challenge
Meeting summarisation was the headline use case and it was not working for most of the organisation.
What we did
Found that recording and transcription were off by default for most meeting types, so there was nothing to summarise. Changed the default and communicated it.
Outcome
The most requested capability started working, which recovered credibility for the wider programme more than any communication would have.
Healthcare group
Challenge
Renewal approaching, genuine enthusiasm from users, and no way to answer the finance question about whether it was worth continuing.
What we did
Too late for a clean baseline, so we reconstructed a partial one from a document type with existing turnaround records and paired it with structured user accounts.
Outcome
Renewed, with a proper baseline established for the expansion cohort so the next conversation would not need reconstructing.
Why bring us in
We do the unglamorous half.
We find the blockers before they cause silent abandonment
Meetings not being recorded, content sitting outside SharePoint where it cannot be grounded, document formats that produce poor results. These never appear as complaints, they appear as usage quietly declining, and they are straightforward to find and fix if somebody looks in week two rather than at renewal.
We build enablement from your work, not from a deck
Our sessions start by asking a cohort what they produce every week, then building prompts for exactly that. It is less polished than a standard training package and considerably more effective, because people leave with something that solves a task on their actual desk.
We can fix the tenant issues we find
Adoption problems frequently turn out to be configuration problems: recording defaults, content location, permissions, labels. Because we run these tenants, the fix happens in the same engagement rather than becoming a recommendation handed to somebody else with a queue.
We will tell you when the answer is fewer licences
Sometimes the honest conclusion is that a cohort does not benefit and the seats belong elsewhere, or that the programme should pause until readiness work is finished. We would rather say that and keep a smaller engagement than help you expand something that will be cancelled.
Who benefits most
Where the value concentrates, by function.
Bid, proposal and pre-sales
High volumes of structured written output assembled from existing material, which is close to the ideal use case. Usually the strongest and fastest result in any organisation that has this function.
Middle management
Meeting follow-up, status reporting and drafting, all of which are recurring and formulaic. Frequently overlooked in cohort selection because they do not ask for tools.
Finance and reporting
Recurring commentary and narrative around numbers that already exist. Also a function that already measures its own turnaround, which makes the baseline straightforward to establish.
HR and internal communications
Policy drafting, candidate and employee correspondence, and summarising long documents into something people will read. Sensitive content, so this cohort depends on the governance work being done first.
Clinical and professional administration
Documentation load rather than clinical judgement: correspondence, summaries and reporting. Value is real and the governance bar is higher, so sequencing matters.
Where it helps least
Deep engineering, hands-on operations and shop-floor roles, where the work is not document-shaped. Being honest about this early protects the credibility of the whole programme.
Prompt literacy
The six habits we teach, and why each one changes the result.
This is the substance of the hour that turns a disappointed user into a habitual one. None of it is complicated, and almost nobody works it out unaided, which is exactly why untrained rollouts produce the verdict that the tool is overrated.
Say who you are and what you are producing
The most common failure is asking a question with no context, which produces a generic answer because a generic answer is the only reasonable response. Stating your role, your audience and the artefact you are creating changes the output immediately.
Name the audience, since a board note and a team update differ entirely
Say what the output is for, not only what it should contain
This single habit accounts for most of the improvement people notice
Point it at your source material
People ask questions expecting it to find everything relevant unaided. Referencing the specific documents, the meeting, or the thread you want it to work from transforms both accuracy and usefulness, and it is what distinguishes Copilot from a general assistant.
Reference documents explicitly rather than hoping it locates them
Grounding in your own content is the whole point of the product
Content must be in SharePoint or OneDrive to be reachable
Be specific about format and length
An unspecified format produces an unpredictable one, and people then judge the tool on a mismatch they created. Asking for five bullets, a two paragraph summary or a table with named columns removes most of the editing burden.
State length, structure and tone explicitly
Ask for the format your process actually needs downstream
Reusing a prompt that produced a good format is a legitimate technique
Iterate rather than accepting the first answer
Most people treat it as a single-shot tool, get an approximately right answer and either use it unedited or abandon it. Refining across two or three exchanges is where the quality actually appears, and it needs saying out loud because nobody assumes it.
Ask it to revise a specific aspect rather than regenerating wholesale
Tell it what was wrong with the last answer, not just what you want
Three exchanges usually beats one long, elaborate prompt
Ask it to show its working when accuracy matters
Requesting the sources it drew on, or asking it to explain how it reached a conclusion, both improves reliability and gives you something checkable. This matters most for anything going to a client or a regulator.
Ask which documents an answer came from and verify the important ones
Verification is a professional obligation, not a lack of trust in the tool
Never send output externally without reading it properly
Use it at the start of a task, not at the end
People habitually write a document and then ask for a polish, which is the lowest-value moment to involve it. The gain is largest at the blank page, where getting to a structured draft in two minutes changes how the whole task feels.
Blank page to first draft is where the time actually goes
Polishing a finished document returns very little
This habit alone often doubles the perceived usefulness
Ask it to interrogate you before it answers
Telling it to ask clarifying questions first, rather than producing an answer immediately, is a technique almost nobody discovers unaided and which reliably produces better output on anything non-trivial.
Works well for planning, structuring and analysis tasks
Surfaces assumptions you had not stated and did not realise mattered
Turns a single exchange into a short and much more useful conversation
Build a small personal library of prompts that worked
The habit that separates sustained users from people who tried it. A handful of saved prompts for recurring tasks converts a novelty into part of the working week, and sharing those within a team is how adoption spreads laterally.
Save the prompt, not just the output, when something works well
Four or five good ones covering your recurring work is enough
Team-level sharing of prompts outperforms any central training material
Two rollouts
Licence distribution against a managed adoption programme.
Both put Copilot in front of people. One produces sustained use and a renewal case; the other produces a spike, a decline, and a difficult conversation with finance about eleven months later.
Feature
Dimension
Licence distribution
Managed adoption
Who gets it first
Whoever asked, usually leadership and IT
A cohort chosen for document-heavy workload
Enablement
A launch email and a recorded demonstration
Scenario work on the cohort actual recurring tasks
Prompt skills
Assumed
Taught, in about an hour, with immediate effect
Blockers
Surface as silent abandonment
Found in the pilot and removed
Baseline
None
Captured before the first licence is assigned
Usage at week four
Declining sharply from a week one spike
Steady, and spreading laterally through champions
Expansion
More licences, same result
Paced to enablement capacity, each cohort supported
The renewal conversation
Anecdotes against an invoice
Measured change against a documented baseline
Capture the baseline before you deploy, or accept you will be arguing from anecdote.
This is the single most common regret in the Copilot programmes we are asked to rescue. Measuring afterwards does not work: people do not remember how long tasks used to take, self-reported time savings are unreliable in both directions, and usage telemetry shows activity rather than outcome. A baseline needs perhaps a day of preparation and it has to happen before the first licence is assigned. Everything else in a rollout can be corrected later. This one cannot.
Pick three or four tasks you genuinely expect to get faster, and be specific
Prefer tasks the business already measures, since that data is trusted
Record the current state for the pilot cohort only, which keeps it small
Agree in advance what result would justify expansion, and what would not
The engagement
Five stages, and the first two happen before any licence is assigned.
1
Select the cohort by workload
Interviews across functions to find where document synthesis, meeting follow-up and drafting actually concentrate. The output is a recommended pilot cohort, which is frequently not the group who requested the tool, and an honest note about which functions will benefit least.
2
Capture the baseline
Three or four specific tasks you expect to improve, measured for the pilot cohort before anything is deployed, preferring tasks the business already tracks so the data is trusted. Agreement in advance on what result would justify expansion and what would not.
3
Remove the blockers
Meeting recording and transcription defaults, content location, document formats, and whatever else would cause a quiet failure in week two. This is a short technical exercise with a disproportionate effect on whether the first fortnight goes well.
4
Enable with scenarios, not features
Sessions built around the cohort actual recurring work, prompt literacy taught explicitly, and a small number of champions identified and supported. Followed by a check-in in week two, which is when silent abandonment starts and when it is still recoverable.
5
Measure, then expand at the pace you can enable
Compare against the baseline, assemble the value case from measurement plus specific accounts, and expand cohort by cohort with the same enablement each time. Expansion paced to your capacity to support it rather than to licence availability.
The week two check-in
The questions that catch a rollout before it fails quietly.
Week two is when people either find a task Copilot genuinely helps with or stop using it without telling anybody. These are the questions we ask, and each one maps to a fix that is still cheap at this point and expensive at renewal.
Is it working technically
Are meetings being recorded and transcribed?
The commonest silent failure by a distance
Is the content people need actually in SharePoint?
Personal drives cannot be grounded properly
Are transcripts good enough to summarise usefully?
Capture the baseline before you hand out a single licence.
It takes about a day, it is the one thing in a Copilot rollout that cannot be fixed retrospectively, and it is the difference between a renewal conversation built on evidence and one built on anecdote. Remote-first from Hyderabad, serving all of India.