What To Look For in a Dynamics Field Service Support Contract

A Dynamics 365 Field Service support contract is an agreement between your organisation and a support partner that defines how problems with Field Service, the Field Service mobile app, scheduling, and reporting are logged, triaged, escalated, and resolved after go-live.

What to look for in a support contract in brief:

• Three distinct user groups need different types of support: field engineers, back office staff, and management
• A clear ticket triage and escalation process is non-negotiable in any Field Service support contract
• You need to decide between open-access support and a single-point-of-contact (conduit) model before you sign
• Remote access to engineers’ mobile devices, via Microsoft Teams or a similar tool, should be standard in any support agreement
• Good support partners don’t just fix problems. They explain what went wrong and how to stop it happening again

You’ve gone live with Dynamics 365 Field Service. Now what?

The moment your engineers are using the Field Service mobile app on live jobs, support problems will surface, and the quality of your support contract decides how quickly those problems get sorted.

You’ve spent months configuring work orders, setting up the schedule board, rolling out the mobile app, and training your team. Now the system has to work every day, on real jobs, under real pressure. Dynamics 365 Field Service, as Microsoft’s own documentation describes it, combines workflow automation, scheduling algorithms, and mobility to support onsite service delivery. That’s a lot of moving parts. Things will break.

Who needs support inside your organisation? 

Field service software connects everyone from engineers and office staff, to management. Because of this, each group needs a different kind of help. 

Field engineers rely on the mobile app to access job details, capture signatures, take photos, and update status in real time. If their app crashes or loses connectivity, the day can quickly fall apart. They need fast, practical help that gets them back on track. 

Back office staff handle dispatching, scheduling, customer communication, and reporting. They need support for managing workflows, fixing data errors, and keeping schedules in sync with the field. 

Managers and leaders depend on accurate dashboards, reports, and insights. Their support needs usually involve configuration, reporting accuracy, and performance optimisation. 

System administrators keep everything running in the background. They need technical support for user management, updates, permissions, and complex troubleshooting. 

A strong support structure balances all these needs, ensuring no single team gets stuck waiting for answers. 

What does a good Dynamics 365 Field Service support ticket process look like?

A good Dynamics 365 Field Service support process tracks every ticket from first contact through to resolution, starts with an attempt to replicate the problem, aims for a first-time fix where possible, and has a clear escalation path for issues that need deeper investigation or input from Microsoft.

That sentence is worth re-reading, because every clause in it describes something that’s missing from a surprising number of support contracts.

No black holes. Your support partner should log every issue in a ticketing system. You should be able to see the status of any open ticket at any time. If you can’t, you don’t have a decent, structured support process.

Triage first. The support team’s first step should be to try to replicate the problem. Can they reproduce it? If yes, fix it. If no, dig deeper. This sounds obvious, but plenty of support interactions skip straight to “have you tried turning it off and on again?” without ever confirming whether the issue is real and repeatable.

Escalation path. Not every problem can be fixed by your support partner. Some issues sit inside Dynamics 365 itself, and need to go to Microsoft. A good support contract spells out exactly how and when that escalation happens.

Here’s what a structured triage and escalation process looks like in practice:

1. Issue raised by phone, email, or support portal
2. Support partner logs the ticket and confirms receipt with the person who raised it
3. Support partner attempts to replicate the problem
4. If the problem is replicable: resolve it and confirm the fix with the user
5. If not immediately resolvable: escalate internally within the support partner’s consultancy team
6. If the issue is platform-level: escalate to Microsoft support on your behalf
7. For complex or recurring issues: carry out root cause analysis and follow up with prevention recommendations

If your prospective support partner can’t describe a process like this clearly, that tells you something.

Should every engineer contact the support partner directly, or do you need a single point of contact?

This is one of the most practical decisions you’ll make when setting up a Dynamics 365 Field Service support contract

Open-access support: every user raises their own tickets

In an open-access model, every engineer and staff member contacts the support partner directly when they hit a problem. This is simple to set up but can cause chaos if 50 engineers all report the same mobile app bug separately, flooding the support desk with duplicate tickets.

The open-access model excels at simplicity and speed for small teams; however, it lags on scalability, because duplicate tickets consume support hours that could be spent on actual fixes.

For a team of five or six engineers, open access can work well. Everyone knows to call or email the support desk. Problems get logged and resolved.

But scale that up to 30, 40, 50 engineers, and you’ve got a different situation. One bug in the Field Service mobile app generates 50 separate tickets. Your support partner spends half their time triaging duplicates instead of fixing the problem.

Single point of contact (conduit model) for Dynamics 365 support

A conduit model means one person inside your business gathers issues from engineers and back office staff, filters out duplicates, and passes only the unique problems through to the support partner, which is cleaner and faster for most field service organisations but depends on having someone with the time and knowledge to do it well.

The conduit model excels at efficiency and noise reduction for larger teams; however, it lags on resilience, because it depends on a single person’s availability and system knowledge.

In practice, this means your internal conduit might receive five calls about the same camera bug on the Field Service mobile app. They log it once with the support partner. Three separate scheduling board issues become three clean tickets, not fifty confused ones.

For many organisations with more than 10 field engineers, the conduit model is the better choice. But it only works if the person in that role has the time, the system knowledge, and the authority to manage it properly. 

Why remote access to engineers’ devices is non-negotiable in any Field Service support contract

Any Dynamics 365 Field Service support partner needs to be able to see what your engineers see on their mobile devices during a support call, because diagnosing a Field Service mobile app issue over the phone without screen access is guesswork, and Microsoft Teams is the simplest way to make remote support work on both mobile and desktop.

Imagine this scenario. An engineer calls the support desk. “The app’s doing something weird with work orders.” The support consultant asks what they can see on the screen. The engineer tries to describe it. Five minutes later, everyone’s frustrated and no closer to a diagnosis.

Now picture the same call, but the support consultant starts a Microsoft Teams screen-sharing session. They can see the engineer’s screen in real time. They spot the issue in 30 seconds.

Microsoft Teams supports screen sharing with remote control as a standard feature. The official Microsoft documentation confirms this is managed through a per-user meeting policy that controls whether external participants can give, be given, or request control of the sharer’s screen.

For field service organisations, this means:

• Engineers’ mobile devices should have Microsoft Teams installed
• Back office and management desktops should have it too
• Your support partner should be set up to initiate Teams-based remote support sessions as part of their standard process

If a prospective support partner doesn’t ask about remote access during the sales process, ask them how they plan to diagnose mobile app problems. If the answer is “we’ll talk you through it over the phone,” that’s a warning sign.

Common mobile app issues after go-live 

Mobile apps are at the heart of field service work and also where most early support calls come from. 

Here are the most common mobile issues your engineers might face: 

• Camera problems that stop engineers from taking job photos or capturing serial numbers. 

• Signature capture errors that delay job completion and invoicing. 

• App update glitches caused by operating system changes or device compatibility. 

• Offline sync issues that prevent data from saving correctly when connectivity drops. 

• Performance problems like slow loading times or unexpected crashes. 

The best way to handle these is with remote troubleshooting tools (such as Microsoft Teams screen sharing), so support staff can see what’s happening and fix it fast. 

How good support providers solve problems 

Good support should help you get issues fixed quickly and also figure out why they broke in the first place.

Good providers combine technical expertise with real-life experience, and use documented solutions and knowledge bases to speed up their response times. 

They know when to escalate issues to Microsoft, and they keep you updated throughout the process. 

Beyond fixing problems, they look for patterns repeated sync failures, recurring configuration errors, or training gaps and recommend long-term fixes so those issues don’t come back. 

That’s the difference between “helpdesk” support and true partnership. 

Support for managers and leadership 

Managers need support that goes beyond “something’s broken.” 

They rely on accurate data, clear dashboards, and reliable reports. When something looks wrong, it might be a data issue, a configuration problem, or a system performance issue. 

Good support helps leaders: 

• Maintain dashboard accuracy 

• Optimise reports and KPIs 

• Fine-tune system configurations 

• Improve overall system performance 

• Support adoption of the new system and ongoing training 

This kind of strategic support helps turn the system from a daily tool into a genuine management asset. 

How to prevent common Field Service support issues 

Prevention is the easiest way to reduce support requests and keep your system stable. 

• Train users properly. Good training prevents most mistakes. 

• Keep documentation handy. Quick reference guides and videos save time. 

• Standardise devices. Limiting to a few approved models avoids compatibility headaches. 

• Test updates before rolling them out. Sandbox testing avoids mass disruption. 

• Run regular health checks. Catch problems before they affect daily work. 

Support works best when users feel confident and know how to handle smaller issues themselves. 

What should be included in a support agreement? 

A clear support agreement sets expectations and prevents frustration later. 

Key things to include: 

• Response time commitments 
• Coverage hours (standard or extended) 
• Available contact channels (phone, email, chat, portal) 
• What’s included and what isn’t 
• Escalation procedures 
• Regular performance reports 

If your engineers start early or work weekends, make sure your support hours actually match your operating hours. 

How to measure support quality 

You can’t improve what you don’t measure. The best support partners track and share key metrics like: 

• First-time fix rate (ideally 70% or higher) 
• Average resolution time 
• Ticket volume trends 
• User satisfaction scores 
• Recurring issue frequency 
• System uptime and stability 

These indicators show how well your support arrangements are performing and where improvements can be made. 

What does Field Service support cost? 

Support pricing depends on how much coverage you need. 

• Standard support: £25–£35 per user per month. Suitable for most businesses operating during standard hours. 
• Premium support: £50–£75 per user per month. Includes faster response times, extended hours, and proactive monitoring. 
• Enterprise support: £100+ per user per month. Tailored for large or international operations with 24/7 coverage. 

You can also choose pay-per-incident support (£100–£200 per case), but this can become expensive if you need frequent help. 

Training and system optimisation are often billed separately, typically £500–£2,000 per session, depending on scope. 

For most UK businesses, budgeting around £100–£110 per user per month (including licences and support) provides a realistic estimate for ongoing costs. 

A checklist for evaluating a Dynamics 365 Field Service support contract

Before you sign a Dynamics 365 Field Service support contract, run through this checklist with your prospective partner. If they can’t clearly answer most of these points without being prompted, that tells you something about how structured their support process is and how much Field Service experience they actually have.

1. Do they track every ticket from first contact to resolution, with status visible to you?
2. Is there a clear triage process (replicate, fix, escalate)?
3. Do they support all three user groups: field engineers, back office, and management?
4. Do they have experience specifically with the Dynamics 365 Field Service mobile app?
5. Can they remote into engineers’ mobile devices using Microsoft Teams or a similar tool?
6. Have they discussed whether you need open-access or conduit-model support?
7. Do they provide root cause analysis and prevention recommendations for complex issues?
8. What’s their escalation path to Microsoft if the issue is platform-level?
9. Is pricing transparent, with no hidden costs for escalations or out-of-hours support?

You don’t need a “yes” to every single point. But you should get clear, confident answers to most of them. If your prospective partner looks surprised by any of these questions, that’s worth noting.

Going live is exciting, but keeping things running smoothly day-to-day is where the real value lies. 

A strong support partner makes sure your systems evolve with your business, your engineers stay focused, and your investment works harder for you.

Support should remove complexity and give you the confidence to deliver the experience your customers expect.

Frequently asked questions about Field Service support 

If you want to explore what a tailored support package looks like for your team, get in touch with All My Systems. 

Read more

The post What To Look For in a Dynamics Field Service Support Contract appeared first on All My Systems.

Check Pete Murray’s original post https://www.allmysystems.co.uk/what-support-do-i-need-after-going-live-with-field-service-software/ on www.allmysystems.co.uk which was published 2026-03-26 12:29:00