How to choose the right partner for Dynamics 365 Customer Service and Field Service?

Short answer: Customer Service and Field Service are among the Dynamics areas where an operational problem becomes visible fastest to the end customer. If something goes wrong, the customer might notice it before you even have time to react. Therefore, choose a partner based on operational capability as much as design capability: how they handle outages, how they test before updates, how scheduling and SLAs are actually set up, and who responds when field technicians can't access the app.

This guide is written by d365 Guide. We do not implement Dynamics 365 and we do not sell licenses. We exist to enable buyers to compare partners on the same grounds.

It specifically applies to Customer Service and Field Service. For the selection process in general, regardless of the application, see our guide on how to find the right partner for Dynamics 365 in the Nordics.

What distinguishes this procurement

Customer Service and Field Service are sometimes treated as minor additions to a Sales or CRM project. This is often a mistake: they have their own processes, integrations, and operational requirements. A limited first implementation without heavy integrations can start below around EUR 45,000, while complete production solutions with SLA models, migration, integrations, and/or Field Service and Contact Center often exceed that level. d365 Guide estimates the number of new deals in the Nordics to be a couple of hundred per application area per year. This is our market assessment, updated in September 2026, not official Microsoft statistics.

The partner landscape is also narrower than on the sales side. Many partners strong in Dynamics 365 Sales have limited experience with scheduling, SLA setup, or telephony integration, as it requires a different kind of expertise. Ask early and specifically, otherwise, you might get a Sales team with a basic understanding of the service module.

The crucial difference compared to many internal business processes is how quickly an error becomes externally visible. An error in finance or an internal sales system can often be detected and handled internally first. An error in a service system, however, can be noticed immediately by a customer waiting for an answer or a technician who doesn't arrive. This should guide how you weigh your evaluation.

Step 1: Define what you are actually implementing

The area is broad and scope creep is easy. Clarify your starting point before you begin, as it determines the expertise needed in the team.

The point about the handover between customer service and field deserves special attention. Many projects deliver two functional parts and a broken connection: the case becomes a work order, but the agent doesn't see when the technician was there, or the technician's report never makes it back into the case. Ask to see this specific handover demonstrated, not just described.

Step 2: Start from your service promises, not from the feature list

A service system is fundamentally a machine designed to uphold promises you have already made to your customers. If those promises are not articulated, the system becomes a guess.

Have the answers ready before the first vendor meeting:

• What response and resolution times have you promised, to which customers, and how do they differ between agreements?
• What counts as the start time for a case, and when does the clock stop? This is the question that causes the most rework when answered too late.
• What are your opening hours and on-call services, and should the system calculate SLA in calendar time or working time?
• Which channels should be included: phone, email, forms, chat, customer portal? And should the customer be able to track their case themselves?
• For field: what governs who gets a job? Competence, geography, spare parts in the vehicle, contract level, or a combination?

The last question is what distinguishes a functional scheduling setup from one that technicians circumvent. If the planner practically moves everything manually every morning, the optimization has yielded nothing.

Step 3: Look closely at the field app

In Field Service, the mobile app is the only part of the system that most users will ever see. It determines whether the solution works.

Three things to check in a demo, based on your own reality:

• What happens without coverage? Technicians work in basements, elevator shafts, and rural areas. Ask how the offline mode works, how long it lasts, and what happens when two people change the same thing before synchronization.
• How many steps does a completed work order take? Including signature, consumed materials, time, and photos. Count the steps yourself during the demo instead of asking.
• Does it work on the equipment technicians actually have? With gloves, in sunlight, on an older phone.

Step 4: Integration and Operations

The service system stands between the customer and your finances. It needs to retrieve assets, contracts, items, and prices, and provide data for invoicing time and materials.

Clarify with each candidate which system owns the asset register, how spare part inventories are managed when materials are in a service vehicle, and how completed work becomes an invoice. If the answer to the last point is a manual routine, it should be clear in the quote, as that's where much of the promised benefit often disappears.

If the ERP system is at the enterprise level, it affects both integration and the choice of supplier. We cover this in the guide on partner selection for Finance & Supply Chain Management.

The operations issue is at least as important. Microsoft continuously updates the platform, and you cannot postpone it indefinitely. Ask how the partner tests your solution before updates, especially the parts related to scheduling and integrations, and what happens if something breaks on a Monday morning.

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

The following questions are formulated not to have an obvious 'good' answer. The assessment of the answer is just as important as the question itself.

1. How many customer service and field service installations have you put into operation in the last two years?

This question effectively filters, as many partners have a long Dynamics history but few service deployments.

Good answers include:

• A number, with customers that can be contacted, and a distinction between Customer Service and Field Service.
• Information on the number of agents and technicians in those installations, respectively.

Warning signs:

• The answer shifts to the total number of CRM customers.
• References relate to pilot installations that were never scaled up.

2. How have you set up SLA for a previous customer?

SLA setup is the most common source of rework, as it requires both agreements and exceptions to be well thought out.

Good answers include:

• A concrete example with different service levels, a working time calendar, and rules for when the clock is paused.
• A discussion about what they usually advise against building in.

Warning signs:

• SLA is described as a setting rather than a model.
• No question is asked back about your agreements.

3. Show how a case becomes a work order and how the response comes back

The interface between customer service and field is the most common deficiency in delivered solutions.

Good answers include:

• A demonstration in a coherent flow, not two separate showings.
• Information on what the agent sees if the technician is delayed.

Warning signs:

• The flow is described on a whiteboard instead of being demonstrated.
• Feedback to the customer requires someone to manually update the case.

4. How does scheduling work in practice, six months in?

Automatic optimization sells well in demos. The question is whether the planner still uses it.

Good answers include:

• An example of how much is scheduled automatically versus manually for an existing customer.
• A discussion about which rules usually need adjustment after a few months.

Warning signs:

• Optimization is presented as something that solves itself.
• No one can describe how an urgent order gets inserted into a full schedule.

5. What happens when something breaks on a Monday morning?

This is the most critical support question in this area, and what distinguishes an operationally mature vendor from a project-oriented one.

Good answers include:

• Response times, on-call arrangements, and who actually answers, with a name or function.
• A concrete example of an outage they handled and how long it took.

Warning signs:

• Support is described solely as a ticketing system.
• The same consultants staff both ongoing projects and urgent support, without capacity planning.

6. How do you test our solution before Microsoft updates?

The platform is updated regardless of your preferences. The question is who checks that your solution still works.

Good answers include:

• A described routine with a test environment and which flows are tested each time.
• Confirmation whether this is included in the maintenance agreement or billed separately.

Warning signs:

• Testing is described as something you do yourselves, without support.
• The question has not come up before with other customers.

7. What have you put into production with AI in customer service?

Automatic response suggestions, summaries, and customer chatbots are the most discussed features in this area, and those with the largest gap between promise and reality.

Good answers include:

• A named function at a named customer, and what measurable benefit it provided.
• An honest description of what was required in terms of knowledge base content for it to work.

Warning signs:

• The answer consists of Microsoft's product description.
• The quality of the knowledge base is not mentioned at all.

Merits that measure something other than you think

• Experience with Dynamics 365 Sales is not experience with Customer Service or Field Service. It's the same platform but different disciplines, and the difference is evident in scheduling, SLA, and operations.
• Certifications are tied to individuals, not to companies. The question is whether the certified individuals will be assigned to your project.
• Microsoft's partner designations have been based on Solutions Partner designations since 2022. The concept of 'gold competency' no longer exists.
• Awards from Microsoft reflect the partner's relationship with Microsoft. They are not customer satisfaction metrics.

What usually goes wrong in the selection itself

• No agent or technician participates in the evaluation, even though they are the only ones who will use the system daily.
• The SLA model is only investigated during implementation, which shifts work and cost into the project.
• The field app is evaluated in a demo on a large screen in a conference room instead of in a real-world environment.
• Invoicing for completed work is left out of scope and handled manually, which eats up the benefits.
• Maintenance and on-call services are priced after the contract is signed, when you no longer have a negotiating position.
• The knowledge base is planned as a post-launch activity, meaning neither the agents nor the AI functions have anything to work with.

A note on sources

Most of what is published in Swedish about how to choose 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 the criteria therefore tend to align with their own profile.

Read multiple sources, and ask yourself who benefits from those specific criteria being weighed most heavily.

Next steps

Write down your service promises and your rules for who gets a job before contacting any vendor. With these two documents in place, vendor discussions will be shorter, and the differences between candidates will quickly become apparent.

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