Skip to main content
Copilot adoption, India

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.

Book a Copilot adoption planSee what drives adoption
Microsoft
Microsoft
365 Copilot
Cloud Solution Partner
  • 3.3%Of M365 users hold a paid seat
  • Baseline firstIt cannot be reconstructed later
  • By roleNot by who asked loudest
  • ScenariosNot a product demonstration
What actually drives adoption

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 ITA cohort chosen for document-heavy workload
Enablement
A launch email and a recorded demonstrationScenario work on the cohort actual recurring tasks
Prompt skills
AssumedTaught, in about an hour, with immediate effect
Blockers
Surface as silent abandonmentFound in the pilot and removed
Baseline
NoneCaptured before the first licence is assigned
Usage at week four
Declining sharply from a week one spikeSteady, and spreading laterally through champions
Expansion
More licences, same resultPaced to enablement capacity, each cohort supported
The renewal conversation
Anecdotes against an invoiceMeasured 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. 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. 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. 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. 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. 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?
    Audio setup determines summary quality
  • Has anybody hit an error they did not report?
    People abandon rather than raise a ticket

Is it working for them

  • What did you use it for this week?
    A vague answer means it has not landed yet
  • What did you try that did not work?
    Usually a prompt problem, fixable in minutes
  • Has it saved you time on anything specific?
    Specific beats enthusiastic as a signal
  • Would you notice if it were taken away tomorrow?
    The most honest adoption question there is

Is it spreading

  • Has anyone shown a colleague something useful?
    Lateral spread is the strongest adoption signal
  • Are there prompts worth sharing with the cohort?
    Collect them, they beat central training material
  • Has a natural champion emerged in this group?
    Support them rather than announcing them
  • Is anyone quietly not using it at all?
    Find out why now, not at renewal
Questions we get asked

Copilot adoption, answered plainly.

Usually three things together, and none of them are the product. The licences went to whoever asked rather than to the people whose work is document-shaped. Nobody was taught how to prompt, so early results were generic and people concluded it was overrated. And a small technical blocker went unnoticed, most often that meetings were not being recorded or transcribed so the headline use case silently did not work. All three are recoverable. We normally start by finding the blocker, then re-selecting the cohort, then running scenario-based enablement, and usage usually recovers within a few weeks without any licensing change.

People whose week contains a lot of writing, summarising and assembling documents from existing material. In most organisations that means bid and proposal teams, middle management, HR, legal, and finance reporting. It is frequently not the engineering group, who tend to ask first and benefit least because their work is already well tooled. Choosing by workload rather than enthusiasm is the highest-leverage decision in the whole rollout, and it is also the one most likely to create a political conversation, which is worth having early rather than after a failed pilot.

Decide before you deploy which specific tasks you expect to get faster, and measure them now. Good candidates are things the business already tracks: turnaround on a standard document type, time to circulate meeting actions, time to first draft of a recurring report. Capture the current state for the pilot cohort only, which keeps the exercise small. Measuring afterwards does not work, because people do not remember how long things used to take and self-reported savings are unreliable. Usage telemetry is not a substitute either, since it shows activity rather than outcome.

With enablement, most of a cohort is using it habitually within two to three weeks, and the pattern is that the first week is exploratory, the second is where people either find a task it genuinely helps with or quietly stop, and the third is where habit forms. That second week is the critical one and it is why we schedule a check-in then rather than at the end of a month. Without enablement the pattern is different: a spike in week one from curiosity, then a steep decline, with a small number of self-taught users continuing and the rest of the licences unused.

It is natural language and it is not mind reading, and that gap is where most disappointment comes from. People ask a broad question, get a broad answer, and conclude the tool is not very good. Teaching four things changes results immediately: give it context about who you are and what you are producing, be specific about format and length, point it at the source material rather than expecting it to find everything, and iterate rather than accepting the first answer. That is about an hour of instruction. Low prompt literacy is one of the four commonly cited reasons adoption stalls, and it is easily the cheapest of them to address.

No, for two independent reasons. First, enablement is what makes it stick, and enablement has a capacity limit, so expanding faster than you can support means later cohorts get the launch email treatment that fails. Second, if your readiness work is still in progress, a wide rollout increases the chance somebody surfaces something they should not before remediation catches up. Staged expansion paced to your enablement capacity consistently reaches higher sustained usage than a fast rollout, and it gives you the option to stop if the value case is not appearing.

The ones that never get reported as problems. Meeting recording and transcription switched off by default, so summarisation produces nothing and people assume the feature does not work. Content sitting in personal drives and email rather than in SharePoint, so there is little to ground answers in. Documents in formats or structures that produce poor results. Cameras and mics configured such that transcripts are low quality. Each is minor, each is quick to fix, and each causes an individual to quietly stop using the tool in week two without ever raising a ticket. Finding them is why we check in early rather than at renewal.

Yes, and the ordering is not negotiable in our view. If oversharing has not been remediated, a well-adopted rollout means more people asking more questions against an estate that will surface things it should not, and the programme gets paused at exactly the point it was working. The sequence we recommend is readiness assessment, then remediation of the serious exposure, then a pilot with a grounding boundary if cleanup is still running, then adoption work on that pilot. Adoption effort spent before readiness is frequently wasted, because the pause resets the momentum you built.

Habitual use for a small number of specific recurring tasks, rather than broad exploratory use across everything. A finance manager who uses it every month for reporting commentary and nothing else is a success. Somebody who tried twenty things once and does none of them regularly is not, however enthusiastic they sounded. This matters for how you read your telemetry: breadth of feature use is a weak signal, and repeat use of the same workflow by the same people is a strong one. It also tells you what to teach the next cohort, because the workflows that stuck are the ones worth demonstrating.

Mostly yes. Cohort selection interviews, baseline capture, blocker remediation and the measurement work are all remote, and enablement sessions work well over video for teams used to remote training. The one place a visit genuinely helps is enablement for groups who are not comfortable with remote workshops, which in our experience is more common in operations and administrative functions than in technology teams. We are based in Gachibowli, Hyderabad and travel where it makes the sessions land better. Initial enquiries get a reply within 4 business hours.
Related reading

What comes before this.

Copilot readiness

The tenant work that should precede adoption: oversharing, labels, identity hygiene and pilot design.

Learn more

Copilot data governance

Data residency, sensitivity labels, acceptable use and the DPDP intersection, which is the first blocker to clear.

Learn more

Copilot vs ChatGPT Enterprise

Which assistant fits your estate, and why the answer usually follows where your work already lives rather than which is better.

Learn more
References

Official documentation

Next step

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.

Book a Copilot adoption planStart with the readiness assessment

Related Services

Explore more solutions that work great with this service

Copilot Readiness

Assess what Copilot would surface before it surfaces it

Learn more

Microsoft Copilot

AI-powered productivity with Copilot

Learn more

Copilot Data Governance

Residency, labels, retention and the DPDP intersection

Learn more

M365 Apps

Deploy and manage Microsoft 365 applications

Learn more