Copilot in Dynamics 365 Sales Made Useful for 180 Manufacturing Sellers
Copilot was switched on and the sales team said the summaries were useless. They were right — the summaries were accurate reflections of an empty CRM. We fixed the data foundation first, then rebuilt seller workflow around it, taking record completeness from 41% to 89%.
About the Client
The Challenge
The manufacturer sold engineered products through a direct field team with long cycles — multi-visit, multi-stakeholder, often running past a year from first enquiry to purchase order. Dynamics 365 Sales had been in place for several years and was, in the sales directors' own description, a forecasting tool that sellers updated on the Thursday before the monthly review.
Copilot was switched on with the expectation that it would make the CRM worth using. The opposite happened. Asked to summarise an opportunity, Copilot returned the account name, a stage, a close date that had been pushed four times and a next step written eight months earlier. Asked to draft a follow-up email, it produced something generic, because the only grounding available was three lines of notes. Sellers concluded the AI was weak. In fact the AI was reporting accurately on a record that contained almost nothing.
The underlying pattern is consistent across sales organisations. Contacts existed but were not linked to opportunities, so Copilot could not tell who the buying group was. Emails were in Outlook and never tracked to the CRM, so months of the actual conversation were invisible. Duplicate accounts split the history of a single customer across two records. Product and competitor detail lived in attachments rather than in fields, where a summary can reach it less reliably.
There was also a sequencing mistake. Copilot had been enabled for everybody at once, across every stage of the pipeline, with a single announcement. A seller's first experience was as likely to be a late-stage renewal with a rich record as an early-stage enquiry with nothing in it — and one bad first impression settles the question for that seller for the rest of the year.
Our Approach
Copilot is a reader. Before changing anything about Copilot we changed what there was to read, and we changed how it got there so it would not decay again.
Data Foundation Assessment (Weeks 1-3)
Profiled the Dataverse tables that Copilot actually draws on for its summaries: opportunity, account, contact, connection roles, activities, notes and the product lines. Measured field-level completeness by sales stage and by seller rather than in aggregate, which is how you find that the problem is one region and two stages, not the whole team. Ran duplicate detection across accounts and contacts. Quantified the gap between emails sent to customer domains and activities recorded against those customers.
Capture at Source, Not Clean-Up (Weeks 3-7)
Cleaning a CRM once produces a clean CRM for about six weeks. We changed where the data comes from instead. Deployed the Copilot for Sales add-in in Outlook so sellers save an email to the opportunity in two clicks from the message they are already reading, and so the add-in can suggest creating the contact it does not recognise. Redesigned the opportunity form to put the fields the summary depends on above the fold and move the rest into tabs. Made the business process flow stage gates real by requiring the two or three fields that define each stage rather than fourteen.
Duplicate Resolution and Relationship Repair (Weeks 5-9)
Merged 14,000 duplicate account and contact records with a rule set agreed with sales operations, preserving activity history on the surviving record. Rebuilt connection roles on live opportunities so the buying group — economic buyer, technical evaluator, incumbent supplier contact — was modelled rather than implied in notes. This is the change that makes meeting preparation summaries useful, because it lets Copilot answer who is in the room.
Copilot Reintroduction by Sales Stage (Weeks 8-12)
Released Copilot back to sellers one workflow at a time rather than all at once, and in the order where the underlying data was strongest. Meeting preparation went first, because the repaired contact and activity data made it immediately good. Email drafting grounded in the opportunity record followed. Opportunity summaries came last, once completeness at the relevant stages was above the threshold we had set. Each release carried one worked example from the client's own pipeline.
Ongoing Hygiene and Measurement (Weeks 11-16)
Built a data-quality scorecard showing completeness and activity capture by seller and stage, reviewed in the existing pipeline meeting rather than in a new one. Automated the low-value chores — stale close-date prompts, unlinked contact alerts — through Power Automate so the sales manager was not the enforcement mechanism. Tracked Copilot usage alongside completeness, because the two move together.
Solution Architecture
Grounding surface: Dataverse opportunity, account, contact, connection role and activity tables, plus tracked Exchange email — the summary is only as wide as what is written to these
Capture: Copilot for Sales add-in in Outlook and Teams for two-click email and meeting capture, with contact suggestion on unrecognised participants
Form and process design: Summary-critical fields surfaced on the main opportunity form, stage gates cut to the minimum that defines the stage, and attachment-only detail moved into fields
Security: Copilot respects Dataverse security roles and record ownership, so territory and team boundaries hold without additional configuration
Measurement: A completeness and activity-capture scorecard by seller and stage in Power BI, reported next to pipeline rather than separately from it
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Copilot is only as good as the CRM hygiene beneath it. A summary cannot invent the buying group, the competitor or the real next step. Enabling Copilot on a thin CRM does not improve the CRM; it publicises how thin it is, to the exact audience whose goodwill you need.
Fix capture, not records. A cleansing project gives you a clean database and a decay curve. Changing where the data enters the system — the Outlook add-in, the form, the stage gate — is the only version of this that holds a year later.
Release by workflow and start where the data is strongest. Meeting preparation succeeds early because contacts and activities are usually the first things repaired. Opportunity summaries should go last. Sequencing the rollout by data readiness rather than by feature list is what protects the first impression.
Stage gates fail when they ask for too much. Fourteen required fields per stage produces fourteen fields of rubbish. Two or three that genuinely define the stage produce data you can ground a summary on and a seller who does not resent the form.
Measure completeness next to pipeline. A data-quality report in its own meeting is ignored. The same number shown beside the forecast in the review that already happens changes behaviour within two cycles. We also place Dynamics 365 CE consultants into in-flight programmes.
Related Case Studies
Copilot Not Landing With Your Sales Team?
It is usually the data, not the model. We assess what Copilot can actually read in your Dataverse and tell you what has to change before another rollout attempt.