An automated work order system is really three systems stacked together — raising the order, deciding who gets it, and telling that person. The first and third are safe to automate today. The middle one is where the money is, and where the vendor demos are least honest.
Key takeaways
Search for an automated work order system and you get a page of products that all claim the same thing. It is easier to evaluate them if you break the work order's life into the three steps it actually has, because the software is good at two of them and only partly good at the third.
Step one is creation: a request arrives and becomes a structured record with an address, a customer, a problem description, a priority and a required skill. Step two is assignment: someone or something decides which technician, which van, which day, which slot. Step three is notification and closeout: the technician gets the job on a phone, arrives, records what was done, and the office bills it.
A work order in Microsoft's Dynamics 365 Field Service documentation is a record built from a service account, an address, a work order type, a price list and one or more incident types that carry the tasks, products and services the job needs. Once that structure exists, creating one from an email, a form or a phone call is a mapping exercise rather than a judgement call. Any decent field service package does it.
The AI layer here mostly saves reading. Microsoft's Copilot features in Field Service include on-demand work order summaries that pull status, priority, related activities and recommended next actions into a short block, and natural-language questions against the data already in the system. The work order summary documentation is careful about a detail worth knowing: the summary is not saved, and it is only available to the user who generated it. It is a reading aid, not a record.
This is where the claim "fully automated dispatch" gets made and where the documentation quietly disagrees. Microsoft's schedule assistant recommends resources that match availability, skills and location, estimates travel time for each, and ranks them — and then the dispatcher books. Microsoft describes it plainly as best suited to semi-automated scheduling where a dispatcher reviews suggestions and makes the final decision.
The same page carries two constraints that matter operationally. The default limit for searching resource availability is 100 entries and can be raised to a maximum of 1,000, which means a large crew list can silently return incomplete results. And if you book outside the recommended slots, constraints such as capacity, work hours and time windows are not verified or enforced — the override is available, and it is genuinely an override.
Fully automatic assignment does exist. Resource Scheduling Optimization schedules multiple jobs at once rather than one at a time, matching job requirements to resource attributes and minimising travel. Microsoft is explicit that it is a paid add-in and that its price is based on the number of resources whose schedules are optimised. That pricing model is the useful signal: it is built for fleets large enough that manual dispatch has become the bottleneck, not for a crew of five.
Optimisers minimise driving. Ontario's employment standards decide when driving is paid, and the two do not line up automatically. The province's guidance on hours of work under the Employment Standards Act draws the line clearly: commuting between home and work is not work time, but if an employee takes a work vehicle home in the evening for the employer's convenience, work time begins when they leave home and ends when they get back. If they are required to transport other staff or supplies to a site, that time counts as work time. And if they have a usual workplace but are sent to another location, the travel counts.
Ontario also caps most employees at eight hours a day, or the established regular workday if longer, and 48 hours a week, with those maximums exceedable only by an electronic or written agreement — and such an agreement does not remove the obligation to pay overtime. So a route that packs an eleventh call into a technician's day is not automatically a win. Feed real working-hour limits into the scheduler as constraints, or you have optimised your way into a payroll liability.
The newer wave of tooling lets an agent open the work order or task itself. Procore's Agent Builder ships an Action Item Generator that creates a task in the project from a plain text command, assigns it and sets a due date. Procore's own documentation on agent actions sets two boundaries that are worth adopting as your own policy even on other platforms: an agent asks for confirmation before creating or sending anything, and Procore agents can create new items and notify users about existing items but cannot modify or delete existing ones.
That second boundary is the safer design. An agent that can only add leaves an auditable trail; an agent that can silently edit or delete a dispatched work order removes the evidence of what was scheduled and when.
Take a six-van HVAC contractor in Mississauga running roughly 30 calls a day, with one dispatcher who is also the service manager. The realistic sequence is not "buy AI dispatch".
First, make creation structured: every call, form and email becomes a work order with a required skill, a duration estimate and a priority, entered once. Most of the dispatcher's day is currently re-keying and chasing missing addresses, and that disappears immediately.
Second, turn on ranked suggestions rather than automatic booking. The dispatcher keeps the final click but stops mentally solving a travel-time puzzle across six vans. This is the step that actually gives time back.
Third, encode the constraints that are specific to you: the two technicians certified for the commercial rooftop units, the apprentice who cannot attend alone, the daily hours agreement you have on file, the fact that a van going home with the truck starts paid time at the driveway. Only after those are in the system is automatic optimisation safe to consider — and at 30 calls a day across six resources, a per-resource paid add-in may not clear its own cost.
What to automate, in order
Automate now: creating the work order from an intake, notifying the assigned technician, sending the customer an arrival window, pushing completion notes back into the office system.
Automate with a person on the button: choosing who goes. Let the system rank and estimate travel; let the dispatcher book.
Automate last, if at all: unattended assignment across the whole day. It requires your skills matrix, working-hours rules and customer commitments to be complete and correct in the system first.
The role does not disappear; it moves. Someone still decides what happens when a job overruns, a part is missing or a customer is not home. What automation removes is the clerical half of the job — the re-keying, the phone calls to confirm, the whiteboard.
Scheduling a subcontractor is a contractual instruction, not an internal assignment, and how tightly you can direct their hours is one of the facts that distinguishes a contractor from an employee. Where the arrangement is genuinely a subcontract, treat the dispatch as an offer of work rather than a booking, and read the terms first.
Ask them to show, in their own written documentation, whether assignment is automatic or recommended; what happens when you book outside a recommendation; how many resources the availability search returns by default; and whether their AI features can modify or delete existing records. Every one of those answers exists in writing for the products above.
A 30-minute call is enough to tell you whether AI pays for itself here.
