Field service economics come down to one ratio: how often a technician resolves the job on the first visit. Every return trip is a day of capacity spent twice, a customer told to wait again, and a margin that quietly disappears. Fixing it requires knowing the asset's history, the technician's skills and the parts position before the visit is scheduled — not after.
Field Service is a market-leading field service management application covering work orders, scheduling, assets and mobile working. These are the four problems it exists to solve.
Who is where, with what skills and which parts, and what happens when somebody calls in sick at six in the morning. It works until that person takes leave.
The skill, the part or the site history is missing, so the visit becomes a diagnostic trip and the actual repair is scheduled for another day.
Job sheets, time records, photographs and signatures captured on paper, some proportion of which never reaches the office — and what is missing is exactly what would have settled the dispute.
Nobody can see what was done at this site last time or which parts were fitted, so recurring faults are re-diagnosed from scratch on every visit.
Where the return actually comes from: Three sources dominate, in this order. Utilisation: an additional completed job per technician per week compounds enormously across a year, and better scheduling is the most reliable route to it. First-time fix: every avoided return visit is a day of capacity recovered and a customer not disappointed twice. And contract revenue: preventive maintenance agreements renewed because the system prompts it, rather than lapsing because nobody noticed — usually the highest-margin revenue in a service business and the easiest to lose by inattention.
The capability that changes both the dispatcher's day and the technician's.
Scheduling by skill, certification, location, travel time, parts availability and contract priority — with optimisation that can reshuffle a day when an emergency job arrives.
The full lifecycle from request through scheduling, execution, parts consumption and invoicing, with the commercial detail carried rather than re-entered.
A technician app that works fully without connectivity — basements, plant rooms, rural sites — and syncs when signal returns. Not a nice-to-have; the design premise.
Every serviced asset registered with its full history, warranty position and configuration, so the next technician arrives informed rather than curious.
Agreements that generate work orders automatically on schedule, with entitlement checking and renewal prompts before they lapse.
Microsoft's current wave adds a scheduling agent for intelligent assignment and dispatcher productivity, alongside continued investment in mobile reliability and offline behaviour.
Two threads matter for planning. First, scheduling is becoming genuinely agentic — assignment and reshuffling handled automatically rather than by a dispatcher with a whiteboard. Second, Microsoft is tightening the connection between Field Service, Finance, Supply Chain and Project Operations, which is what finally closes the loop between work performed in the field and margin recognised in the ledger.
We baseline from your last twelve months of jobs, travel and first-time-fix data.
Additional productive hours from better scheduling
Improvement when skills, parts and history inform the schedule
Reduction through route and territory optimisation
Captured digitally, including with no connectivity
Faster billing from completed work orders
Rather than remembered, or missed
How to read these: How to read these: the figures above are typical ranges we plan and measure against, not guarantees. In your first engagement we agree the baseline, the target and the measurement method in writing, then report against them.
Microsoft's documentation frames the application's value in the following terms.
Where this comes from: Where this comes from: these themes follow Microsoft's Dynamics 365 Field Service documentation and 2026 release wave 1 plan on learn.microsoft.com, including the Scheduling Operations Agent, mobile and offline investment, and integration with Finance, Supply Chain Management and Project Operations. The numeric ranges above are ours and are planning figures rather than Microsoft benchmarks.
The scheduling problem differs enormously depending on what is being serviced.
Preventive maintenance contracts alongside emergency call-outs, with equipment history at each site and contract entitlement checked before dispatch.
Aftermarket service on installed equipment, warranty administration, and parts logistics for machines the customer cannot afford to have stopped.
Home health visit scheduling with travel optimisation, mobile documentation in the patient's home, and medical device servicing with inspection records.
Asset-based maintenance across a distributed estate, planned and reactive work, and regulatory inspection evidence.
Multi-site work orders with service level agreements per property, and reporting to owners who want evidence rather than assurance.
Mixed project and service work, crew scheduling across many small jobs, and van stock management.
The mobile experience comes first. If technicians reject it, nothing above it works.
The technician's experience, designed for gloves, sunlight and no signal.
The resource engine, and the institutional knowledge currently held by one dispatcher.
The commercial layer that turns service delivery into a business.
Implementation, customization, support and integration — measured against utilisation and first-time fix, not against configuration completeness.
Environment design, tenant and licensing setup, configuration, data migration, testing and go-live — scoped to a fixed price and a fixed date, against outcomes agreed in writing before we start. For Field Service that means the mobile app goes live with one crew and proves itself before anything else rolls out. Field adoption decides whether the whole programme works.
Where the product stops short of your process, we extend it inside the platform rather than beside it, and we build it as configuration you can maintain wherever that is possible. Work order types, job checklists, scheduling rules and contract templates configured as data your operations team maintains, job type by job type.
Managed support after go-live: a named team, agreed response times, release management for Microsoft's update cadence, and a backlog we work through with you. Field-hours coverage. Crews start before the office does, and a mobile app failing at six in the morning costs a day of billable work.
Connecting this platform to the systems you are keeping, with monitored, re-runnable interfaces and a documented contract for every field that moves. Connections to finance, inventory, telematics, customer systems and supplier ordering, so a part consumed in the field is a part reordered and a line on an invoice.
Offline capability is not a feature we check for; it is the design premise. A field application that requires connectivity will be abandoned in favour of paper within a fortnight, and every reporting benefit above it disappears with it.
We start in a van, not in a workshop. Field software designed from an office is the most reliable way to produce something technicians refuse to use.
We spend days with technicians and the dispatcher, watching what is captured and what is lost.
We model skills, territories, contract entitlements and the scheduling constraints that actually bind.
We put the mobile app with one crew — including your most sceptical technician — and fix what they find.
We roll out crew by crew, with dispatch trained before each wave.
Device policy and access secured, then utilisation and first-time fix tracked against baseline.
The technician least interested in this should be in your pilot group rather than protected from it. If the app works for them it works for everyone, and if it does not, week three is a much better time to discover that than after a full rollout.
Field software fails for one dominant reason: it was designed for the office and handed to the site.
Cracked screens, gloves, sunlight, no signal and someone who wants to get to the next job. If capturing a job takes more than a couple of minutes it will not happen properly.
Scheduling constraints that exist only in one person's head are the real system. Modelling them is most of the work and most of the value.
Work performed, parts consumed, time recorded and margin recognised should be one chain. Most implementations stop at the work order and leave the commercial half undone.
Devices, connectivity, the application and the support desk from one accountable team — which matters when a crew cannot log in at six in the morning.
Two illustrative engagements showing the shape of the work.
One dispatcher held the entire schedule on a whiteboard and in her memory. Utilisation was unknown, emergency work displaced planned maintenance unpredictably, and her leave was genuinely stressful for the business.
The manufacturer knew what it had shipped and very little about what those machines were doing now. Service was reactive, contracts were sold inconsistently and renewals lapsed unnoticed.
Practical pieces on utilisation, first-time fix and mobile adoption.
Why connectivity assumptions kill field software adoption within a fortnight.
Read moreCapturing institutional scheduling knowledge before it retires, and the constraints that actually bind.
Read moreThe arithmetic behind return visits, and the three inputs that move the rate.
Read morePick a job type and give us your skills matrix and a real work order. We will configure a demo of scheduling and mobile capture for that job — including the offline behaviour — and put it in the hands of one of your technicians.
Describe the situation in your own words.
