Sixteen capabilities. One work order underneath all of them.

What field service management software actually is

Field service management software is the system that runs work performed away from your own premises: raising the job, deciding who attends, giving the technician what they need on site, capturing what happened, and turning that into an invoice and a record.

That definition is broader than it sounds, and it is where most confusion starts. A scheduling tool is not field service management. Nor is a mobile forms app, a job-tracking spreadsheet, or the service module bolted onto an ERP. Each covers part of the cycle. What makes a system a field service management platform is that one work order carries the customer, the site, the asset, the contract, the technician's qualifications, the parts, the evidence and the invoice as a single thread.

The practical test is what happens when a technician arrives and the job is not what the ticket said. In a genuine platform, they see the asset's history, raise a variation, pull the part from van stock, capture the evidence and close it, and the invoice reflects what was actually done. In a collection of tools, that sequence spans four systems and a phone call.

The categories it gets confused with

Buyers frequently evaluate field service management software against products that solve an adjacent problem. All four of these overlap with it; none replace it.

• CMMS: computerised maintenance management. Built for maintaining assets you own, usually on your own site. Excellent asset registers and PM scheduling, weak on the things field work needs: travel, customer appointments, contracts, billing. If your technicians rarely leave the plant, a CMMS may genuinely be the right answer.
• The service module in an ERP. Strong on finance, purchasing and inventory because that is what the ERP already does. Typically weak on the technician's day: mobile use, offline work, scheduling under real constraints. Often the right system of record and the wrong system of work.
• CRM with a service add-on. Good at the customer relationship and the sales pipeline. The field execution layer is usually thin, and asset history in particular tends to be an afterthought, which matters enormously in equipment service.
• Job management for trades. Well suited to small operations doing short, self-contained jobs. It runs out at multi-site customers, contract entitlements, qualification enforcement and multi-region dispatch, which is exactly where enterprise field service lives.

The useful question is not which category is best. It is which system owns the work order, and whether everything else reads from it or duplicates it.

What to look for when you evaluate

Most evaluations are run on feature checklists, which every vendor passes. These are the questions that actually separate products, and they are worth asking in a demo rather than a questionnaire.

• Ask to see it offline. Have someone put a device in aeroplane mode, complete a job with photographs and a signature, and bring it back. Watch what happens to a conflicting edit. This one test eliminates more products than any other.
• Ask what happens when the schedule breaks. Not how the optimiser builds a perfect day, but what it does at 10:40 when a job overruns and an emergency lands. Ask to see what the coordinator is shown.
• Ask how a qualification is enforced. Whether the system can prevent assignment, and whether it records the qualification held on the day of attendance rather than the one held now.
• Ask where van stock lives. If vehicles are not stock locations, inventory reporting describes a warehouse that is not where the parts are.
• Ask what the integration actually passes. Not whether it integrates with your finance system, but which objects, in which direction, how often, and what happens when one side rejects a record.
• Ask about the data you would leave with. Export format, whether history comes with it, and whether you can retrieve it without a professional services engagement.

A vendor who answers these precisely has deployed at your scale. One who redirects to the roadmap has not.

One record, not sixteen integrations

The modules described on this page are not separate applications sharing an interface. They read and write the same underlying records (customer, site, asset, work order, technician, contract), which is what makes combinations work without integration effort.

A concrete example. A contract says four-hour response for chillers at a named site. A fault is reported. The contract sets the response clock, scheduling filters to technicians holding the current refrigerant handling qualification, the asset's history and manuals travel to the device, van stock confirms the part, the completed form blocks closure until the pressure reading is captured, and the invoice draws on the entitlement to mark labour covered and the part billable.

Nine modules were involved. Nobody configured an integration, because there is nothing between them to integrate.

What implementation actually involves

Vendors are vague about this and buyers plan optimistically. Honest ranges for an enterprise deployment, assuming a mid-sized operation and a competent internal owner:

• Weeks 1–4. Work orders, customers, sites and the dispatch board. Live for a pilot region. This is genuinely fast because it needs little configuration.
• Weeks 4–10. Forms and process. The slowest phase, and the effort is not technical: it is getting your own organisation to agree what the method actually is. Budget more than you think.
• Weeks 8–16. Assets, contracts and qualifications, built up as work touches them rather than loaded in one exercise.
• Weeks 12–24. Scheduling optimisation and billing integration, once there is enough real history for either to behave sensibly.

Two things reliably wreck this timeline: attempting a full historical data migration before going live, and rolling out to technicians before there is something in it for them. Both are avoidable and both are common.

Terms you will meet in evaluations

Vendors use these words differently, which makes comparison harder than it should be. This is how they are used here.

• Work order. The unit of work. Everything else attaches to it.
• Dispatch. Committing a job to a technician and a time. Distinct from scheduling, which is deciding the plan.
• First-time fix. Jobs resolved on the first attended visit. Definitions vary wildly; ask for theirs.
• SLA and response time. The contractual clock, which starts on report rather than on assignment.
• Entitlement. What a customer's agreement covers, and therefore what is billable.
• Preventive maintenance. Servicing on an interval. Condition-based acts on a threshold; predictive forecasts one.
• Asset hierarchy. Site, system, sub-assembly. Determines whether history rolls up usefully.
• Van stock. Parts on vehicles, treated as real stock locations rather than as unaccounted issue.
• Truck roll. A dispatched visit, used as a cost unit. Reducing avoidable ones is most of the business case.

Security, hosting and where your data lives

This is usually the section that decides an enterprise purchase, and it is rarely on a feature comparison. Procurement and IT will ask; it is worth knowing the answers before the demo rather than after.

• Data residency. Which region your data is stored and processed in, and whether that can be pinned. This matters for regulated work and for customers whose own contracts constrain where their information may sit.
• Access control. Role-based permissions granular enough to separate operational access from commercial terms. A technician needs asset history; they do not need contract margin.
• Authentication. Single sign-on against your identity provider, so joiners and leavers are handled by the process you already run rather than by someone remembering to deactivate an account.
• Audit logging. Who saw what, who changed what, and when. Distinct from record amendment history, and asked about separately.
• Subcontractor access. How third parties are given scoped access without becoming full users of your tenant.
• Exit. What you can extract, in what format, and how quickly. The answer to this shapes how much leverage you have at every renewal thereafter.

The mobile side deserves its own question. Devices leave the building, get lost and get replaced. Ask what is cached on the device, whether it is encrypted at rest, and how access is revoked for a handset that is no longer in your possession.

How the modules depend on each other

Every module on this page can be enabled independently, which is genuinely useful and also the source of most confusion when scoping a rollout. Two things are worth understanding before you build a business case.

First, some modules only pay for themselves in combination. Scheduling optimisation without qualification records produces efficient plans that occasionally send an unqualified technician. Inventory without van stock as a location describes a warehouse rather than the parts your technicians have. Neither is a licensing trick; they are simply dependent on data another module owns.

Second, the modules most often deferred (contracts and asset management) are frequently the ones carrying the return. Contract entitlements determine what is billable, and unbilled contract work is usually the largest single leak in a service P&L. It is worth modelling that before deciding what to leave out of phase one.

Scope itself follows the technicians you dispatch, the locations you run and the modules you enable. Tell us how you run today and we will scope it against your operation rather than against a tier.