Field service schedule: build one that survives dispatch

A field service schedule is one row per job: assignee, skill, customer window, drive time, and the part on the van. For a US shop of 10 to 40 technicians, one shared spreadsheet is still safe while a single dispatcher can see every booking. It fails when that file cannot block a double booking, a missing certification, an unreachable window, or a second copy the crew already follows. As of October 2026, Dynamics 365 Field Service is USD 105 per user per month, paid yearly, informational on Microsoft's US page, and checkout can differ. Build the columns below before you price that license.

What each row of a field service schedule has to hold

The appointment time is the last column you fill, because the row is a constraint list. Microsoft describes four kinds of work a commercial schedule has to carry: reactive break-fix, agreement-based preventive maintenance that generates work orders on an interval, IoT predictive work, and multi-day project work that needs different specialists in sequence. A work order, in that same product overview, carries tasks, parts, labor, required characteristics, and a location. Your sheet should carry the same facts even if the software comes later.

Use one row per visit, including a return trip. A helper who rides along gets their own row tied to the same job number, so you can see that two people are committed for the same hours.

• Job number and type (What you write: Work order id, plus break-fix, agreement PM, predictive, or multi-day · Why the dispatcher needs it: Priority and staffing differ by type)
• Customer window (What you write: Earliest and latest arrival the customer accepted · Why the dispatcher needs it: A start time inside the window is the promise)
• Promised start and end (What you write: The slot you told the customer, separate from the window · Why the dispatcher needs it: The window is the range. The promise is the slot)
• Duration (What you write: On-site hours, excluding drive · Why the dispatcher needs it: Drive is its own block)
• Skill or certification and rating (What you write: Named characteristic and the minimum rating · Why the dispatcher needs it: A general tech on a rated job is a wrong dispatch)
• Territory (What you write: The patch the resource is allowed to cover · Why the dispatcher needs it: Keeps a distant tech off a local board)
• Site address (What you write: A complete service address · Why the dispatcher needs it: Travel math needs a point, and so does the crew)
• Travel block (What you write: Minutes before the job, and the prior stop it is measured from · Why the dispatcher needs it: An 8:00 start with a 45-minute drive is a 7:15 departure)
• Parts and van (What you write: Part numbers and the warehouse or truck that should hold them · Why the dispatcher needs it: A booked tech with an empty van is a second trip)
• Priority (What you write: Emergency, same-day, or planned · Why the dispatcher needs it: Decides what moves when the day breaks)
• Second tech or helper (What you write: Name, skill, and hours, or blank · Why the dispatcher needs it: Sequence work fails when the second person is only a note in the margin)

BuildOps, in its August 2025 scheduling guide, says proper scheduling "prevents double bookings". The column that does that work is a single assignment of person plus start plus end, with no second row allowed to overlap those hours. A calendar color is a weaker version of the same column.

A filled Tuesday row for a 22-technician HVAC company

Assume a 22-technician HVAC company in one metro, eight of them with EPA certification and a rating your office treats as the minimum for commercial refrigerant work. Tuesday has 31 jobs. One of them is a rooftop unit at a clinic.

• Job: WO-4418, break-fix, priority same-day
• Customer window: 10:00 to 14:00
• Promised start and end: 10:30 to 12:30
• Duration: 2.0 hours on site
• Skill and rating: EPA certification, minimum rating your office requires for commercial refrigerant
• Territory: North
• Site: Clinic address with a dock entrance, written out in full
• Travel block: 35 minutes after the residential call that ends at 9:55 on the same tech
• Parts and van: Compressor and contactor, van 14, counted that morning
• Second tech: Blank. Electrical support is a separate row only if the diagnosis needs it

Read the row as a chain. The tech finishes the residential job at 9:55, drives 35 minutes, and arrives at 10:30, inside a window that runs from 10:00 to 14:00. The 2.0 on-site hours still end at 12:30, which leaves the afternoon for a planned agreement visit if the morning holds. If the compressor is still not on van 14, the row stays undispatchable until that van shows the compressor, and any new arrival still has to fall inside 10:00 to 14:00. A second version of the workbook that still shows this tech free at 10:30 is how the office books a water heater over the top of WO-4418.

That is the whole template. Copy the columns, then fill a week of real jobs before you argue about software. If the week cannot be filled because addresses, ratings, or van counts live in someone's head, the sheet is already behind the work.

How travel, the window, and the van share one row

Dispatchers lose the promise when these three facts live in different places. Put them on the row in this order.

1. Write the customer window first, as earliest and latest arrival. For WO-4418 that is 10:00 to 14:00. The promised 10:30 to 12:30 has to sit inside it.
2. Write the previous stop and the travel block next. The promised start is inside the customer window, and the previous job's end plus the travel block is at or before that start. For WO-4418, the prior job must end by 9:55 for a 35-minute drive to make 10:30. If the previous job has no address, you do not have a travel block. You have a guess.
3. Write duration as on-site time only. The 2 hours end at 12:30. The drive is not part of that 2 hours, or the next customer inherits a late start.
4. Write the van and the part numbers last, before anyone is told the 10:30. A compressor that arrives at the shop at 11:00 cannot support a 10:30 promise, whatever the skill match looks like.

Microsoft's travel rules are the same chain, once you leave the sheet. Travel time is calculated only for on-site work inside working hours, and only when the resource or the previous booking has a valid location. The calculation is driving only. Standard travel time does not use live traffic or historical traffic, so a 35-minute block on a spreadsheet and a 35-minute block in Dynamics 365 Field Service can both be wrong on a bad afternoon. The difference is what the system does next. On the sheet, nothing moves. On the schedule board, dragging a booking does not recalculate travel unless Auto Update Booking Travel is on, and even then later start times do not cascade. Overlaps stay until a person fixes them or Resource Scheduling Optimization runs.

When Time and Material Invoicing is on, Odoo 19 records the part on the way out of the job, through the product catalog. The user's default warehouse, and a van is allowed, is the source for sales-order products on the intervention. Stock updates when the task is marked done. That is a clean record of what was used. It is a weak record of what was on the truck at 7:30, which is the fact WO-4418 needs. Until you have seen a booking stop because van 14 is short a compressor, keep the morning count on the row.

Skill sits beside those three, and it is a separate test. For this HVAC shop the row requires EPA certification at the office's commercial rating. A tech who can do the drive, the window, and the van stock, and who lacks the rating, is still the wrong assignment. Characteristics in Dynamics 365 store that skill on the resource and on the work order, with an optional rating. The spreadsheet version is a column you compare by eye. Either way the row is incomplete if the rating is blank.

The check to run before the first truck leaves

Run this in order. Stop at the first failure and fix the row. A schedule that survives the morning is a stack of rows that each passed.

1. One owner of the file. If two people can edit, name the copy that crews follow and archive the other before anyone is booked.
2. No overlapping hours for the same person, including helpers and the travel block in front of the job.
3. The promised start is inside the customer window, and the previous job's end plus the travel block is at or before that start. For WO-4418, the prior job must end by 9:55 for a 35-minute drive to make 10:30.
4. The named skill and rating on the row match the person in the assignment column.
5. The part numbers are counted in the van or warehouse written on the row, before the job is marked dispatched.
6. Agreement visits that fall on this date are rows, with the same skill and window tests as break-fix.
7. Multi-day work lists the specialist sequence on separate rows so Tuesday's electrician is on the board when Thursday's inspector is booked.
8. Emergency insertions name which lower-priority row moved, and the customer whose window changed gets a new promise the same hour.

Teams describe the failures in plain language: "Double-booked technicians", "Missed service appointments", and "Multiple versions of the same spreadsheet". Those three lines come from a field-service software thread about the point where sheets stop working. Treat them as the audit, every morning, while you are still on a file.

Where a spreadsheet schedule stops being safe

Do not wait for a headcount milestone. The trouble shows up once several technicians and dozens of jobs share one file, because of double booking, missed appointments, no live status, and more than one copy, as dispatchers describe in a field-service software thread. A 12-person shop with tight windows and van stock can be in that spot. A 30-person shop with loose anytime-Tuesday windows and one dispatcher can still be fine.

The break is a constraint the file does not enforce.

• Two bookings can occupy the same hours because the grid does not reject the second save.
• A certification can lapse, or a rating can be short, because the cell is text.
• A customer window can be missed because drive time is a guess typed after the start time was already promised.
• A part can be on the purchase order and still absent from the van, because the schedule and the truck count are different files.
• Status stays stale. The office learns about an overrun when the technician calls, and every later row is now wrong.
• People end up "spending more time updating spreadsheets than actually running the business", from that same field-service software thread. Another owner wrote that "my entire operations lived inside messy Excel spreadsheets" in a separate operations thread.

If your week already fails the morning check more than once or twice, the template has done its job: it showed you the constraints. The next decision is whether a person can keep enforcing them by hand.

What the file will never reject on its own

A careful dispatcher can catch an overlap by scanning columns. The file will still save the bad row. That gap is the reason companies outgrow the template, and it is also the reason a new board can disappoint if you assume every drag is a checked booking.

Skills are the clearest example. In Dynamics 365, characteristics are skills or certifications stored on resources and on work orders, with optional rating models. Enhanced characteristics can also store an ID, an issue date, and an expiration date, but Microsoft still marks that enhancement as preview and not for production use. On a spreadsheet, the equivalent is a text cell. Nothing expires it on the morning the card lapses. If you stay on the sheet, put the expiration in its own column and have Monday's check compare it to today's date. If you move, ask to see a booking blocked by an expired characteristic on a job like yours.

Travel sits in the same gap. A typed 35 minutes does not move when the previous job runs long. Customer windows then fail in a chain: one overrun, then three missed arrivals, then an evening of rebooking. Parts have a cousin of that gap. Knowing the compressor was ordered is a purchasing fact. Knowing it was loaded on van 14 before WO-4418 was promised is a dispatch fact. Keep those as separate columns until a system can show both on the booking.

Same-day priority is where crews feel it. An emergency insert is legitimate. The schedule fails when the insert does not name the planned row that moved and the window that was broken. Write the displaced job on the emergency row every time. That single habit tells you, after a month, whether emergencies are occasional or whether the board is fiction by noon.

How Dynamics 365 Field Service schedules the same row

Dynamics 365 splits the work across three tools, and the split is where buyers mis-budget. The schedule board is the dispatcher view of availability and bookings. It has hourly, daily, weekly, and monthly scales, and Gantt, list, and map views. The map is a single-day view. The weekly view always treats Sunday as the start of the week, which matters if your payroll week starts Monday and you compare the board to a spreadsheet that does too. Microsoft's board article shows a documentation date of 16 September 2026. The travel-time article is dated 10 September 2026. Read those pages against a trial tenant before you train dispatchers, because the board is the screen they will live in.

The schedule assistant is the matcher. It recommends resources from availability, skills, and location, and it estimates travel time. A person still makes the booking. The default search for resource availability is 100 entries, and it can be raised to a maximum of 1,000 in Booking Setup Metadata. Microsoft says the default can return incomplete results when there are many resources, and raising it can slow search. For a 22-technician company the default is usually plenty. The limit starts to matter when you search a long horizon across a large resource pool, including subcontractors. If a dispatcher books outside the assistant's recommended slots, constraints such as capacity, work hours, and time windows are not verified or enforced. That sentence, from the schedule assistant overview, is the one to put in the training note: a manual booking is a human decision, and the product will not rescue it.

Travel math has its own boundaries, documented on the travel-time page. Travel time is calculated only for on-site requirements inside working hours, and only when the resource or the previous booking has a valid location. Routes support driving only. Standard calculations do not use live traffic or historical traffic. Dragging a booking onto the board does not calculate travel time unless Auto Update Booking Travel is enabled. Even then, only travel time updates when later bookings are reordered. Booking start times do not cascade, so overlaps and working-hour conflicts remain unless you fix them by hand or pay for optimization. Resource Scheduling Optimization does use historical traffic, and it is a separate add-in.

That add-in is what schedules many jobs at once. It considers characteristics, territory, and promised time windows. Documented patterns include an overnight run, a single-resource reoptimization, a simulation, intraday runs as often as every 30 minutes, and an emergency insert ahead of lower-priority work. Those patterns are in the Resource Scheduling Optimization overview. Fully automated multi-job scheduling is this add-in or the Scheduling Operations Agent. The assistant alone will not rebuild Tuesday when the 9:55 residential job overruns.

What the US list price includes

As of October 2026, on the US pricing page:

• Dynamics 365 Field Service (List price: USD 105 · Basis: Per user per month, paid yearly. Informational. Checkout can differ.)
• Field Service Contractor (List price: USD 50 · Basis: Per user per month, paid yearly, for assigning and managing external frontline technicians.)
• Resource Scheduling Optimization (List price: USD 30 · Basis: Per resource per month, paid yearly. Pricing assumes a single tenant.)

The same products on the Canada pricing page, as of October 2026, list at CAD 142.50, CAD 67.80, and CAD 40.70 on those same bases, plus applicable tax. This article is aimed at US dispatch. Use the Canadian page only if a crew is employed and billed there.

Budget the yearly figure, or take a checkout quote, before you compare Field Service with a tool billed by the month. The Contractor price is for external frontline technicians. Which board actions that license includes is something to confirm on a quote, because a price line is a different fact from a feature matrix. A worked license mix for 30 technicians, including who needs a full user and who might sit on a lighter seat, is already laid out in our note on field service software pricing for 30 technicians. Use that for the arithmetic. One owner, shopping software after years in spreadsheets, described per-user pricing as a seat charge that did not fit a hands-on crew, in a separate operations thread. Count seats by role before you accept or reject that feeling: dispatchers and techs who book and complete work are different from a helper who only needs to see today's list.

For a single-location service team, the board plus the assistant covers the morning check if a dispatcher still confirms each booking. Pay for Resource Scheduling Optimization when you need the product to rebuild many jobs against windows, skills, and territory after the day moves, on a cadence up to every 30 minutes. Buying the board and expecting drag-and-drop to cascade start times will recreate the spreadsheet problem on a nicer screen.

How the apps, the schedule, and the agreements fit a service company is covered in Dynamics 365 Field Service pricing and fit. Read that next to the column template so the license conversation stays tied to rows you already know you need.

How Odoo Field Service schedules the same row

Odoo is the other system we implement for companies this size, and its schedule is a different bargain. The Field Service app page says the app can be started free with unlimited users. The US pricing page says the first app is free forever with unlimited users on Odoo Online, including hosting and support, as long as you do not add another paid app. The moment you need a second app, you are on a paid plan for the users who require it.

As of October 2026, with the yearly toggle on that US page, Standard shows USD 24.90 per user per month and Custom shows USD 49.00 per user per month. The page states the discount is valid for 12 months for the initial users ordered. Both paid plans include all apps. The cards also print nearby dollar figures. Those extra figures are not labeled as a billing term on the page, so budget the labeled yearly amounts and confirm the rest at checkout. A light user is shown at USD 8.90, and Field Services is listed among light-user capabilities. Light users are sold through an advisor quote. Custom adds Odoo.sh or on-premise, Studio, multi-company, and the external API, and Odoo.sh hosting is extra.

Planning, per Odoo 19, uses Kanban, a Gantt with drag-and-drop dates, assignees, and dependencies, a calendar by day, week, or hour, and a map. The itinerary documentation says the map is a static pin map of tasks that have a valid customer address, sorted by Planned Date. It is an ordered list of pins. An itinerary requires the Mapbox integration. Opening Google Maps uses the worker's current location as the start. If your dispatch question is the cheapest driving order for eight stops, have Mapbox shown on your own addresses. The default map will not answer it.

Tasks can be created manually, from a confirmed sales order that uses a service product, or from a Helpdesk ticket, per the creating-tasks page. That page does not document skill matching, promise windows, or double-booking prevention. Keep the skill, window, and overlap columns in your process, and have someone show you those checks on a copy of WO-4418 before you retire the morning audit.

Parts are recorded, and they are recorded late relative to dispatch. With Time and Material Invoicing on, products go on the task through the product catalog. A user's default warehouse, including a van, is the source for sales-order products on the intervention. Stock in that warehouse updates when the task is marked done, which the product management page describes. Have the van count demonstrated before the job is scheduled if your failure mode is a truck that arrives without the compressor. Until you have seen that check, keep a column for whether van 14 was counted this morning.

Odoo is the practical first system when you want every tech on a shared board, your constraints are mostly dates and assignees, and you can keep skill and window discipline in the morning check. Dynamics 365 is the practical first system when the booking itself must consider characteristics, territory, and promised windows, and when you are willing to pay the Field Service user price plus, if the day will not sit still, USD 30 per optimized resource per month.

When the spreadsheet is still the right schedule

Keep the file when all of the following are true for a normal week.

• One dispatcher owns one file, and technicians see that file or a same-day export from it.
• Overlaps are rare enough that the morning scan catches them before the trucks leave.
• Most windows are half a day or wider, so a rough travel block does not break the promise.
• Skills are stable and few. A laminated list of who can do commercial refrigerant work matches the work.
• Vans are restocked on a routine, and missing parts are uncommon enough to handle with a phone call.
• Emergencies are a handful a week, and each one names the job it displaced.

Move when the opposite shows up as a pattern: more than one editor, tight windows, rated certifications, van-level parts, and same-day inserts that reshuffle a full board. Headcount is a clue only because more technicians usually mean more of those constraints at once. Last week's rows tell you more than a headcount.

The office side of the same decision is the customer record, the agreement, and the invoice that follows the visit. If dispatch is changing systems, the service history the coordinator sees should change with it. A CRM implementation is the office half: the ticket or agreement that becomes the row, and the status the customer is given when the row moves. Service-company software is the wider frame when scheduling is one workflow among quoting, agreements, and billing.

Bring the template to that conversation. A useful first phase is the morning check made automatic for the constraints that hurt you: no overlapping hours, a skill the work order requires, a window the travel block can reach, and a part location you trust before the promise goes out. Agreements, IoT alerts, and multi-day specialist sequences can follow once Tuesday's board matches the rows. If you want that scoped against your own week, start with field service implementation and send the grid ahead of the call.

How Flectic can help

Flectic implements Field Service on Dynamics 365, puts your biggest dispatch bottleneck live first and stays through launch stabilization. Flectic sends a written proposal with a fixed price for each phase before work starts. For the platform scope, see Microsoft Dynamics 365 implementation. Book a free discovery call with Flectic to decide which dispatch bottleneck goes live first.

Sources

• Dynamics 365 Field Service pricing (United States), Microsoft, October 2026
• Dynamics 365 Field Service pricing (Canada), Microsoft, October 2026
• Use the schedule board in Field Service, Microsoft, October 2026
• Schedule assistant overview, Microsoft, October 2026
• Schedule requirements with travel time and distance, Microsoft, September 2026
• Specify characteristics for resources, Microsoft, October 2026
• Overview of Resource Scheduling Optimization, Microsoft, October 2026
• Overview of Dynamics 365 Field Service, Microsoft, October 2026
• Odoo Pricing, Odoo, October 2026
• Field service management software, Odoo, October 2026
• Planning an itinerary, Odoo 19.0, Odoo, October 2026
• Product management, Odoo 19.0, Odoo, October 2026
• Creating tasks, Odoo 19.0, Odoo, October 2026
• The Comprehensive Guide to Field Service Scheduling, BuildOps, August 2025
• At what point did spreadsheets stop working, Reddit, 2026
• Years running operations in Excel, Reddit, 2026