Many CRM projects start with a feature list. Better dashboards. More automation. Cleaner handovers. Pipeline reporting. Outlook integration. AI. A new platform.
Those requests may be valid. They may also be symptoms.
Before briefing CRM vendors, define the business problem, the users affected, the process that needs to change, the data reality, the minimum useful phase-one scope and the measures of success.
A strong CRM vendor brief should separate what needs fixing now from what can wait, so demos and proposals are judged on fit, risk and business value, not feature volume.
“We need CRM” is rarely the real starting point
When a leadership team says it needs CRM, it is often describing the visible pain rather than the cause.
Sales leaders may be frustrated by unreliable forecasts. Customer service may be chasing updates through inboxes. Account managers may hold customer knowledge in private notes. Finance may not trust pipeline numbers. The board may want clearer revenue visibility.
A CRM system can help with all of that. But it will not fix unclear sales stages, inconsistent qualification, weak task ownership, poor data discipline or teams that treat customer records as optional.
This is where many first CRM conversations go wrong. Buyers ask vendors what the system can do before deciding what the business must stop doing.
The first question is not “which CRM?” It is “what is broken?”
A useful CRM decision starts by sorting each problem into one of five causes:
We use this simple diagnostic model in Dynamics 365 discovery workshops to separate system issues from process, data, training, and ownership problems before any vendor is briefed.
- System limitation: the current tools genuinely cannot support the work.
- Process gap: people follow different rules for the same customer or opportunity journey.
- Data problem: records are duplicated, incomplete, outdated or not trusted.
- Training issue: users do not know the agreed way to work.
- Ownership failure: nobody is accountable for follow-up, data quality,reporting or adoption.
This distinction matters because each cause needs a different response. A process problem needs process design before configuration. This is exactly how Microsoft’s Success by Design framework recommends approaching Dynamics 365: design and agree the end-to-end process first, then configure CRM to support it. A data problem needs cleansing, ownership and migration rules before dashboards. An adoption problem needs training, leadership reinforcement and practical usability, not more fields.
Automating weak habits simply makes them happen faster. Reporting on poor inputs gives leaders faster access to unreliable numbers. Integrating every tool before defining the single source of truth can spread confusion across more systems. For Dynamics 365, that single source of truth should usually be Dataverse, with other systems integrated deliberately around it rather than competing with it.
What should leaders look for before CRM vendor conversations?
The best early signal is whether the business can describe how customer-facing work should happen.
Who owns the account? What makes an opportunity qualified? Which activities must be logged? What fields are genuinely needed? Which reports will leaders use to manage performance? What would count as adoption after go-live?
For a manufacturing or distribution business, this often means creating one shared commercial view across contacts, accounts, pipeline, proposals, tasks and customer history. Dynamics 365 CRM can support that well when the process, data and user model are clear, using shared Dataverse entities for accounts, contacts, opportunities, and activities, and standard business process flows for pipeline stages. Without that clarity, even a strong platform becomes another place for inconsistent working.
The practical aim is not to brief vendors with every future ambition. It is to brief them with a sharp diagnosis.
Define the minimum useful CRM scope before the brief grows
A strong CRM phase one is not the smallest system you can buy. It is the smallest version that changes daily behaviour, improves sales visibility and gives leaders information they can trust.
In practice, we define minimum useful scope in Dynamics 365 as the smallest release that changes daily behaviour, supports a complete lead-to-opportunity-to-order process, and gives leaders reports they can actually use to run reviews.
That distinction protects the budget. It also protects adoption. When phase one becomes a holding pen for every dashboard, integration, automation and edge case, the project becomes harder to deliver and harder for users to accept.
The CRM Phase-One Fit Test
Before adding a requirement to your CRM vendor brief, test it against five questions.
| Requirement test | What to ask | Why it matters |
| Behaviour | Will this change how people work each day? | CRM value depends on usage, not configuration. |
| Visibility | Will leaders see pipeline, activity or customer risk more clearly? | Better decisions need better commercial signals. |
| Data trust | Will this improve the quality, structure or reliability of records? | Weak data damages reporting, forecasting and adoption. |
| Ownership | Will this clarify who owns the next action? | Unclear ownership lets deals and tasks drift. |
| Decision quality | Will this help managers act faster or with more confidence? | CRM should support judgement, not create more admin. |
If a requirement does not pass at least one of these tests, it probably belongs outside phase one. It may still matter. It just does not need to shape the first CRM implementation scope.
What usually belongs in CRM phase one?
For most sales-led CRM projects, phase one should create the operating base: the records, workflows and habits the business needs before it adds more capability.
A practical CRM phase one often includes:
- Account and contact structure. The business needs one agreed way to record customers, prospects, buying groups and relationship history.
- Opportunity stages and qualification rules. Pipeline visibility depends on shared definitions. A “qualified” opportunity should mean the same thing across the team.
- Activity and task tracking. Follow-up needs to move out of private notebooks, inboxes and memory. Sales work becomes easier to manage when the next action is visible.
- Essential dashboards. Early reporting should focus on what leaders will use: pipeline value, stage movement, overdue activity, forecast confidence and stalled opportunities.
- Role-based access and user views. Salespeople, managers and leadership do not need the same screen. Usability improves when each role sees what matters.
- A limited set of adoption-critical integrations. Outlook, Teams and core Microsoft working habits often matter more than broad integration ambition. Familiar tools reduce friction and make Dynamics 365 CRM feel like part of the working day, especially when combined with simple Power Automate flows instead of heavy custom integration.
What should wait?
Advanced automation, AI, predictive scoring, complex integrations and heavy customisation usually work better after users trust the system and the data. Adding them too early can increase cost, slow delivery and create a false sense of progress.
The question is not, “Can the CRM do this?”
The better question is, “Does the business have the process, data and ownership needed to make this useful now?”
What belongs in CRM phase one, and what should wait?
CRM phase one should establish the operating foundation: usable records, clear sales stages, trusted data, sensible permissions, basic reporting and adoption habits. Later phases should build on that foundation with automation, deeper integrations, AI, advanced analytics and more tailored workflows once the business can prove stable usage.
| Requirement layer | Business purpose | Good examples | Risk if rushed | Decision rule |
| Foundation | Create a reliable CRM operating base | Account/contact structure, opportunity stages, permissions, migration rules, mandatory fields | Leaders inherit cleaner screens but the same unreliable working habits | Include in phase one if it affects trust, usage or basic control |
| Enablement | Help users and managers work properly each day | Role-based views, activity tracking, simple dashboards, Outlook/Teams working patterns, super-user support | The system goes live but teams return to spreadsheets and inboxes | Include where it reduces friction or supports adoption |
| Optimisation | Improve speed and consistency once usage is stable | Workflow automation, approval flows, richer reporting, lead scoring, document generation | Automation magnifies inconsistent rules or poor data | Delay until the process is proven and data is dependable |
| Future value | Extend CRM into more advanced capability | AI/Copilot use cases, predictive analytics, complex ERP integration, multi-system customer intelligence | Spend rises before the business has earned the right to complexity | Sequence after adoption, governance and reporting quality are visible |
Weak inputs create expensive CRM risks
A CRM project does not fail only at go-live. It often starts failing when weak assumptions are accepted into scope.
| Weak input | Business risk |
| “Every team defines pipeline stages differently.” | Forecast meetings become debates about interpretation, not decisions about action. |
| “We will clean the data after migration.” | Duplicate and incomplete records reduce trust from the first week. |
| “Salespeople can decide what to log.” | Customer knowledge stays fragmented and management visibility remains partial. |
| “Let’s customise it to match how we work now.” | The new CRM recreates old inefficiencies with higher support cost. |
| “We need all integrations in phase one.” | Delivery becomes harder before the business has proved which data flows truly matter. |
This is why phase one should be deliberately conservative. Conservative does not mean unambitious. It means disciplined.
This conservative, outcome-first approach is exactly what Microsoft’s Success by Design framework promotes for Dynamics 365 implementations: earn the right to complexity by stabilising process, data and adoption first.
For example, a distributor may eventually want CRM connected to ERP, marketing automation, customer service, Power BI and AI-assisted account planning. That may be a valid roadmap. But the first phase may only need a shared customer record in Dynamics 365, a standard opportunity process, reliable activity capture, a small set of dashboards and clear ownership for data quality.
That foundation gives leaders something more useful than a broad feature launch: a system people can use, govern and improve.
The test for later phases should be evidence-based. Are users entering activity consistently? Are opportunity stages being used as agreed? Do managers trust the reports? Are duplicate records under control? Are the right people owning follow-up?
Once those answers are strong, advanced CRM investment becomes safer. Until then, more capability can simply create more places for the same problems to hide.
Build a first-phase CRM brief vendors can answer properly
A strong CRM vendor brief gives potential partners enough context to judge fit, risk and value. It should not ask every vendor to interpret vague ambition from scratch.
Before demos or proposals, your brief should cover:
| Brief section | What to include |
| Business problem | The commercial issue CRM must improve: weak pipeline visibility, inconsistent follow-up, poor customer records, slow reporting or fragmented sales activity. |
| Core users | Which teams will use CRM in phase one, what they do daily and where current working habits create friction. |
| Target workflows | The agreed sales, account or service processes CRM must support. |
| Phase-one scope | The records, stages, dashboards, roles, fields and integrations required for the first usable release. |
| Exclusions | What is deliberately out of scope until later, such as advanced automation, AI, complex integrations or heavy customisation. |
| Data reality | Where customer data lives now, its quality, duplicates, missing fields and migration assumptions. |
| Success measures | Adoption, activity capture, pipeline visibility, forecast confidence, data quality and reporting use. |
| Delivery expectations | Governance, training, testing, super-user ownership, go-live support and post-launch improvement. |
This changes the vendor conversation. Instead of asking, “Can your CRM do this?”, the business can ask, “How would you deliver this safely, what risks do you see, and what should we challenge before phase one starts?”
That is a better test of a CRM partner. Feature breadth matters, but realism matters more. A good partner should be able to explain what belongs in Dynamics 365 CRM now, what should wait, what data needs attention and where the business may be asking technology to solve a process issue.
FAQs for CRM buyers
What should a CRM brief include?
A CRM brief should include the business problem, phase-one scope, core users, target workflows, data condition, reporting needs, adoption plan, success measures and delivery expectations.
What should not go into CRM phase one?
Phase one should usually avoid heavy customisation, advanced AI, complex integrations and automation that depends on untested processes or poor-quality data.
When should CRM automation wait?
CRM automation should wait when sales stages, ownership rules, data standards or user behaviour are still inconsistent. Automation works best when the process is already clear.
How do you know whether CRM or process is the real problem?
Map the current workflow before selecting features. If people disagree on stages, ownership, data rules or follow-up expectations, process design comes first.
What should vendors be asked before proposal stage?
Ask how they would phase delivery, reduce adoption risk, handle data migration, support training, manage scope and decide what should be excluded from phase one. For Dynamics 365, also ask how they will align the project to Microsoft’s Success by Design stages (Initiate, Implement, Prepare, Operate) and how they will manage environments, ALM and post-go-live evolution.
