How to choose the right partner for Dynamics 365 Sales?

Short answer: the critical risk in a CRM project is not technical. It's that the sales team won't use the system. Therefore, choose a partner based on how they address factors determining usage: the sales process, daily friction, integration with the ERP system, and what happens after launch. Ask each candidate to demonstrate how they track actual usage with previous customers. If they cannot describe this, it reveals something about the systematic nature of their adoption work.

This guide is written by d365 Guide. We do not implement Dynamics 365, nor do we sell licenses. We exist to help buyers compare partners on consistent grounds.

This guide specifically concerns Dynamics 365 Sales. For the general selection process, regardless of the application, see our guide on how to find the right Dynamics 365 partner in the Nordics.

What makes this procurement unique

Dynamics 365 Sales is one of the most common implementations in the Nordic Dynamics market. d365 Guide estimates that approximately five hundred new deals are added per year, and projects often fall into the same cost range as a smaller ERP project or less. The partner field is broad, offering you negotiation room but also a larger selection to sort through. These figures are d365 Guide's market assessment, updated in September 2026, not official Microsoft statistics.

The low entry cost is also the biggest pitfall of this procurement. A CRM can be set up quickly and cheaply, and precisely for this reason, partners are often evaluated superficially. The cost of a failed CRM rarely appears in the project budget. It shows up in untrustworthy forecasts two years later.

An ERP system is used because it must be used: invoices won't be sent otherwise. A CRM is only used if salespeople feel it benefits them. This is the whole difference, and it should guide your evaluation.

Note that Customer Service and Field Service are separate procurements with a narrower partner field, even if the apps share a platform with Sales. If they are part of your scope, refer to the guide on Customer Service and Field Service.

Step 1: Determine what the system should solve

The most common reason CRM projects lose direction is that the decision group wants different things without having articulated them. Management wants forecasts. The sales manager wants an overview. Salespeople want to avoid double entry. Marketing wants data. All these can be fulfilled, but they lead to different solutions.

Clarify before you proceed:

• Is the main purpose forecasting and control, or supporting the salesperson's daily work? If the answer is the former, the system will require discipline that someone must enforce.
• Which sales process should the system reflect, and is it currently documented anywhere?
• What should the salesperson stop doing once the system is in place? A CRM that only adds work will be circumvented.
• Who internally will own the system after launch, and is that person allocated time?

The last question is the most important and the one most often left unanswered. A CRM that no one owns internally will stop reflecting the business within a year, as sales processes change faster than financial processes.

Step 2: Understand the type of vendor you are talking to

In the Nordic market, you will encounter three different types of vendors. None of them are inherently wrong, but they have different strengths and different things that need to be checked.

The choice between them is primarily driven by how tightly CRM needs to be integrated with your ERP system. If Sales needs to retrieve customers, items, prices, and order history from an ERP in real-time, integration is the heaviest part of the project, and who can handle both sides becomes very important. If the system mainly supports a sales process with limited exchange with finance, then specialized CRM expertise carries more weight.

Step 3: The question of standard app vs. custom app

This is what distinguishes a CRM procurement from everything else in the Dynamics family, and what buyers find most difficult to assess.

Dynamics 365 Sales is built on Microsoft's Dataverse data platform. The line between the standard application and a custom-built app in Power Apps is fluid. Two partners can solve the exact same need in completely different ways: one by configuring the standard app, the other by building a custom model-driven app on top of the same data.

Both can look similar in a demo. The difference often only becomes apparent during ongoing management. A solution close to standard is usually easier to update, document, and hand over to another partner. A custom model-driven app can, at the same time, be perfectly right when the business requires a more precise workflow, but then you need to understand what is custom-built, how it is tested, and who can maintain it over time.

Therefore, ask directly: what of this is standard, and what have you built? Request the answer in writing, per functional area. A partner who cannot answer without looking at the solution has either built more than you think or hasn't considered the question, and both are worth knowing.

Step 4: Integration with the ERP system

CRM rarely lives alone. Customer records, items, prices, order history, and credit information reside elsewhere, and the quality of that connection determines how credible the system is perceived to be.

Three things to clarify with each candidate:

• How does the integration work? Ready-made connectors and platform-based integrations survive Microsoft's updates better than custom point-to-point code.
• In which direction does the truth flow? Which system owns the customer data, and what happens when the same customer is updated in both places? A missing answer here will become a data quality issue within six months.
• Who owns the integration in ongoing management if CRM and ERP are delivered by different partners? This should be clarified before the contract, not after the first error.

If the ERP system on the other end is Finance & Supply Chain Management, partly different conditions apply to partner selection, which we cover in the guide on partner selection for Finance & Supply Chain Management.

Step 5: Questions to ask, and how to interpret the answers

The following questions are formulated not to have an obviously good answer. The evaluation of the answer is at least as important as the question.

1. Can you show actual usage rates from a previous customer?

The most revealing question in the entire evaluation. All partners talk about user adoption. Few measure it.

Good answers include:

• Concrete metrics: percentage of salespeople logging in daily, percentage of deals registered in the system, how it looked three and twelve months after launch.
• An example where the number was low and what they did about it.

Warning signs:

• Adoption is described as a customer attitude issue.
• The answer is about training sessions rather than usage.

2. How much daily friction does the solution build in?

Ask a salesperson to perform three real-world tasks in the demo: register a customer meeting, update a deal, and find a customer's history. Count the steps and assess how much needs to be manually entered. Small frictions repeated daily determine whether the system is used by more than just the dutiful.

Good answers include:

• A demonstration of the workflow, on mobile, with a realistic deal.
• A discussion about what they usually remove from standard views to reduce clutter.

Warning signs:

• All fields are presented as necessary.
• The demo is run only in a web browser despite salespeople working on mobile.

3. What of the solution is standard and what have you built?

See the section above. This question determines maintenance costs and how locked-in you become.

Good answers include:

• A breakdown per functional area, in writing.
• A discussion of why those specific parts were built instead of configured.

Warning signs:

• Custom-built parts are presented solely as a strength.
• No one can answer without first looking at the solution.

4. Who in your team understands how sales works?

A consultant who has never worked closely with a sales organization designs systems that look logical in a process diagram but are used by no one.

Good answers include:

• Names of someone on the team with a background in sales or sales management.
• Questions back about your sales process that you hadn't considered.

Warning signs:

• The conversation is always about features and never about how you sell.
• Your existing process is accepted without objections.

5. What does the integration with our ERP system look like, concretely?

See step 4. The answer should include technology, direction, and ownership.

Good answers include:

• Which method is proposed and why, as well as its ongoing cost.
• A clear statement about which system owns which task.

Warning signs:

• Integration is described as simple without discussing the system on the other end.
• No distinction is made between displaying data and synchronizing it.

6. What have you put into production with Copilot and agents?

Almost all partners claim to work with AI in CRM. Significantly fewer can describe what they have actually deployed for a customer.

Good answers include:

• A named function for a named customer, and what it achieved.
• An honest delimitation of what doesn't yet work well.

Warning signs:

• The answer consists of Microsoft's product description.
• AI is presented as a reason to choose them, without examples.

7. What happens after launch?

A CRM that isn't developed doesn't keep up when the sales organization changes, and it changes more often than the finance department.

Good answers include:

• A management model with a named contact, response times, and pricing model.
• A rhythm for ongoing adjustments, such as recurring check-ins during the first few months.
• A discussion about what you should be able to do yourself without calling them.

Warning signs:

• The project ends at launch, and management is offered as something separate later.
• Every field change requires an order.

Merits that measure something different than you think

• Certifications are tied to individuals, not companies. The question is whether the certified individuals will be the ones assigned to your project.
• Microsoft's partner designations have been based on Solutions Partner designations since 2022. The term 'gold competency' no longer exists.
• Awards from Microsoft reflect the partner's relationship with Microsoft. They are not customer satisfaction metrics.
• The total number of CRM customers says less than the number of launches in the last two years, and significantly less than how many of them are still actively used.

What usually goes wrong in the selection itself

• The decision is made by management and IT without any salesperson having tested the system. The group that will use it daily then has no part in the choice.
• The requirements list meticulously reflects the existing process, thereby building today's problems into the new system.
• Ongoing management is excluded from the procurement, even though CRM changes more often than any other system you have.
• The marketing aspect is brought in late, requiring the data model for contacts and consents to be redone.
• The price is compared for the project, not for three years of total cost including licenses, integration, and ongoing adjustments.

A note on sources

Most of what is published in English about choosing a Dynamics 365 partner is written by partners. The material is often competent, but it is written by a party with an interest in the outcome, and therefore the criteria often lean towards their own profile.

Read multiple sources, and ask yourself who benefits from those specific criteria carrying the most weight.

Next steps

Involve a salesperson in the evaluation, and let that person have real influence over the choice. That is the single biggest difference between CRM projects that are used and CRM projects that are quietly phased out.

On d365 Guide, you can compare Nordic Dynamics 365 partners by application area, industry, and size, and narrow down the field before you start booking meetings.