Microsoft Field Service Dispatch Software vs. Dedicated Scheduling Tools
A comparison for teams still scheduling technicians in a spreadsheet and over the phone: Microsoft field service dispatch software, which means Dynamics 365 Field Service on Dataverse, against a purpose built dispatch product such as Jobber or ServiceTitan.
There has to be a better way to do this. That sentence usually arrives somewhere between a scheduling spreadsheet nobody trusts and a phone that will not stop ringing. There is, and the first thing to know is that Microsoft field service dispatch software is not a separate product you can buy. It is Dynamics 365 Field Service, which puts work orders, the dispatcher schedule board, resource scheduling, and the technician mobile app on the same Dataverse as your CRM. Dedicated software such as Jobber or ServiceTitan gives you a purpose built dispatch tool that stands alone. The real choice is an integrated platform against a point solution, compared here on dispatch, mobile, CRM integration, and cost.
Being straight about the bias: Solzet implements Dynamics 365 Field Service, we also build custom field service and CRM applications when neither a platform nor a packaged product fits, and we do not sell Jobber or ServiceTitan. So this page is written the way we would talk it through on a call, including the cases where we would tell you to buy the point solution and spend the difference on your crews. One accuracy note. Feature sets and pricing for every product named here move constantly, so we describe what each kind of product is built to do rather than publishing a feature matrix or a price that will be wrong in a quarter. Check the vendor pages for the current detail, and hold both against the questions further down.
Should you buy a dedicated scheduling tool or Dynamics 365 Field Service?
Buy the dedicated scheduling tool when
Field work is the whole business, the workflow is quote, schedule, do the job, invoice, get paid, and you want to be running next week rather than next quarter. If you have no CRM worth integrating with and nobody whose job is configuring software, a purpose built product that arrives opinionated is the honest recommendation.
Choose the Microsoft option, Dynamics 365 Field Service, when
The same customer already exists in a sales pipeline or a support queue you care about, dispatch has real constraints such as certifications, territories, and equipment, or the field is one operation inside a business that also needs a CRM. Field Service is the field module of a platform, and the platform is most of the value.
Either way, settle this before you buy
Who owns the schedule model once the software exists, and whether your service addresses and asset records are good enough to schedule against. Both products fail in exactly the same way when the answer is nobody and no. Software is the cheap half of getting off the spreadsheet.
What are you actually replacing?
Most of the value of either purchase comes from the structure rather than from any feature, so it is worth naming the baseline. If several of these are familiar, the question is no longer whether to buy something, only which shape of something.
The schedule exists in more than one place
There is the spreadsheet, the version the dispatcher keeps in their head, the messages sent last night, and whatever was agreed on a call this morning. Each is authoritative to somebody. Double bookings and dropped jobs are not carelessness, they are the arithmetic of four sources of truth that never reconcile.
Nobody can answer where the technician is
Not because the information does not exist, but because getting it means interrupting someone who is driving. Every status question costs two phone calls, and the person asking is usually the customer.
The record of the job is a photo on somebody's phone
Serial numbers, before and after photos, the note about the damage that was already there, the signature. It exists, scattered across devices and chats, and it is unsearchable the day a warranty claim or a disputed invoice needs it. When a technician leaves, so does their camera roll.
You cannot see the numbers that would tell you what to fix
Average job duration, first time fix rate, how much of the day is driving rather than working, which jobs are actually profitable. None of it is available, because the data is in free text and images. Decisions get made on instinct, which works until the crew count grows past what one person can hold.
The customer is the last to know
Arrival windows are vague because the schedule is too fluid to promise anything better, and nobody is going to send a proactive message from a spreadsheet. The work can be excellent and the experience around it still costs you the referral.
We wrote about the same costs from the other direction in what dispatching field technicians over WhatsApp really costs, which covers what a group chat hides as a crew count grows.
What is Microsoft field service dispatch software, actually?
Worth clearing up before the comparison, because the search term and the product name are not the same words. Microsoft does not sell a dispatch tool on its own. Here is what you are actually being offered, and what is not in the box.
There is no product called Microsoft Field Service Dispatch
Microsoft does not sell a standalone dispatch tool. What people find when they search for Microsoft field service dispatch software is Dynamics 365 Field Service, where dispatch is one capability inside a module that also carries work orders, customer assets, agreements, inventory, and the technician mobile app. You cannot buy the dispatch board on its own, which matters for the comparison: you are weighing a whole module against a whole product, not one screen against another.
The schedule board is the screen the dispatcher lives on
Bookings appear as blocks across resources and days, with unscheduled work orders queued alongside, filters for territory, skill, and resource type, and a map view of where everyone is. Dragging a booking reschedules it and the technician sees the change. For a dispatcher coming off a spreadsheet, this one screen is most of what they were promised.
The schedule assistant answers who can actually do this job
Rather than an empty calendar to guess against, the assistant takes what the work order requires, matches it against technician characteristics and proficiency, territory, working hours, time off, and travel time, and returns ranked slots that genuinely work. This is the part a simple dispatch board cannot imitate, and it only performs as well as the constraints somebody wrote down.
Resource Scheduling Optimization is the automatic half
A separate solution you deploy and tune, running on a schedule or on demand, that builds routes against objectives you choose such as minimizing travel or maximizing jobs per day. It needs service addresses that geocode, real start locations for every resource, and skills that are maintained rather than set once. Given those, it is genuinely strong. Without them it produces routes no dispatcher will trust, and we see that far more often than an engine problem.
Dispatch is only half a loop until the technician app closes it
The Field Service mobile app is what makes the board true rather than aspirational. Travelling, in progress, and completed flow back from the van, so the dispatcher stops phoning to ask where anyone is, and the photos, parts, readings, and signature land on the work order rather than in a camera roll. Dispatch software that only sends work out and never hears back is a spreadsheet with better colours.
What is not in the dispatch box
Taking a card payment at the door and posting to the ledger happen in whatever finance system you run, so that is an integration. Arrival reminders and on the way messages are built with Power Automate, Customer Insights Journeys, or Power Pages rather than switched on. Both are ordinary work, and both are things the dedicated products tend to ship ready made, which is exactly why the rest of this page is a comparison and not a sales pitch.
How does a platform compare against a point solution, factor by factor?
Microsoft field service dispatch software on one side, a dedicated dispatch product on the other. The dedicated column wins several of these rows outright, and where it does, the table says so rather than manufacturing a counterargument.
| Factor | Dynamics 365 Field Service | Dedicated scheduling software |
|---|---|---|
| Time to a working schedule | Weeks to months. Field Service arrives as a configurable model of work orders, bookable resources, requirements, and territories, and somebody has to decide how yours are shaped before the schedule board is useful. That work is the implementation. | Days. Products in this category are deliberately opinionated: you sign up, add your crew, and drag jobs onto a calendar the same week. This is a real advantage and the main reason the category exists. |
| How scheduling is modelled | Deeply, and explicitly. A work order carries requirements, technicians carry characteristics with proficiency ratings, and territories, working hours, time off, and booking rules all feed the schedule board and the schedule assistant. The engine can only match what you have written down, which is the price of the depth. | Simply, on purpose. A calendar or dispatch board, crews, job types, and usually a light notion of skills or tags. For teams whose real constraint is who is free and who is nearest, simple is not a limitation, it is the correct amount of software. |
| Rescheduling when the day falls apart | Drag the booking on the schedule board and the requirements are checked again, so you are stopped from sending a technician who is not certified for the job or is outside the territory, and optimization can rebuild the rest of the day around the change. The guard rails are the value, and maintaining the constraints is the price of them. | Drag the job, message the crew, carry on. Faster on an ordinary day, and it will let you make the mistake the platform would have blocked. Which of those matters more depends entirely on how much damage a wrongly assigned technician does in your business. |
| Automated optimization | Resource Scheduling Optimization is a separate solution you deploy and tune against your own objectives and constraints. It is powerful and it is honest about its inputs: it needs geocodable service addresses, real resource start locations, and maintained skills, or it produces routes no dispatcher will trust. | Route and drive time optimization is commonly built in and works out of the box on the data the product already has. Less to configure, less to tune, and a lower ceiling once the constraints get genuinely complicated. |
| Technician mobile app | The Field Service mobile app runs on the Power Platform, so the forms technicians see are the forms you configured, offline profiles decide what is available with no signal, and you can add an inspection or a checklist without asking a vendor to build it. | A polished, focused app that a technician can use with no training, built by a vendor whose entire product is that job. You get what they ship. If it fits your work, that is a feature rather than a compromise. |
| Customer communication | Reminders, on the way notifications, and portals are built rather than switched on, using Power Automate, Customer Insights Journeys, or Power Pages. Fully yours, and a piece of work. | Appointment confirmations and technician on the way messages tend to be standard, because for a home services business they are the product. Point to the dedicated tool here without argument. |
| Quoting, invoicing, and getting paid | Field Service prices work orders from products and services and can raise an invoice record, but taking a card payment and posting to the ledger happen in your finance system, which is an integration. Solzet works on Customer Engagement and the Power Platform rather than on the accounting side, so we scope that connection honestly rather than pretending it is free. | Quote to invoice to card payment in one subscription is the core loop of these products, especially for residential trades. If cash collection in the field is your bottleneck, this row alone can decide the purchase. |
| Assets, service history, and maintenance contracts | Customer assets model what you service, including hierarchies of equipment and their full service history, and agreements generate recurring maintenance work orders on a schedule. This is one of the strongest reasons to be on Field Service at all, and it is where the platform pulls clearly ahead for contracted or equipment heavy service. | Recurring visits and basic equipment records are usually supported, at a depth aimed at repeat residential and light commercial work rather than serialized asset fleets under contract. |
| Inventory and parts | Warehouses, van stock, transfers, purchase orders, and returns are part of the module, so parts consumption ties back to the work order and to whatever ERP you run. | Typically lighter. Enough to track what was used on a job, less suited to running truck stock as real inventory that has to reconcile with finance. |
| Integration with CRM | Not an integration. Field Service, Sales, and Customer Service are apps over one Dataverse, so an account, a contact, a case, and a work order are the same records rather than copies kept in step. The salesperson sees the service history, the dispatcher sees the open opportunity, and nobody maintains a sync. | A separate system with its own customer list. Vendors offer connectors and APIs, and they work, but you own a sync: duplicate customers, fields that exist on one side only, and the question of which system is right when they disagree. |
| Reporting and analytics | The data sits in Dataverse, so Power BI can answer questions nobody anticipated, and you can join field data to sales and support data in one model. | Well built dashboards for the metrics the vendor decided matter, which for most teams leaving a spreadsheet is a large step forward. Anything outside that set means exports. |
| Extending it when your process is unusual | Power Automate for logic, model driven app configuration for the interface, and custom PCF components in TypeScript and React where the standard controls run out of road. If your process genuinely differs from everyone else, this is the column that accommodates it. | The vendor roadmap plus available integrations. Constraining, and also protective: you cannot customize yourself into an unmaintainable mess. |
| Identity, security, and the rest of your IT | Microsoft Entra ID sign in, Teams and Outlook alongside it, and Dataverse security roles down to individual columns. If your organization already runs on Microsoft 365 and has a security posture to satisfy, this is meaningful rather than cosmetic. | Vendor accounts and vendor permissions, usually with single sign on available on higher tiers. Fine for most field businesses and a real conversation in a regulated one. |
| Who has to own it | Someone must own the scheduling model, the security roles, and the change queue, whether that is an internal admin or a partner on a support arrangement. Twice yearly release waves are a routine to absorb rather than a crisis. | An office manager can administer it, which is exactly the point. Upgrades happen to you and are largely invisible. |
| Cost shape | Licensed per user per month, plus an implementation that is a project, plus a budget for change afterwards. The licence is rarely the number that decides anything. | Subscription tiers by user or feature level, low setup cost, predictable from month one. Costs tend to appear later as tier upgrades, add on modules, and the integration work you did not plan for. |
| Best fit | Service organizations where the field is one part of a business that also sells and supports, where scheduling has hard constraints, where equipment under contract has to be tracked, or where you already run on Microsoft and want one customer record. | Field first businesses, especially residential trades, that need scheduling, mobile, and cash collection working quickly, with no CRM to integrate and no appetite for an implementation project. |
When would we tell you to buy the dedicated product?
We would rather say this than win an implementation that was never a good fit. If most of these are true, buy the point solution and spend the difference on your crews.
You need to be running in days, not after a project. Nothing in the Microsoft column beats a product you can sign up for on Monday and dispatch from on Wednesday.
Field work is the entire business and there is no CRM to integrate with. The main argument for Field Service is the shared customer record. If there is nothing to share it with, that argument does not apply to you.
Getting paid on the doorstep is the bottleneck. Quote, invoice, and card payment in one subscription is what these products are for, and building the same loop across Dynamics 365 and a finance system is a project, not a setting.
Nobody in the company configures software. An opinionated product that an office manager can run is worth more than a flexible one with no owner. We have taken over enough stalled implementations to say that plainly.
The work is genuinely standard. If your jobs look like everyone else's jobs in your trade, a product shaped around that trade will fit better than a platform you have to shape yourself.
And if neither fits, because the dedicated products cannot model the way your jobs really run but per technician Microsoft licensing will not pay back, there is a third route. See our Custom CRM Development option for a tailored field service app on a stack you own.
When is Dynamics 365 Field Service worth the implementation?
The other side, stated as plainly. These are the situations where the platform earns back the project it costs to start.
One customer record across sales, service, and the field. The same account, contact, case, and work order live in one Dataverse, so nobody maintains a sync and nobody argues about which system is right.
Scheduling with real constraints. Certifications and proficiency, territories, working hours, time off, required equipment, and multi day or multi resource bookings can all be modelled explicitly rather than remembered by the dispatcher.
Equipment under contract. Customer assets with service history and agreements that generate recurring maintenance work orders are hard to replicate in a tool built around one off residential jobs.
You already live in Microsoft. Entra ID sign in, Teams and Outlook, Power BI, and Dataverse security roles are things you already run rather than a new vendor relationship, and the field data lands where your other reporting already is.
Your process is not the standard process. Power Automate, model driven configuration, and custom PCF controls mean an unusual workflow is a configuration question rather than a feature request in somebody else's backlog.
How do you manage multi-day installations and projects?
Field Service is built around the single visit. A work order is raised, a technician is booked, they arrive, they do the job, they close it. That model is why the schedule board and the schedule assistant work as well as they do, and it is also the first thing that breaks for anyone whose jobs are installations, commissioning, refits, or deployments that run for days or weeks with materials staged in advance and more than one trade involved.
The good news is that this is a solved problem with two legitimate architectures, and choosing between them is the whole exercise. Either you keep the job as one work order and model the days as bookings, which is the right answer far more often than vendors admit, or the job becomes a project in Dynamics 365 Project Operations and Field Service takes over after handover. What follows is the configuration each one actually needs, what each costs you, and a flow for deciding without a workshop.
Approach one: one work order, one booking for every day on site
No extra module and no custom tables. The job stays a work order, the days become bookings, and eight configuration decisions separate a multi day job that works from one that closes itself on Tuesday. These are the steps, in the order we set them up.
Keep one work order and give it one booking per working day
The two instincts are to create a single booking five days long, or five separate work orders. Both cause trouble. One long booking makes the schedule board unreadable, distorts travel time, and hides what the crew actually has capacity for. Five work orders scatter the materials, the photos, the readings, and the service history of one job across five records nobody can reconcile when a warranty claim arrives. The pattern that holds up is one work order that stays open for the duration of the job, with a separate booking for each day the crew is on site, each sitting inside that resource's working hours. The work order is the job. The bookings are the attendance.
Model the crew as a requirement group when more than one person has to be there
A resource requirement group expresses what a single requirement cannot: two engineers together on day one and one for the rest of the week, or an engineer plus a lift that has to be booked at the same time. Build the group as a template where the same shape repeats across jobs, then let the schedule assistant fill it, rather than booking people one at a time and hoping the calendars line up. If you only ever book individuals, the day a second person is genuinely required is the day the schedule quietly lies to you.
Fix the booking statuses before anyone works a multi day job
This is the configuration step most teams skip and the one that creates the mess. Every booking status maps to a Field Service status, and a technician who ends day two with a status mapped to Completed starts closing a job that has three days left. Add a status such as Paused, returning tomorrow, mapped to On Break or to your own equivalent, and make it the normal way a day ends. Only the last booking on the job gets a Completed status. Decide separately who is allowed to move the work order system status to completed, because on a multi day job that should be a supervisor rather than whoever left site last.
Turn on booking journals so time adds up across the days
Booking journals capture actual travel, work, and break time against each booking, so a job that ran over four days rolls up into one set of actuals instead of the estimate somebody typed in week one. Decide up front whether that time flows into billable work order services automatically or after a review step. On a long job the gap between hours recorded and hours billed is exactly the conversation the customer will want to have, and you want it backed by a record rather than by memory.
Stage the materials for the whole job, then record consumption per visit
Put the expected products on the work order before day one, move them to the van or a site warehouse as one inventory transfer, and have technicians record what was actually used each day rather than one lump at the end. That gives you a job you can reconcile: what was allocated, what was consumed, what came back. Raise purchase orders for anything long lead against the job at the start, because the most common reason a four day install becomes a six day install is a part that was ordered on day three.
Break the work into ordered service tasks so progress is visible without a phone call
On a multi day job the end of a day should update a record, not send a text message. Service tasks per phase, in order, with duration estimates, tell the dispatcher where the job actually got to and what tomorrow starts from. The same tasks become the checklist the technician sees in the mobile app, which is the only version of this that gets kept current, because it is the version that is in front of the person doing the work.
Decide what finished means, and who signs it
Sign off on a job that took a week is rarely the last technician handing over a screen at five on Friday. Configure a final commissioning or handover booking with the inspection, the readings, and the photographs it requires, and keep the work order open until that is done. If the install creates or updates a customer asset, do it here, because that asset record is what every future service visit, agreement, and warranty question will hang from.
Know where this approach stops
Everything above gives you one job, one history, real actuals, and a schedule board that tells the truth, and for the large majority of multi day installations that is the correct amount of software. What it does not give you is a budget, a plan with dependencies between phases, staged billing against milestones, or margin per job with cost rates behind the hours. If you find yourself building custom tables for phases, percentage complete, and milestone invoicing on top of work orders, you have arrived at the second approach by the expensive route, and you now own the maintenance of it.
How do you record daily sign-off, evidence and parts used on a multi-day work order?
When a government or regulated contract pays against what happened each day, the structure above is necessary but not sufficient. The customer, the auditor or the contracting authority wants a record per day on site: who attended and when, what was done, which parts were fitted, the evidence, and a signature from their representative. One work order with one requirement split into daily bookings still holds, and these are the additions that turn each booking into a record that contract will accept.
Keep one requirement and let it produce the daily bookings
The structural answer comes first, because everything else hangs from it. The work order carries one resource requirement for the whole job, with its start and end dates, and the schedule assistant books it as a series of daily bookings inside each technician working hours rather than one block across the week. Depending on your version and settings this is done by booking the requirement across its date range or by creating the daily bookings from it, so confirm the behaviour against current Microsoft documentation. Not a work order per day: products, sign-off and invoicing all belong to the one job, and each day is visible as its own booking underneath it.
Capture a sign-off for each day, not only at the end
The standard work order signature holds one signature for the job, which is the final handover, not the daily one a contract may require. For daily sign-off, add a small daily sign-off table related to the booking, or signature and signer columns on the booking itself, holding the name and role of the customer representative, the signature, the time and a short note of what was accepted. Make it required before a day can end with the paused status described above, so no day closes without it.
Attach the day evidence to that day
Photos, readings and completed service tasks prove what happened, but on a multi day job they only prove it for a specific day if they are tied to the booking rather than dropped on the work order in one pile. Relate photos and notes to the daily record, capture service task results with the booking they were completed on, and keep the capture time. What an auditor asks for and which record holds each piece of evidence is set out in our guide to Field Service proof of work, so it is not repeated here.
Record parts used against the booking that consumed them
Parts live on the work order, not on the booking. There is no separate standard booking product table: a work order product line can be associated with a booking through its booking lookup, so a line marked Used on Wednesday references the Wednesday booking. Stage the expected parts as Estimated lines before day one, and when only part of a line is fitted on a given day, split it so the used quantity sits on its own line linked to that booking. The same applies to work order services for labour. Parts used per day then comes from a simple view of Used lines grouped by booking, while the work order still totals the whole job.
Decide how daily records relate to invoicing
Invoicing in Field Service works from the work order and its Used lines, normally once the job is completed and posted, so the daily records support the invoice rather than create one each day. If the contract pays per day or per stage, agree whether finance invoices from the daily report through your existing finance integration, or whether the staged billing means the job belongs in Project Operations, as the decision flow below asks.
Produce a per day report an auditor or public sector contract will accept
Generate one report per booking: work order and contract reference, site and asset, the crew with arrival and departure times from the booking status history and booking journals, the tasks completed, the parts used that day, the photos, and the customer sign-off. Store the generated document on the daily record, remove edit rights on signed days from field and dispatch roles, and enable auditing on the booking, the daily sign-off and work order product tables, so a correction after sign-off is visible rather than silent.
Make the whole daily flow work offline
Crews on installation sites often have the worst signal of anyone. The mobile offline profile has to include the booking, the work order products, the daily sign-off table, notes and files, or the technician finds the signature screen missing on day three. Capture the signing time on the device and keep it separate from the time the record synced, so a sign-off that reached the server that evening is still explainable. The failure modes of offline capture and how to prevent data loss are covered in our guide to offline field apps that do not lose data.
Approach two: run the job as a project in Dynamics 365 Project Operations
When the job has a plan, a budget, and staged billing behind it, work orders are the wrong container and no amount of configuration fixes that. Project Operations is the module built for it, and it sits next to Field Service rather than replacing it.
What actually changes
The job stops being a work order with bookings attached and becomes a project with a work breakdown structure: phases, tasks, dependencies, and a schedule that recalculates the rest of the plan when day two slips. Resource requirements come out of the plan as generic roles and are then filled with named people, a project contract carries the billing model whether that is milestones or time and materials, and cost and bill rates sit behind every hour, so margin exists while the job is running rather than being discovered after the invoice.
It is the same platform and the same people
Project Operations and Field Service both sit on Dataverse and both build on the same universal resource scheduling foundation, so an engineer is one bookable resource with one calendar whether they are assigned to a project task or booked against a work order. That is the practical argument for this pairing over bolting a separate project tool onto the side: you avoid two systems that each believe they own somebody's Tuesday, which is the failure mode of every project tracker that lives outside the scheduling engine.
The pattern most equipment businesses actually want
Run the installation as a project, with its plan, its staged billing, and its budget against actual. The moment the equipment is handed over, everything after it runs as Field Service work orders against the customer asset the project created: the reactive calls, the agreements that generate preventive maintenance, the warranty visits. One customer record, one asset history, two shapes of work, and a clean line between them at handover.
What it costs you, said plainly
A second module means licences for everyone who plans, approves, or books time to it, an implementation with its own discovery and its own configuration decisions, and an integration to whatever finance system issues the statutory invoice. It also means somebody has to own project templates, roles, and rates after go live, and it means people filling in time every week. A project rollout with immaculate configuration and poor time entry produces numbers worse than the spreadsheet it replaced, because now they look official.
When it is plainly the wrong answer
Three day installs at a fixed price with one crew. Jobs where the only thing you need out the other end is a labour and materials tally. Any situation where nobody will own the plan once the consultants leave. Adding a project module because installations feel like projects, with no billing or margin question that work orders fail to answer, buys administration and nothing else.
We are not going to relitigate that implementation here, because it has its own page. The deployment shape, mapping the contracts you really sell, the resource role and rate model, time and expense adoption, and the integration to whichever system issues the statutory invoice are covered in implementing Dynamics 365 Project Operations. Read the deployment section of that page before you budget for this option, because that decision sets the size of the programme more than any feature does.
The two approaches side by side
The same job, modelled two ways. Read this as a trade rather than as a ranking: the left column is cheaper, faster, and correct for most installation work, and the right column buys you planning and margin at the price of a second implementation.
| Factor | Work order with bookings per day | Project Operations project |
|---|---|---|
| The unit of work | One work order, one booking per day on site, service tasks for the phases inside it. | A project with a work breakdown structure, tasks with dependencies, and resource assignments generated from the plan. |
| Planning depth | Sequence and estimated durations. There is no critical path and nothing recalculates when a day is lost. | Dependencies, phases, and a schedule that reflows when something slips, which is the reason to be here at all. |
| Billing | Priced from products and services on the work order, invoiced when the job is done or on your normal cycle. | Contract lines with milestones, fixed price, time and materials, or a mix, billed as the project progresses. |
| Materials and parts | Native. Van stock, transfers, purchase orders, and consumption recorded per visit against the job. | Expense and material estimates against the plan, with the physical parts side still handled where inventory actually lives. |
| Time capture | Booking journals from the mobile app, so actual travel and work time roll up per work order with no separate habit to build. | Weekly time entry against project tasks, which is a genuine behaviour change and the thing most likely to decide whether it worked. |
| Cost and margin | Hours and parts consumed, which reporting can turn into a labour and materials view. No cost rates, so no margin in the system. | Cost and bill rates per role, budget against actual, and margin visible while the job is still running. |
| Setup effort | Configuration inside a module you are already implementing. Days of work, not a separate programme. | A second implementation with its own discovery, contract mapping, rate model, and finance integration. |
| Who has to keep it current | The dispatcher and the crew, using the board and the app they already use every day. | A project manager who maintains the plan, plus everyone who books time to it every week. |
| Best fit | Installations of a few days to about two weeks, continuous work by the same crew, billed on completion or on time and materials. | Multi week or multi phase deployments, staged or milestone billing, dependent trades and subcontractors, margin reported per job. |
The decision flow, five questions in order
Work down these in sequence and stop at the first yes. This is the flow we run on a whiteboard in a scoping session, and it settles the architecture in about twenty minutes for most installation businesses.
Does the customer see a plan, a budget, or staged payments for this job?
Yes: Go to Project Operations. Milestone billing, budget against actual, and a plan you can put in front of a customer are the things work orders do not have and should not be modified to have.
No: Continue. A job invoiced on completion or on time and materials does not need a project structure in order to be billed correctly.
Do phases depend on each other, with different trades or subcontractors waiting on the one before?
Yes: Go to Project Operations. Reflowing everything downstream when day two overruns is precisely what a work breakdown structure is for, and it is the part that cannot be imitated with a sequence of bookings.
No: Continue. Continuous work by the same crew across consecutive days is a booking pattern, not a plan.
Do you need margin on this job while it is running, with labour cost rates behind the hours?
Yes: Go to Project Operations, or accept that margin arrives afterwards from finance. Work orders give you actual hours and consumed parts, which Power BI will turn into a labour and materials picture, but there are no cost rates behind them.
No: Continue. Hours and parts against the job are usually enough for operational control.
Is the job longer than roughly two weeks, or does it run past a handful of resources?
Yes: Treat it as a project even where the first three answers were no. Past that size the coordination is the expensive part, and a plan that maintains itself is worth more than the module it costs.
No: Use work orders with one booking per day. Configure them the way the steps above describe and stop there. This is where most installation businesses correctly land.
Will there be service visits, warranty work, or a maintenance agreement afterwards?
Yes: Whichever approach wins for the installation, the life after handover belongs in Field Service against the customer asset. Make sure the install creates or updates that asset record, because it is the join between the two halves and the thing every later visit hangs from.
No: Then the asset model matters less and the choice above stands on its own merits.
If the honest answer to most of those is maybe, start with work orders configured properly. Moving a job shape from work orders to projects later is ordinary work. Unpicking a half built project module someone hand rolled inside Field Service is not, and it is one of the more common things we get called in to remove. For a sense of what the work order side looks like when it is done well, including asset modelling, mobile capture, and automated maintenance work orders, our field service digitization case study for a European manufacturer covers a rollout across more than fifty technicians and three thousand pieces of equipment.
Which five questions settle it?
Answer these honestly and the choice usually makes itself. They are also the questions we ask on a first call, before anyone opens a demo environment.
Does the same customer already exist somewhere else in your business?
If a salesperson quotes them, a support person answers their calls, and a technician visits them, the shared record is the whole argument for an integrated platform, and it compounds every year. If the field team is the only team that touches the customer, that argument is worth very little to you and you should weigh the other rows instead.
Is your scheduling problem about availability, or about constraints?
Who is free and who is nearest is a calendar problem, and a dedicated tool solves it well. Who is certified for this, who is inside the territory, who has the part on the van, and which two people have to arrive together is a modelling problem, and that is what Field Service requirements, characteristics, and resource requirement groups exist for.
Do you service equipment you are contracted to maintain?
Serialized assets, service history that has to survive a change of technician, and agreements that generate the next maintenance visit automatically point firmly at Field Service. Ad hoc jobs at an address point the other way.
Who will own the system in eighteen months?
Name the person. If nobody has the time or the inclination to own a scheduling model and a change queue, an opinionated product that upgrades itself will serve you better than a platform with no owner, regardless of which is technically more capable. If the answer is a partner, agree what that costs before you buy, not after.
Is your service address and asset data good enough to schedule against?
Both products are only as good as the addresses they can geocode and the equipment records they can attach a history to. A cleanup pass before the software arrives is the least glamorous and highest return work in the whole project, and skipping it does not save time, it just relocates the failure to go live.
How do you compare cost without kidding yourself?
We do not publish prices for products we do not sell, and we will not put an implementation figure on a page before anyone has described the scope. What we can give you is the shape of the comparison and the line items that get left out of it.
Count every seat that needs one, not just technicians
Dispatchers, schedulers, office staff who raise work orders, managers who only read reports, and subcontractors all sit somewhere in a licensing model. Dynamics 365 licences vary by the depth of access a user needs, and the dedicated products tier by user and feature level. The cheapest quote is usually the one that counted the fewest people.
Implementation is a real number on one side and near zero on the other
This is the honest asymmetry. A Field Service rollout has a scoping, configuration, data, and adoption cost. A self serve product mostly does not. Anyone comparing licence lines alone is comparing the least important column.
Data preparation belongs in the budget of both options
Deduplicating accounts, making service addresses geocodable, and building an asset list happens whichever product you buy. It is frequently the largest single piece of effort, and it is usually left out of both business cases.
Integration is where point solution costs surface later
The dedicated tool is cheap until the customer list has to match your CRM, the invoices have to reach your accounting system, and someone has to own the sync when the two disagree. That work is not free, it just arrives in month nine instead of month one.
Budget for change, not just for go live
The process you configure in month one is not the process you run in year two. On the platform side that is a change queue and a support arrangement. On the point solution side it is tier upgrades and add on modules. Both are ongoing, and neither is on the first quote.
What does the move take, whichever you choose?
Buying the software is the cheap half. These five pieces of work decide whether the schedule board is trusted in week one or quietly abandoned by month three, and they apply to a point solution exactly as much as to a platform.
Clean the customer and address data first
Duplicate accounts produce duplicate work orders, and an address that will not geocode cannot be optimized, only guessed at. A deduplication and address pass before anything is loaded is the work that decides whether the schedule board is trusted in week one.
Write the scheduling model down before configuring it
Sit with the dispatcher and capture what they actually know: which jobs need which certification, which crews start from home and which from the depot, which customers only accept mornings, how overtime works. That document is the specification for either product, and its absence is the single most common reason a schedule board goes unused.
Decide what a completed job must record
Photos, serial numbers, parts used, readings, signature. Agreeing this before you configure forms is what turns a mobile app from an extra step for the technician into the thing that replaces the paperwork they already hate.
Roll out in phases and start with dispatch
Scheduling and dispatch onto a real board first, then mobile capture, then analytics and customer notifications. Crews absorb one change at a time, and each phase proves itself before the next one is funded.
Plan for the technicians, not just the software
The rollout succeeds or fails on whether the people in vans use it. That means the app being faster than the old way rather than more thorough, training that happens in a van rather than a meeting room, and someone who answers the phone in the first fortnight.
The failure modes are covered in more depth in why mid market companies fail at Field Service implementation, and you can see what an actual delivery looked like in our field service case study for a European manufacturer. If a rollout has already stalled somewhere between the two, our rescue and takeover guide covers how we read a half built environment and move it forward.
How does Solzet implement Dynamics 365 Field Service?
For completeness, the other side of the comparison stated plainly, so you can hold it against whatever a vendor sales team offers you.
We scope the schedule before we configure anything
Work order types, incident types, characteristics and proficiencies, territories, working hours, and booking rules come out of sessions with the people who dispatch today. We write the model down and validate it against a real week of jobs before anyone relies on the board.
We treat the data as part of the project
Accounts and service addresses that geocode, an asset model that matches what you actually service, and work order and product data that reflects what crews really do. This is where Field Service rollouts are won, and it is the part that gets cut from rushed proposals.
We extend the platform rather than working around it
Power Automate for the logic, model driven configuration for the forms and the mobile experience, Power BI for the numbers leadership asks for, and custom PCF components in TypeScript and React where the standard controls are not enough. Extending Field Service is ordinary work for us rather than a special case.
We build on proper solution lifecycle management
Separate development, test, and production environments, changes made in unmanaged solutions and promoted as managed ones, so a change can be reviewed and rolled back instead of edited live. It is also the only way ongoing support means anything, since you cannot support what you cannot version.
We stay inside our scope and say where it ends
On the Microsoft side we deliver Dynamics 365 Customer Engagement and the Power Platform: Sales, Customer Service, Field Service, and Customer Insights on Dataverse. Outside Microsoft we build custom CRM on React, Node.js, PostgreSQL, and .NET. We do not implement accounting or ERP systems, so where invoicing and the ledger are concerned we scope the integration to whichever finance system you run rather than claiming the whole stack.
Certified engineers in one time zone
We deliver from a single hub in Yerevan, Armenia, at GMT+4, a working day that overlaps Western European hours and reaches into the US morning. Our engineers hold Microsoft certifications including MB-240 for Field Service, MB-210 and MB-230 for Sales and Customer Service, and PL-200, PL-400, and PL-600 for the Power Platform.
More detail on the service is on our Dynamics 365 consulting page, the Power Platform layer around it under Power Platform consulting, and the operational context for equipment heavy service on our manufacturing industry page.
What do buyers ask about field service dispatch software?
Is Microsoft field service dispatch software a separate product?
No, and this trips up most first searches. There is no standalone Microsoft dispatch tool to put next to a dedicated product feature for feature. Microsoft field service dispatch software is Dynamics 365 Field Service, where dispatch is one capability, the schedule board, the schedule assistant, and Resource Scheduling Optimization, inside a module that also carries work orders, customer assets, agreements, inventory, and the technician mobile app, all on the same Dataverse as your CRM. Licensing is per user by the depth of access each person needs, and there is no dispatch only tier, so the real comparison is a whole platform against a whole product.
What does a dispatcher actually do all day in Microsoft field service dispatch software?
They work from the schedule board: unscheduled work orders queued on one side, bookings laid out as blocks across technicians and days, filters for territory and skill, and a map of where the crews are. For anything with a constraint attached they use the schedule assistant, which takes what the job requires, matches it against certifications and proficiency, working hours, time off, territory, and travel time, and offers slots that actually work rather than an empty calendar. When the day changes they drag the booking, and the requirements are checked again so an uncertified technician cannot quietly end up on the job. Meanwhile status changes come back from the mobile app, which is what removes the phone calls asking where anyone is.
We only need dispatch. Is the Microsoft option still the right buy?
Often not, and we would rather say so. If dispatch really is the whole requirement, nothing else in the business touches the same customer, and the schedule is mostly about who is free and who is nearest, a dedicated product will have you dispatching within the week for a fraction of the effort. The Microsoft option earns its implementation when dispatch is attached to something else: one customer record shared with sales and support, equipment under contract with a service history, or constraints such as certifications, territories, and required parts that have to be enforced rather than remembered. Buying a platform to use one screen of it is a poor trade, and we have been called in to unpick that more than once. If a packaged product cannot handle a rule that is specific to your business and Microsoft licensing still does not pay back, a custom-built dispatch and CRM app is the third option, and we build those too.
We are scheduling in Excel and over the phone. Is Dynamics 365 Field Service overkill for us?
Sometimes, and it depends on one thing more than size: whether the same customer already exists somewhere else in your business. If sales quotes them and support answers their calls, Field Service on Dataverse means one customer record instead of a sync, and that is worth an implementation project. If the field team is the only team that touches the customer and the schedule is mostly about who is free and who is nearest, a dedicated product such as Jobber or ServiceTitan will get you off the spreadsheet faster and cheaper, and that is a legitimate answer. The step that matters most is leaving the spreadsheet, not which product replaces it.
What is the actual difference between Dynamics 365 Field Service and software like Jobber or ServiceTitan?
One is a module of a platform and the other is a product. Dynamics 365 Field Service adds work orders, bookable resources, scheduling, assets, agreements, and a technician mobile app to Dataverse, the same database that carries your accounts, contacts, cases, and opportunities, and everything on it can be extended with Power Automate, Power Apps, and Power BI. Dedicated field service management software is built end to end around one workflow, typically quote, schedule, complete the job, invoice, and take payment, and it arrives configured for that. The platform gives you depth and one customer record at the cost of an implementation. The product gives you speed and simplicity at the cost of a ceiling and a customer list that lives outside your CRM.
We already use Microsoft 365. Does that make Dynamics 365 Field Service the obvious choice?
It is a genuine advantage but not a decision on its own. Entra ID sign in, Teams and Outlook alongside the work, Power BI over your field data, and Dataverse security roles are real savings in administration and in security review. What it does not do is remove the implementation. Field Service still needs a scheduling model, clean addresses, an asset model, and an owner. Microsoft 365 makes the platform cheaper to run, not cheaper to start.
Which one actually costs less?
On licence lines the dedicated products are usually lower, and on total cost the answer depends on integration and on how many people need a seat. We deliberately do not publish prices for products we do not sell, since they change and quoting them would only mislead you. What we can tell you is which line items decide it: every seat including dispatchers and office staff rather than technicians alone, an implementation cost that is real on the Dynamics side and close to zero on the other, data preparation that both options need and neither business case includes, integration work that arrives around month nine on the point solution side, and a budget for change in year two. Comparing subscription costs alone compares the least important column.
Can Dynamics 365 Field Service handle multi day installations, or is it only built for single visits?
It handles them, but only if you configure for it, because the out of the box shape really is one visit. The pattern that works is one work order that stays open for the whole job, with one booking for each day the crew is on site inside their working hours, rather than a single booking five days long or five separate work orders. Three configuration decisions make or break it. Booking statuses need a paused or returning status so that ending a day does not map to Completed and start closing the job. Booking journals need to be on so actual travel and work time roll up across every day into one set of actuals. Materials should be staged onto the work order up front and consumption recorded per visit, so what was allocated, used, and returned can be reconciled. Add ordered service tasks for the phases and a final commissioning booking, and a dispatcher can see where a week long job actually got to without ringing anybody.
How do we capture a daily sign-off on a multi day Field Service work order?
Keep one work order with one resource requirement split into daily bookings, and add a daily sign-off record related to each booking, or signature and signer columns on the booking, because the standard work order signature holds one signature for the whole job. Capture the customer representative name, role, signature and time on the device, attach that day photos and task results to the same record, and require the sign-off before the day can end with the paused status. Generate a per day report from it and lock signed days against editing by field roles.
Which record shows the parts used on a specific day of a multi day job?
The work order product line. Parts sit on the work order, not on the booking, and there is no separate standard booking product table, but each work order product line can be associated with a booking through its booking lookup. Stage expected parts as Estimated lines, mark what was fitted as Used against the booking for that day, and split a line when only part of its quantity is used, so a view of Used lines grouped by booking gives the parts used per day while the work order still totals the job.
What per day record will an auditor or a public sector contract accept for field work?
A report per booking that ties together the contract and work order reference, the site and asset, the named crew with arrival and departure times from the booking status history and booking journals, the tasks completed, the parts used that day, the photos with capture times, and the customer representative signature. Store the generated document on the daily record, remove edit rights on signed days from field and dispatch roles, and keep Dataverse auditing on so any later correction is visible. It must also work offline, with the signing time captured on the device.
When should a multi day job be a Project Operations project instead of a Field Service work order?
When the answer to any of four questions is yes. Does the customer see a plan, a budget, or staged payments, meaning you need milestone billing rather than one invoice on completion. Do phases depend on each other, with trades or subcontractors waiting on the one before, so the schedule has to reflow when day two overruns. Do you need margin while the job is running, with cost rates behind the hours rather than a labour and materials tally afterwards. Is the job longer than roughly two weeks or spread across more than a handful of resources. If all four are no, work orders with a booking per day are the cheaper and better answer and you should stop there. The warning sign that you have chosen wrong is building custom tables for phases, percentage complete, and milestone invoicing on top of work orders, which is arriving at Project Operations by the expensive route and then owning the maintenance of it.
Can we run the installation as a project and the maintenance afterwards in Field Service?
Yes, and for equipment businesses that is usually the right architecture. Project Operations and Field Service both sit on Dataverse and both build on the same universal resource scheduling foundation, so an engineer is one bookable resource with one calendar whether they are assigned to a project task or booked on a work order, which is what stops two systems from each thinking they own the same Tuesday. The installation runs as a project with its work breakdown structure and its staged billing, the handover creates or updates the customer asset, and everything after that runs as work orders and agreements against that asset: warranty visits, reactive calls, and preventive maintenance generated on a schedule. The asset record is the join between the two halves, so getting it created properly at handover matters more than any other single step. The two modules are licensed separately and Project Operations is its own implementation, which we cover on our Project Operations implementation guide.
Can Dynamics 365 Field Service handle skills based scheduling and route optimization?
Yes, and the depth is one of the main reasons to choose it. Work orders carry requirements, technicians carry characteristics with proficiency ratings, and territories, working hours, time off, and booking rules constrain what the schedule board and the schedule assistant will offer. Resource Scheduling Optimization is a separate solution you deploy and tune to your own objectives. The condition attached is that the engine can only use what is written down: every resource needs a real starting location, every service address has to geocode, and skills have to be maintained rather than set once. When we are called into a Field Service rescue, bad optimization is almost always a data problem rather than an engine problem.
What is the technician mobile app like, and does it work with no signal?
The Field Service mobile app runs on the Power Platform, so technicians see the forms and business logic you configured rather than a fixed vendor screen, and offline profiles define which records and views are available with no connection, syncing when the device is back online. That flexibility is the trade: a dedicated vendor app is usually more polished out of the box because the vendor designed every screen for one job, while the Field Service app is shaped by whoever configures it. Which is better depends entirely on whether the effort of configuring it gets put in.
Can we start with scheduling and add the rest later?
Yes, and it is how we would recommend doing it. Get dispatch onto a real schedule board first so the spreadsheet can be retired, then mobile capture of photos, parts, readings, and signatures, then analytics and customer notifications, then agreements and preventive maintenance if you service equipment under contract. Each phase is usable on its own, crews absorb one change at a time, and each stage proves its value before the next is funded. A single big bang rollout is the pattern we most often find behind a stalled implementation.
Can you move us onto Dynamics 365 Field Service later if we start with a dedicated product?
Yes, and starting with a point solution is not a mistake you have to apologize for later. You arrive with something more valuable than the software you leave behind: a real job history, a customer list that has been used rather than typed once, and a team that already works to a schedule. The migration is mostly customers, service addresses, assets, and history into Dataverse, plus rebuilding the scheduling model properly rather than transplanting it. We also take over Field Service environments that another partner started and left half configured, which is a different exercise and a common one.
We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.
Already decided on Microsoft and looking for someone to build it? See our Dynamics 365 Field Service implementation partner page, which starts with a fixed scope feasibility sprint that ends in a working pilot rather than a proposal.
Not sure which side of this you are on?
Tell us how you dispatch today, what the hard constraints are, and what else in the business touches the same customer. You will get a straight answer about whether Dynamics 365 Field Service is worth the implementation for you, including the answer where it is not. Solzet is a CRM consultancy in Yerevan, Armenia, delivering Dynamics 365, the Power Platform, and custom-built CRM to clients and Microsoft partners across Europe and the US.