The Field Service
AI Playbook

The honest state of AI in field service

Before we talk about AI, we have to agree on what a good day looks like.

A technician's best day looks like this.  Leave the house.  Drive to the site.  Turn wrenches all day with a hard hat on.  Go home.  No meetings.  No emails.  Nobody from the office calling to ask if they're free next week Tuesday.  Show up.  Do the work.  Go home.  That's the happy path, and every technician I've ever managed would sign it in ink.

Now notice who interrupts that day.  Dispatch.  Billing.  IT.  Administration with a new policy.  The happy path of the front office runs directly thru the technician's worst day.  And here's the thing: every piece of a field service deployment that isn't focused on wrench time and the moment in front of the customer is where the friction comes from.  That's true of your FSM system, and it's doubly true of every AI feature you bolt onto it.

Field service companies run a culture of safety.  They open meetings with safety talks, back their trucks into parking spots, and cone their own lot.  Then a software team shows up speaking LLMs and structured data governance, and the two sides stare at each other like foreigners.  Most AI projects don't fail on the technology.  They fail in that gap.

The industry numbers back the skepticism.  IBM's research across 1,200+ enterprise deployments found that only 33% of AI initiatives meet their ROI targets, and 72% have failed to scale beyond one business unit.  Aquant's 2026 benchmark says the gap between top and bottom performers is enormous: an 88% first‑time fix rate at the top against 60% at the bottom.  AI didn't create that gap.  Operating discipline did.  AI just widens it, in whichever direction you're already headed.

So this book has one yardstick, and we'll use it in every chapter: does this AI workload make the technician's job easier and the wrench time better?  If yes, it earns its seat.  If it just gives the office another dashboard, it's friction with a subscription fee.

The AI workload map

Every AI pitch you'll hear this year is selling one of three different machines.  They all wear the same badge.

• Batch AI.  A scheduling optimizer (Microsoft's is Resource Scheduling Optimization, RSO) that evaluates the whole board at once: work orders, technicians, skills, territories, travel, SLAs, parts.  It runs on a schedule, not in real time, by design.  It's a chess engine, not a copilot.
• Real‑time suggestions.  Decision support in the moment: a schedule assistant proposing the best technician, a suggested priority on an alert.  Fast, narrow, per‑decision.
• Generative AI.  Copilots and agents that read context and produce language: summaries, reports, knowledge answers.  Brilliant with clean context.  Confidently wrong without it.

Three machines, three failure modes, three data appetites.  When a seller says "our AI optimizes your field service," your first question is: which of the three is this?  If they can't answer cleanly, that is your answer.

The six layers you can actually buy

Inside a platform like Dynamics 365 Field Service, the AI catalogue breaks into six workloads.  And this map is not a Microsoft thing: Salesforce, IBM, Oracle, ServiceTitan, everyone sells a parallel stack.

Data readiness

Your work order history matters more than the model.  Nobody wants to hear it.  It decides everything.

A mining equipment manufacturer rolled out field service across nine languages.  Real crews mixed a specialist from headquarters, a regional engineer, and local technicians around one machine.  The gap got bridged the only way it ever does on a job site: everybody around the same official manufacturer documentation.  Except the manuals weren't translated into all nine languages.  And the job site was a mine, no internet, and nothing cloud‑hosted was going to save anyone down there.

The fix wasn't a bigger model.  The system was rebuilt to track two things it had never tracked: the technician's language, and the languages needed at each location.  Manuals went portable and on‑device, offline, in every language a site might need.  AI earned its seat there doing the least glamorous job imaginable, translating technical manuals, and it was the highest‑value AI line item in the deployment.

Every generative feature in chapter 02 reads your work order history as its source of truth.  If your closed work orders say "fixed" in the resolution field and nothing else, that's what your AI knows about your business: nothing, confidently.

Data readiness isn't a two‑year data warehouse project, either.  That's the other failure mode: getting so lost in "fixing the data" that no workload ever ships.  Scheduling optimization needs clean skills, territories, and durations.  Copilot needs honest resolution notes.  Predictive maintenance needs asset history.  Score the data the workload touches.  Ignore the rest until its turn.

Copilot | where it earns its seat

Copilot in field service has been a great conference room pilot demo.  The job site is not a conference room.

Let me be fair first, because Microsoft keeps iterating on this and the investment is real.  Within its own context, Copilot does pretty good.  Work order summaries save dispatchers real minutes, and they're generally available today on web and mobile.  Summarizing a long, messy service history before a customer call is genuinely useful.  Updating work order fields by voice instead of thumbs is in preview on mobile now, and that's the kind of paperwork nobody will miss.  And per Salesforce's research, more than 75% of mobile workers say AI saves them time on the job.  The wins are real.  They're just smaller and more specific than the keynote.

Know the history here, because it's the best vendor honesty you'll find anywhere in this book.  Microsoft shipped a wave of AI previews into Field Service around 2020: predictive work duration, incident type suggestions, IoT alert suggestions.  In late 2024 it retired all three.  That's not a scandal.  That's what shipping AI actually looks like: some of it survives contact with the field, some doesn't, and a vendor that prunes is healthier than one that doesn't.  But it's also why you buy what's generally available and in the deprecation log's clear, not what's in the keynote.

Here's the structural problem.  Today's assistant is a standalone feature talking to one application.  A technician's actual questions cut across systems the assistant can't see: What's next on my schedule after this?  Do I have all the parts to finish this job?  What's the first and most important thing on this work order?  Those answers live in email, inventory, scheduling, and the work order at once.  The gap isn't the model.  The gap is the context it's allowed to see.

And then there's the part nobody demos.  A technician wearing a hard hat who needs to hear an assistant needs a headset.  On a lot of job sites, a headset under a helmet is a safety hazard.  Gloves don't type.  Machine rooms are loud.  If your AI strategy assumes a quiet room and free hands, it was designed in one.

So the buying rule for assistants: pick tasks where the context is already inside the system, the output is reviewed by a human, and the minutes saved are countable.  Recaps, report drafts, knowledge answers, translations.  Skip anything that needs the assistant to know the technician's whole day.  It doesn't, yet.

Scheduling and RSO intelligence

The hardest, most valuable problem in field service.  And the place where one week can wreck a perfect plan.

My worst week running a service department started with a technician destroying a customer's laptop, hard drive included.  Data recovery, an angry customer, a new inspection protocol.  Midweek, a hi‑lo driver in the warehouse backed into a pallet of thirty computers.  About $100,000 of hardware.  Every unit had to be unboxed, powered on, and tested so we knew what to claim.  One in five was dead.  That ate a week of planned capacity, and the schedule didn't recover for three.

Nothing about that week was preventable, and that's the point.  A schedule optimized to 100% utilization has zero capacity for the week that goes sideways thru no fault of your own.  The save wasn't an algorithm.  It was having enough slack for management to throw extra bodies at the fire.  When you configure a scheduling engine, that slack is a design decision.  TSIA makes the same warning from the other direction: in the AI era, raw utilization becomes a misleading metric.  Optimize outcomes, not busy‑ness.

Jobs to be scheduled vs. jobs to be done

Here's the framework I want you to steal.  Scheduling engines are excellent at jobs to be scheduled: getting the right person to the right place with the least windshield time.  They're nearly silent on jobs to be done: what happens in the hours on site.  The work breakdown structure.  The assets and tasks.  The procedures.  The information the technician needs standing in front of the machine.  Most FSM products treat getting a person to the site as the job.  It isn't.  The job is the job.  If your deployment optimizes time‑on‑task and ignores the task, you've built a very efficient way to arrive unprepared.

Which scheduling brain do you buy?

• Batch optimization (RSO) when you're 50+ technicians with real constraint complexity: territories, skills, SLA windows, parts.  This is where the 20 to 40% drive‑time reductions live.
• Schedule assistant when a dispatcher makes good calls and needs faster ones, one booking at a time.
• Manual when the dispatcher knows every tech and every customer by name.  A small shop's dispatcher IS the optimizer, and a good one is hard to beat.

One more for the watch list: Microsoft's Scheduling Operations Agent, an agentic layer over scheduling that's still in preview as I write this.  Watch it.  Pilot it if you're curious.  Don't bet a go‑live on a preview.  Chapter 04 explains why that rule exists.

Your best dispatchers override the system every shift, and they're usually right, because they're correcting for constraints nobody encoded: the customer who needs the same tech every visit, the site with the gate code drama, the trainee who shouldn't solo that machine yet.  Don't automate your dispatchers out.  Build them a faster cockpit, and treat every override as a requirement you haven't captured.

IoT to work order | the pattern that holds

Detect before dispatch is real.  So is the alert that can't tell a fire from a dropped ping.

The pattern at its best is almost boring.  An ATM servicing company put IoT devices inside the machines.  When cash runs low or a component drifts, the machine raises its hand and a work order exists before any customer notices anything.  Detect, diagnose, dispatch, resolve.  The service model flips from reactive to scheduled.  That's connected field service earning its keep.

Now the other story.  A clean‑energy company runs self‑serve propane and natural gas filling stations.  No clerk on site.  Sensors watch for leaks, and when a hazard signal fires, a technician has to be on site within a hard time window.  More than once, a power outage knocked out an area's connectivity, and the board flooded with one identical error: cannot reach the site.  That one signature means one of two things.  The station is on fire.  Or the router lost power for twenty minutes while customers pump gas, annoyed at nothing.  From the dispatch chair, you cannot tell which.  That ambiguity is the detect‑before‑dispatch trap, and it will drown your dispatchers exactly when the stakes are highest.

The fix: solar‑and‑battery cameras with LTE connections on a different carrier, deliberately not integrated with anything.  No telemetry, no workflow, no dashboard.  Just out‑of‑band eyes a human checks before dispatching.  Telecom people call this physical diversity, and mission‑critical monitoring deserves it.  Engineer for ambiguity before you automate the response to it.

Predictive maintenance without the hype

A predictive model with an empty asset record is a fortune teller with amnesia.

Predictive maintenance is the most oversold phrase in field service.  The pitch writes itself: stop fixing things on a calendar, let the data tell you when the machine is about to fail.  And the ceiling is real.  The World Economic Forum documents a chemical manufacturer cutting downtime by more than half with predictive analytics.  But that's a lighthouse case, not a median.  The median is closer to Geotab's 2025 survey: 88% of leaders got asset‑uptime gains of 6 to 15% from new field service technology.  Meaningful.  Not magic.

Here's the dependency chain the pitch skips.  Prediction needs two feeds: a signal from the asset (telemetry, inspections, usage) and a history of what's been done to it (work orders, parts, failures).  Most organizations have neither wired up.  The asset record exists, technically.  It's a name and a serial number, no install date, no service history, work orders attached to the customer instead of the machine.  Feed that to a model and you get confident scheduling of the wrong maintenance on the wrong assets.

McKinsey's list of why predictive maintenance programs fail should be printed on the box: insufficient or inaccessible data, inadequate sensors and infrastructure, poor prioritization of which assets deserve the effort, missing data science capability, weak change management, and, for plenty of assets, economics that were never going to work.  Read that list again.  Five of the six failure modes are yours, not the vendor's.

The realistic on‑ramp isn't "deploy ML."  It's a ladder.  Rung one: usage‑based maintenance instead of calendar‑based (hours run, cycles, miles).  Rung two: condition thresholds from the sensors you already have.  Rung three: anomaly detection and real predictive windows, for the short list of assets that earned it.  Each rung pays for the next, and each one needs the same thing: an asset record with real history.  That's why this chapter's homework is chapter 03's homework wearing a hard hat.

AI governance | value or noise

Organizations that skip governance don't get AI‑generated value.  They get AI‑generated noise.

A propane distributor (delivery, tank inspections, installations) bought the best scheduling AI money could configure.  The project team fell in love with it.  Nine scheduling rule sets across the lines of business, tuned and beautiful.  On paper, it beat the human dispatchers' schedule every single day.  I mean that literally: we could line the two schedules up each morning and win on the math.  The dispatchers didn't trust it.  They wouldn't run it at scale.  Their world was spreadsheets, nobody had brought them along, and the tooling made proving the machine's schedule against theirs almost impossible to see.  Nine months in, the project fell apart.  The math never mattered.

That project taught me that trust is not a soft topic.  It's an engineering deliverable with a spec, and the spec is three questions.  Answer them in writing before any AI workload goes live.

The three questions

• 1 · Alert governance.  How do machine‑raised alerts get triaged?  Who has the authority to dismiss one, and what happens when they're wrong?  What suppression rules keep a connectivity blip from flooding the board (chapter 06)?  If nobody owns dismissal, everything becomes a truck roll.
• 2 · Override rules.  When can a dispatcher overrule the optimizer, and how is that logged?  Not to punish the dispatcher.  The override log is your requirements backlog: every consistent override is a constraint the system doesn't know yet (chapter 05).
• 3 · Trust calibration.  Which AI outputs go straight to customers, and which require human review first?  A work order recap for internal use and a customer‑facing message are different risk classes.  Decide the boundary on purpose, per output type, before the first hallucinated SLA promise decides it for you.

Notice none of the three questions are about model quality.  The propane project failed the second question's spirit: the humans who owned the schedule were never made partners in the machine that wanted it.  Governance is how you make them partners, in writing, before go‑live.  And it's cheap: three questions, one page, a signature from operations.  Compare that to nine months.

The ROI math and the first 90 days

Domino's figured out field service economics before most field service companies did.

The delivery cost of a pizza is buried inside its price.  Call it a couple of dollars of driving baked into a $15 order.  Domino's rarely gets to deliver two pizzas on one run, and it bothers them enough to experiment with trucks full of hot pizzas waiting for orders.  Because a second order on a drive that's already paid for is nearly pure profit.

Your work orders are pizzas.  Every quoted job carries its truck roll inside the price.  So when the optimizer cuts drive time, that's good.  But the under‑appreciated win is density: finding the low‑priority work order ten miles from your technician instead of sending them sixty miles to the next scheduled stop.  The customer already paid for that drive when the job was quoted.  The technician drives for free.  That marginal, drive‑free work order may be the most profitable work your company can do, and "jobs per day went from four to five" doesn't begin to describe it.  A 10% cut in windshield time is a solid target, and in heavy‑truck country it's not just money.  Service miles carry accident risk your P&L never itemizes, driven by people at hour thirteen of their day whom no DOT rule covers.  Fewer miles is a safety program wearing a cost‑savings badge.

The external numbers, honestly labeled

Every number below comes from a vendor with skin in the game, so treat them as directional until your own telemetry replicates them.  They're still the best public map of where the money is.

Failed visits are the clearest lever on that list.  A failed visit is a full truck roll that produced a second truck roll: wrong part, wrong skills, wrong information, no site access.  Every one of the six AI layers from chapter 02 attacks it from a different angle, which is why the benchmark‑led loop below beats any "transformation program."  Improve first dispatch accuracy, raise remote resolution, capture what your best technicians know.  Repeat.

The first 90 days

• Days 1 to 30 | Baseline.  Measure the eight KPIs (chapter 10's scorecard) with consistent formulas.  Pick your North Star and put it on a wall.  And start socializing the hardest workload now, with the people who'll live in it.  Not month seven.  Day one.
• Days 31 to 60 | One workload.  Pick the single layer your baseline says is bleeding the most (usually failed visits or windshield time).  Pilot it on one territory with the schedule‑vs‑schedule test running in the open, where dispatchers can see it win and see it lose.
• Days 61 to 90 | Governance and the scale call.  Write the three‑question one‑pager.  Compare pilot numbers to baseline.  Scale, fix, or kill, and say which out loud.  A killed pilot with a clean number is a win.  A zombie pilot is how you become IBM's 72%.

The buyer's checklist

The mortgage you pay is the moat.  Understand what it buys before you decide to build.

Somebody on your team, or a partner who wants your business, is about to propose replacing your FSM scheduling with an LLM and some tables.  Look at a real scheduling schema for five minutes.  Skills, certifications, territories, SLA windows, parts, crew composition, customer preferences, travel, time zones, unions, safety rules.  It is not two tables and a query away, and most of the people pitching that have never dispatched anything.

That's what the moat is.  It's a gilded cage, I'll grant that.  But it locks both directions: your service history, customer data, and pricing live inside a governed boundary, auditable and access‑controlled.  You're not training a frontier lab on how to run your service business.  Multi‑language deployment, mobile device management, auditing, a roadmap with committed engineering behind it.  Build custom agents on top of that platform (layer six), absolutely.  Replace the platform because a demo made it look easy?  That's how you volunteer to be somebody's cautionary tale.  SaaS has survived every hype cycle for one reason: it's the fastest path to value that also survives year three.

The scorecard | baseline these eight before any AI purchase

• First‑time fix rate (industry benchmark 77% | top performers 88%)
• Resolution time, case open to resolved (median 4.5 days | top performers 2.5)
• Failed‑visit cost share (median 25% of service cost | top performers 14%)
• Remote resolution rate, and its twin, avoidable dispatch rate
• Technician productive time, with one written formula everyone uses
• Travel time per completed work order
• SLA attainment, by line of business
• CSAT or NPS, measured at all (barely half of orgs do)

The seven questions that separate shipping from roadmap

• Which of the three kinds is this: batch, real‑time, or generative?  Which of the six layers?
• Is this feature generally available today, in my region, at my license tier?  Show me, not the roadmap.
• What data does it read, and what does it do when that data is wrong?
• Where's the human override, and where's the log of it?
• What evidence ships with each suggestion?  (Remember the 66‑of‑80 screen.  That's the bar.)
• What does it cost at my volume, all‑in, next year?  Consumption pricing reads small until it isn't.
• Can I turn it off without breaking anything?  Reversibility is the cheapest governance there is.

And the last rule, the one this whole book has been building: run a benchmark‑led improvement loop, not an AI transformation.  Baseline, pick the bleeding KPI, deploy one workload against it, govern it, measure it, then go again.  That's the whole playbook.  It's not flashy.  It works.