What should a CRM project start with?
A good CRM project should start with the commercial problem the business needs to solve, not with the phrase “we need CRM”. The real issue may be weak pipeline visibility, poor follow-up, inconsistent sales stages, unclear account ownership, low data trust or no shared view of customer activity.
That distinction matters.
When a leadership team says “we need CRM”, it sounds like a brief. In reality, it is often a symptom. It describes the category of system being considered, but not the operating problem behind it.
One company may need better control over new enquiries. Another may need a cleaner handover from sales to delivery. Another may need reliable activity tracking because too much customer knowledge sits in private inboxes, spreadsheets and personal notes. All three may ask for CRM. They do not need the same project.
That is where CRM projects often start to drift. The team begins discussing fields, dashboards, automations, integrations and licences before it has agreed what must improve in the business.
The myth is that CRM failure is mainly a software problem. It is more often a definition problem.
CRM should not be treated as a digital address book or a place to “store contacts”. For sales-led organisations, especially in manufacturing, distribution and other relationship-heavy sectors, CRM should act as a shared operating layer for customer-facing work. It should show who owns the relationship, what has happened, what is due next, where opportunities stand and where commercial risk is building.
Before choosing or configuring a CRM system, leaders need to diagnose the current sales operating model:
- Is the issue process discipline?
- Is the issue poor or incomplete customer data?
- Is the issue unclear ownership?
- Is the issue inconsistent follow-up?
- Is the issue system fit, because current tools cannot support the way the business now sells?
Those questions prevent the project from becoming feature-led too early.
The evidence is not new, but it remains relevant. Harvard Business Review’s classic analysis of CRM failure warned that many executives treat CRM as software that will manage customer relationships for them, rather than as customer strategy and process supported by technology. It also cited that 55% of CRM projects did not produce results.
The lesson is not “avoid CRM”. The lesson is to start in the right place.
A safer CRM implementation begins by turning a vague request into a plain-English business problem. For example: “We cannot trust our sales forecast because opportunities are updated inconsistently, proposal follow-up is not owned clearly, and key customer activity is spread across inboxes and spreadsheets.”
That statement gives the project direction. It tells the business what CRM must fix first. It also protects scope, spend and adoption because every future decision can be tested against the same question: does this help solve the real commercial problem?
What are leaders really trying to fix with CRM?
Leaders usually ask for CRM because they want more control over sales performance. The practical need is rarely contact storage alone. It is trusted pipeline visibility, clearer accountability, consistent follow-up, better forecasting and one place where customer activity can be seen without chasing five different sources.
That is why a CRM project should be framed around commercial control.
In Dynamics 365 CRM, that control comes from a few disciplined basics: well-defined sales stages in the business process flow, mandatory data at key milestones, Outlook and Teams-based activity capture, and standard pipeline views that sales managers use in regular reviews.
In many businesses, the sales picture is assembled manually. A forecast comes from one spreadsheet. Proposal history sits in a folder. Customer promises are buried in email. Meeting notes live in Teams, notebooks or personal memory. A sales manager may know the number, but not the confidence behind it. A Dynamics 365-based CRM should move this picture into Dataverse as the single source of truth, so pipeline and activity data are no longer scattered across spreadsheets and inboxes.
This creates a familiar pattern: pipeline reviews become status-gathering exercises rather than decision meetings. Leaders ask what has changed. Sales teams explain what they remember. The business leaves with activity, but not always clarity.
Bain found that more than 80% of surveyed firms claimed to run structured sales and marketing activities, yet 70% did not effectively integrate their sales plays into CRM or revenue technology, with only around 20% realising full value. That is the gap many CRM projects are really trying to close: the difference between having a sales approach and having that approach visible, usable and governed inside the system.
A good Dynamics 365 CRM design should make the sales operating model easier to run. That means defined stages, clear exit criteria, follow-up rules, activity capture, pipeline health reviews and reporting that reflects real behaviour, not partial records.
The Weak Input → Business Risk Map
In any CRM – and especially in Dynamics 365 where reporting and AI rely on trusted Dataverse data – weak inputs in the sales process quickly turn into business risk.
| Weak input inside the sales process | Business risk it creates |
| Vague opportunity stages | Forecasts look cleaner than they really are |
| Follow-ups tracked in inboxes | Deals stall without visible ownership |
| Customer notes kept personally | Handover risk increases when people are absent or leave |
| Free-text updates with no standards | Reporting becomes hard to trust |
| No agreed next-step rule | Pipeline reviews focus on explanations, not action |
| Unclear account ownership | Customers receive inconsistent communication |
| Dashboards built before data rules | Leaders see charts, but not reliable truth |
| Unmanaged customisations and ad-hoc automations | Changes become risky, ALM is harder, and upgrades are more complex. |
The point is not to control every movement a salesperson makes. It is to remove unnecessary ambiguity from work that already affects revenue, margin and customer experience.
This is where the CRM conversation becomes more useful. Instead of asking, “What features do we need?”, ask, “What decisions are currently slower or weaker because we cannot see the truth quickly enough?”
For some businesses, the first win is a single source of truth for pipeline and account activity. For others, it is forecast confidence, better handovers, or knowing which opportunities need intervention before the month-end surprise arrives.
Once that is clear, CRM stops being a software shopping exercise. It becomes a practical route to better visibility, cleaner ownership and stronger commercial decision-making.
How do you define the real CRM problem before design starts?
The real CRM problem should be written in plain business language before anyone designs screens, fields or dashboards. A useful CRM problem statement names the outcome being harmed, the evidence behind the issue, the people affected and the business impact of leaving it unresolved.
This is where CRM discovery earns its value. In Dynamics 365 projects, this is exactly what Success by Design discovery and solution blueprint workshops are designed to do: turn plain-language problems into scoped processes, data models, and solution requirements.
A leadership team may begin with: “We need better reporting.”
A better problem statement would be: “We cannot make reliable pipeline decisions because sales stages are used inconsistently, customer activity is not captured in one place, and opportunity updates depend on individual habits.”
That change in wording matters. The first version asks for a dashboard. The second version reveals process, data, behaviour and ownership issues. It gives the CRM project a job.
The CRM Problem-First Test
Before solution design, ask six questions:
- What outcome are we trying to improve? Forecast confidence, conversion, response time, handover quality, customer retention or sales productivity?
- What behaviour must change? Better follow-up, cleaner opportunity updates, consistent stage movement, clearer account ownership or stronger sales management cadence?
- What data must be trusted? Contacts, activities, next steps, proposal status, close dates, revenue values, customer history or account ownership?
- Who owns each handover? Sales to estimating, sales to delivery, marketing to sales, account management to service, or leadership to team managers?
- What decision should CRM help us make? Where to focus sales effort, which deals are at risk, which accounts need attention, which activities drive progress, or whether the forecast is credible?
- How will we measure success? Which KPIs – for example, forecast accuracy, cycle time, conversion rate, or activity coverage – will we track in CRM to prove the change is working?
This test works because it separates what users ask for from what the business needs. Users may ask for fewer clicks, more automation, cleaner screens or a specific dashboard. Those requests may be valid. They should still be tested against the problem the business is trying to solve.
A strong CRM discovery workshop should bring together sales leadership, users, operations, IT and any team that depends on customer information. The aim is not to collect every preference. It is to agree the operating rules CRM must support.
Those rules include which records matter, which fields are mandatory, when an opportunity changes stage, what follow-up standard is expected, what reports leaders need and who owns data quality after go-live.
This also protects the Dynamics 365 CRM design from becoming overbuilt. If the first-phase goal is pipeline visibility, the project may not need every possible automation, integration or report on day one. It needs the right structure, the right data and the right habits to make the first outcome real.
Plain-English problem definition gives the CRM project a sharper scope. It helps leaders agree what success means before delivery begins.
Why does better problem definition protect CRM scope and spend?
Better problem definition protects CRM scope because it gives every design choice a test: does this help solve the agreed business problem? Without that discipline, a CRM implementation can fill up with extra fields, unnecessary automation, weak data migration decisions and reports that look useful but do not change behaviour.
The cost risk is not only licence spend. It is time lost in rework, user resistance, poor adoption and leadership losing trust in the system before it has had a fair chance to work.
A safer CRM project defines four things early:
- What must be solved first: the core commercial issue, such as pipeline visibility or follow-up discipline.
- What can wait: useful but non-critical features for later phases.
- What should not be configured: requests that add complexity without improving the agreed outcome.
- What must be owned after go-live: data quality, user habits, reporting cadence and internal system ownership.
This matches Microsoft’s phased approach to Dynamics 365: start with a thin but end-to-end process that delivers clear value, then extend in later waves once adoption and data quality are stable.
This is where CRM scoping becomes a commercial control exercise. A first phase should not try to solve every sales, marketing and service problem at once. It should create a usable foundation: trusted records, clear ownership, agreed sales stages, practical reporting and training that helps people work differently. For example, an initial Dynamics 365 Sales release might focus only on opportunity management and pipeline reviews, leaving complex quote automation or CPQ for later phases.
Data migration is a good example. Moving every historic record may feel safe, but poor legacy data can damage trust from day one. A better question is: which customer, contact, activity and opportunity data do users need to run the business properly after go-live?
Adoption needs the same realism. CRM adoption does not happen because the system exists. It happens when users understand the reason for change, managers reinforce the right behaviours, and the system makes daily work clearer rather than heavier.
CRM project FAQs
What should a CRM project start with?
A CRM project should start with a plain-English business problem, such as poor pipeline visibility, inconsistent follow-up or unreliable customer data. Software selection should follow that definition.
Why do CRM projects fail?
CRM projects often fail when technology is treated as the strategy. Weak process design, poor data quality, unclear ownership and low user adoption can undermine even a well-built system.
How do we avoid CRM scope creep?
Use the agreed problem statement as the scope filter. If a feature does not support the first-phase outcome, it should be challenged, deferred or removed.
When should we consider Dynamics 365 CRM?
Dynamics 365 CRM is worth considering when you want your CRM to sit at the centre of a Microsoft cloud strategy: shared Dataverse data, Outlook and Teams-connected working, Power BI for analytics, and Power Platform to extend processes under a governed framework.
The right CRM conversation is not “which system should we buy?” It is “what commercial problem are we prepared to define clearly enough to solve well?”
For organisations considering Dynamics 365 CRM, GO ERP can help run a CRM discovery or scoping review to clarify the real problem, assess data and adoption readiness, and shape a practical first-phase roadmap before build decisions are made.
