A CRM can be technically available, fully licensed and extensively trained while still becoming an expensive address book. Users keep private spreadsheets, important updates live in email, managers chase pipeline information manually, and administrators respond by adding more mandatory fields.
That behaviour is often labelled an adoption problem. It can be. But adoption is also a design signal. If the CRM asks for data that does not help the user complete work, if stages do not match real decisions, or if handoffs to operations happen outside the system, avoiding the CRM may be rational from the user's point of view.
Microsoft's current Dynamics 365 implementation guidance puts business processes at the centre of solution design. It recommends defining end-to-end processes first and using them to guide scope, design, configuration, testing, training and ongoing operation. It also stresses using the organisation's own business language — the terms people already use to describe their work — so that requirements stay clear and misunderstandings are avoided.
People adopt a business system more readily when the system helps them perform the business process they are already accountable for.
Why workflow mismatch looks like resistance
From a manager's dashboard, an unused CRM and a resistant team look identical: missing updates, stale opportunities, empty fields. The difference only appears when you watch the work. A salesperson who logs a call in the CRM and then has to email the same notes to a colleague in delivery has done the work twice. A user asked to choose a “probability” at a stage where no customer decision has been made will pick a number that means nothing. A field engineer who cannot see the commercial history of an account will phone the account manager instead. Each of these is a sensible response to a system that does not fit the job.
The mechanism is cumulative. Every step the CRM adds without removing another becomes a small tax on the user. People pay it when they are watched and avoid it when they are busy, so data becomes patchy precisely when activity is highest.
Look for workflow mismatch
Start by mapping a real customer journey from initial enquiry to qualification, proposal, close, onboarding and service. Mark where information is created, where a decision is made, where ownership changes and where the CRM is supposed to support the step.
Then compare the configured CRM to that map. Common gaps include stages that exist only for reporting, required fields nobody can answer yet, duplicated entry between CRM and delivery systems, unclear responsibility after a sale, and notifications that create noise rather than action.
An illustrative example
This is a hypothetical scenario, not a client case. A professional services firm configures its CRM with six pipeline stages taken from a vendor template. In practice, its deals turn on two events the template does not represent: a scoping workshop and a security review by the client. Salespeople therefore move deals between stages arbitrarily, managers forecast from a separate spreadsheet, and the delivery team learns about won work from a forwarded email. More training would teach people to use six stages that do not describe their work. Replacing those stages with ones that mirror the real decisions, and triggering a delivery handoff from the win, would remove the reasons to work around the system.
Do not solve every problem with mandatory fields
Required data is useful when the process genuinely needs it at that point. It becomes friction when fields are mandatory simply because management wants complete reports. Users then invent placeholder values, delay updates, or move work elsewhere.
Instead, tie each required field to a decision or downstream dependency. Ask who uses it, when they need it, what happens if it is missing, and whether the value can be captured automatically from another system.
Make the CRM the easiest path
Adoption improves when the system removes work. A well-designed CRM can prefill information, trigger tasks, route ownership, surface context, reduce duplicate entry and make the next action obvious. A poorly designed CRM adds administrative labour after the “real work” has already happened somewhere else.
Training still matters. Microsoft's adoption guidance explicitly treats training, change management and adoption as ongoing processes rather than one-off go-live events, and describes adoption as the link between technology implementation and business outcomes. But training cannot permanently compensate for a workflow that is badly represented in the system.
Warning signs
- Pipeline reviews depend on a spreadsheet that is reconciled to the CRM by hand.
- Fields contain placeholder values such as dots, “TBC” or default dates.
- Deals jump several stages at once, or close without passing through intermediate stages.
- Handoffs to delivery, finance or support happen by email or chat rather than from the record.
- New mandatory fields are added after each reporting complaint.
- One team uses the CRM well while another barely touches it.
Measure behaviour and process outcomes
Login counts alone are weak evidence of adoption. Measure whether key process events are captured on time, whether handoffs complete without chasing, whether pipeline stages correspond to observable evidence, whether duplicate spreadsheets are disappearing, and whether reports can be produced without manual reconstruction.
If usage is low in one part of the process, investigate that segment. The issue might be interface design, role permissions, missing integration, unnecessary data entry or a stage that does not belong in the process at all.
A practical diagnostic
- Sit with two or three users and watch them complete a real piece of customer work end to end.
- Note every point where they leave the CRM, and why.
- For each mandatory field, name the person who uses the value and the decision it supports.
- Check whether each pipeline stage corresponds to a customer action or internal decision that can be evidenced.
- Trace one won deal into delivery and record how the information got there.
The results usually separate into three groups: genuine skill gaps (a training problem), configuration that misrepresents the process (a design problem) and missing connections to other systems (an integration problem). Each needs a different response.
Trade-offs
Redesigning the workflow takes longer than running another training session, and it can unsettle reports built on the old stages. Reducing mandatory fields may make some management reports less complete in the short term. Integration to remove double entry costs money and needs an owner. These costs are real, but they are usually smaller than the ongoing cost of a CRM people work around — paid for in licences, duplicated effort and forecasts nobody trusts.
What better looks like
A healthy CRM is not the place employees visit because management told them to. It is part of how customer work moves. The process language in the system matches the language of the business, ownership is clear, information is captured once where possible, and downstream teams receive what they need without side-channel coordination. This is closely related to the wider point that broken handoffs are systems problems.
If CRM “adoption” requires constant policing, the organisation should examine the workflow before buying more training or replacing the platform.
Digital Operations Improvement can redesign the workflow around real customer work. Where configuration or integration is the constraint, Systems Implementation & Integration can align the platform to that operating model.
Sources and further reading
- Implement a solution based on business processes - Dynamics 365 (last verified 10 October 2026)
- Base the implementation lifecycle on processes - Dynamics 365 (last verified 10 October 2026)
- Train users and increase adoption overview - Dynamics 365 (last verified 10 October 2026)