You assigned the licences. Someone from IT ran a demo on a Thursday. A handful of people tried it, found it impressive, and then quietly went back to the way they've always worked.
Three weeks later, usage metrics have flatlined. Nobody complained. Nobody submitted a ticket. Copilot just stopped being part of anyone's day.
We've seen this pattern across implementations in the UK, UAE, and Southeast Asia, in businesses running anywhere from 50 to 3,000 seats of Dynamics 365. And the cause is almost never the technology.
The Real Problem Isn't Adoption. It's Integration.
Most Copilot rollouts are designed backwards.
Organisations focus on what Copilot can do, summarise emails, draft documents, surface data insights, and then ask users to find their own way to apply it. That's not implementation. That's a product demo with a licence key attached.
What we've found, consistently, is that the gap between "people tried it" and "people use it daily" is almost entirely a workflow integration problem. If Copilot doesn't have a specific job to do inside a process someone already owns, it becomes optional. And optional tools don't survive week three.
This matters more in D365 environments than in general productivity deployments. Dynamics 365 users aren't operating in one unified workspace, they're moving between Sales, Finance, Customer Service, and Field Service, each with its own process logic, its own data, and its own definition of a "repetitive task." A Copilot prompt that's useful in Customer Service (summarising a case thread before escalation) has no relevance to someone reconciling purchase orders in Finance. A blanket rollout treats both users identically, and then wonders why uptake is inconsistent.
Who Owns This, And Why the Wrong Team Usually Does
Here's the most common structural mistake: Copilot adoption gets handed to IT.
IT teams are the right owners of deployment. They're the wrong owners of adoption. The people who know which tasks are killing time, the repetitive status updates, the manually assembled reports, the reformatted data pulled from three different modules, are the operations managers and team leads doing those tasks every day. They're rarely in the room during rollout planning.
The implementations that work are the ones where those two groups are talking before a single licence goes live. IT brings the infrastructure and security constraints. Operations brings the workflow intelligence. Neither group can do the other's job.
In one mid-market deployment we supported, the sales team had been manually pulling weekly pipeline summaries from D365 Sales into a spreadsheet, formatting them, and emailing them to leadership, every Monday, around 45 minutes per person. That task was the obvious Copilot use case. It was also the use case nobody mentioned in the initial rollout planning, because no one from the sales ops team was in the room.
Workflow Mapping: The Step That Gets Skipped
Before you configure anything, before you build a training deck, before you announce the rollout in a company all-hands, map the workflows.
It doesn't have to be elaborate. Run a two-hour session with each department, ask three questions, and document what comes back:
- What does your team spend the most time on in a given week?
- Which of those tasks feel like the same thing done over and over?
- Which tasks require consistency, same structure, same format, same logic every single time?
In D365 contexts, the tasks that keep surfacing are: weekly pipeline summaries in CRM, post-interaction follow-up drafts in Customer Service, standard financial report formatting from Finance modules, and long email thread summaries before escalation. These aren't edge cases, they're the bread and butter of most mid-market operations teams.
Once you have the list, map each task to a Copilot capability. Then cross-check with IT to confirm what's technically possible within your current licensing tier and data configuration. Build a simple tracker: task, department, estimated time currently spent, proposed Copilot action, expected time saving. It doesn't need to be sophisticated. It just needs to exist, because without it you're running a pilot with no baseline to measure against.
What a Useful Pilot Actually Looks Like
The sweet spot for a Copilot pilot is deliberately narrow: one or two business functions, ten to twenty users, four to six weeks. Narrow enough to produce clean signal. Broad enough to be representative.
Define success before day one. The metrics most organisations track, number of Copilot interactions, feature usage frequency, tell you whether people are clicking. They tell you almost nothing about whether the tool is changing how work gets done. The metrics worth tracking are:
- Time saved per specific task (compare completion times before and after, on the same tasks)
- Error or rework rate on outputs Copilot supports
- User sentiment at week two and week four, a five-question survey takes ten minutes and surfaces things usage data won't
- Volume of tasks completed without escalation or manager review
Also pay close attention to what isn't working. If users are rewriting every Copilot output before they send it, that's a signal worth investigating. Either the prompt guidance needs improving, or that particular use case isn't the right fit. During one pilot we ran for a customer service team, roughly 60% of Copilot-drafted email responses were being significantly edited before sending. The issue wasn't the quality of the outputs, it was that the tone guidance embedded in the system prompt hadn't been aligned to the company's existing service standards. That took a day to fix and pushed rewrite rates down to under 15%.
End the pilot with a proper debrief. Not just numbers. Talk to the users. What did they actually use it for? What did they avoid? What would make them use it more often?
Scaling Without Breaking What You Built
The pilot gives you two assets: validated use cases, and internal advocates.
Internal advocates, users who genuinely found Copilot useful and can speak to it in the language of their own team, are more credible than any IT announcement or management directive. Before you roll out to the full organisation, identify two or three advocates per department and find them a platform. A ten-minute internal session, a short post in your company's Viva Engage feed, a paragraph in an internal newsletter. Make the use case visible and credible to peers, not just to leadership.
On the structural side, scaling requires prompt libraries built by department, not generic walkthroughs, but actual prompts mapped to actual tasks. It requires workflow documentation to be updated so Copilot's role in each process is written down somewhere. It requires a feedback loop so users have somewhere to send output quality issues. And it requires training that's tied to specific use cases, not to the feature list.
One practical note: don't push to full rollout until your pilot use cases are producing stable, repeatable outputs. Scaling a tool that's still producing inconsistent results doesn't accelerate adoption, it accelerates disengagement, and that's much harder to recover from than a slower rollout.
What Good Looks Like at Week 4, and What It Looks Like at Week 12
The benchmarks shift as adoption matures. The mistake is holding week-twelve expectations at week four, or week-four expectations at week twelve.
At week four, you're looking for habit formation. Consistent use of two or three specific tasks per participating team. Measurable time savings on those tasks. User sentiment that's neutral-to-positive. Transformation is not the goal at week four. Repetition is.
At week twelve, you're looking for integration. Copilot should be part of documented workflows, not an ad-hoc option. There should be at least one quantifiable business outcome, time saved per week, error rate down, throughput up. And you should be seeing new use cases surfaced by users themselves, not just by IT or the implementation team. That last one is the real signal. When users are finding their own applications for Copilot inside their own processes, the tool has actually found its place.
Week twelve is also when you run your first formal review. Compare the metrics from your workflow map against actual outcomes. Where is Copilot delivering? Where does the plan need adjusting? Don't skip this step, it's the one that informs everything you do next, including how you brief the next department.
The Part Nobody Talks About Enough
The organisations that get to week twelve with strong adoption, and we've seen this play out enough times now to say it with some confidence, are the ones that treated implementation as an ongoing process rather than a one-time activation event.
Copilot is a capable tool. But deployed into an unchanged workflow, it just becomes something people tried once and forgot about. The work is in the workflow mapping, the structured pilots, the change accountability, the prompt libraries, and the feedback loops. That work isn't glamorous. It doesn't make good demo footage. But it's the difference between a tool that actually gets used and a licence cost sitting idle on someone's P&L.
If you're at that week-three plateau right now, the answer isn't to push harder on adoption communications. It's to go back to the workflow map, find where the integration gaps are, and close them, one task at a time.
That's where the real work is. And it's worth doing properly.
