Field Service Management Software: How to Choose

Every field service management demo you sit through will look impressive. A job appears on a map, an engineer is dragged onto a timeline, a phone buzzes, a signature is captured, a PDF lands in an inbox. Forty minutes of that and every platform on your shortlist feels equivalent. The differences that decide whether the software works for your business are almost never in the demo script: they are in how the invoice gets raised, how a service contract with an SLA clock behaves at month end, what the mobile app does with no signal in a plant room, and whether a subcontractor's job looks like a first-class job or an awkward exception. This guide is about finding those differences before you sign, not eighteen months after.

The message up front: the single biggest dividing line in this market is whether the platform closes the commercial loop. A tool that schedules jobs and captures completion is job tracking. A real field service management platform prices the work, costs it against labour and parts, raises the invoice, and passes it cleanly to finance. Everything else on the checklist matters, but that is the boundary that decides which tier of product you are actually looking at.

1. What field service management software is for

Field service management software exists to run maintenance and service work that happens away from your own premises, performed by mobile engineers, usually under a commercial arrangement with a customer. That last clause is what makes the category distinct. A CMMS is built around your assets in your buildings, maintained by your team, with cost as an internal budget line. FSM software is built around a job that belongs to a customer, delivered against a contract or a quote, and finished when it has been invoiced and paid.

That changes the shape of the whole system. The customer becomes a first-class entity, not a reference field. The engineer's diary becomes a scarce resource to be allocated, not just a name on a work order. The job carries a price as well as a cost. Compliance paperwork has to be presentable to somebody outside your organisation. And the SLA clock is contractual rather than aspirational.

If you are still deciding whether you need FSM at all rather than maintenance software, start with field service versus CMMS and the broader practitioner's guide to field service management. This article assumes you have made that call and are now choosing a platform.

2. The capability checklist that actually matters

Vendor feature lists run to hundreds of rows, and almost every row is present in some form in almost every product. The useful question is never "do you have it" but "how deep is it, and what happens at the edges". The table below is the checklist I would work through with a buying team, with the depth question that separates a tick from a capability.

Work down that right-hand column in a demo and the shortlist thins out quickly. Most products answer three or four of those questions convincingly and improvise on the rest.

3. Scheduling and dispatch: manual, assisted, optimised

Scheduling is the capability buyers get most excited about and most often over-buy. It is worth separating it into three genuinely different things.

• Manual scheduling. A planner board where a dispatcher drags jobs onto engineers and days. The software's job is to make the constraints visible: who is qualified, who is nearby, who is already full, what is overdue. For a team of ten to thirty engineers with a competent dispatcher who knows the patch, this is often the best answer, and every platform does it.
• Assisted scheduling. The system proposes candidates ranked by fit, travel and availability, and the dispatcher decides. This is where most of the practical value sits. It keeps human judgement in the loop, which matters because the dispatcher knows that this customer will not accept that engineer and that this site needs two hours not one.
• Full optimisation. The system builds the routes and the day plan itself, re-optimising as jobs and emergencies arrive. Genuinely powerful in the right operation, and a poor fit in most.

The mechanics of dispatch boards, priority rules and engineer allocation are covered in more depth in work order dispatch and scheduling software, and the optimisation question specifically in field service scheduling and route optimisation.

4. Contracts, PPM and SLA clocks

If a meaningful share of your revenue is contracted maintenance rather than one-off calls, contract handling deserves more weight in your scoring than scheduling does. The questions that matter:

• Contract structure. Can a single contract cover many sites, many asset groups and several PPM frequencies, with its own rate card, and tell you its profitability across the term?
• PPM generation. Does the planner generate a year of visits you can level out across the calendar, or dump them all in the anniversary month?
• Task lists. Are asset-type service specifications held once and reused, or retyped per contract? This is where operations quietly drown.
• SLA clocks. Response and rectification need to be separate, calculated against the customer's working calendar and holidays, pausable for genuine reasons such as awaiting parts or site access, with the pause reason recorded.
• Renewals and uplifts. Contract expiry visibility, indexation, and re-quoting without rebuilding the asset list.

I would treat the SLA clock as a pass or fail test. If the platform cannot pause a clock for customer-caused delay and evidence it, you will lose arguments you should have won, and your reported performance will be worse than your actual performance. The measurement frame around this sits in field service KPIs, SLAs and contractor management, and for the Gulf-specific contract shapes, AMC management with a GCC focus.

5. Quoting and job costing

Quoting and costing are the two halves of knowing whether the work you do makes money. A useful quoting module lets an engineer raise remedial recommendations from site, turns them into a priced quote against the customer's rate card, tracks acceptance, and converts the accepted quote into a scheduled job. The conversion step is the one to test. If accepted quotes are rekeyed as new jobs, your quote-to-order data will never be reliable and your engineers will stop bothering.

Costing is the harder capability and the one most often overstated. Ask to see a single completed job with labour at the engineer's real cost including travel and overtime, parts at cost rather than sale price, any subcontractor invoice attached, and the resulting margin. Then ask for the same view rolled up by contract and by customer. Plenty of platforms can show revenue by customer. Far fewer can tell you which contracts are losing money, which is the report that changes commercial behaviour.

6. Parts, van stock and purchasing

Field service inventory is not warehouse inventory. Stock sits in vans, in engineers' boots, on customer sites and in a small central store, and it moves without paperwork unless the system makes recording it easier than not recording it. What to look for: the van as a real stock location; parts consumption booked from the mobile app as part of closing the job, in two taps; purchase orders raised against a job so material cost lands where it belongs; supplier delivery against PO; and a stock take process a non-specialist can run.

Also ask what happens with a part bought specially for one job, which is extremely common in commercial maintenance. It should be procurable against the job, cost-allocated to it, and invoiceable with a markup rule, without ever entering general stock.

7. Mobile and offline behaviour

The mobile app is where your platform either gets adopted or quietly abandoned. Two things decide it.

The first is how long it takes to close a routine job. Count the taps in the demo. If completing a simple reactive call takes an engineer more than a couple of minutes of data entry, expect paper to reappear within a month and your data to degrade with it.

The second is offline. Plant rooms, basements, lift shafts and remote sites have no signal, and "offline support" covers a wide range of behaviour. The question is whether the engineer can create and edit records offline, including forms, photos, parts and signatures, and whether the app resolves conflicts sensibly when it reconnects after several jobs. Read-only offline caching is a much weaker capability sold with the same two words. Test it properly: put the phone in airplane mode, complete three jobs including a photo and a parts issue, then reconnect and see what survived. The detail behind this is in mobile field service apps for technicians.

8. Customer portal, notifications and the finance integration

A customer portal changes the economics of your back office more than almost any other module, because it moves the "where is my engineer" call out of your office. Judge it on whether the customer can log a job, track it, retrieve certificates and history, and approve quotes. Notifications should be configurable per customer and per event, since one client will want an email per status change and another will want silence and a monthly report.

Then the invoicing and finance integration, which is the capability I would weight highest of all. This is the single biggest differentiator between a real field service management platform and a job-tracking tool with a nice planner board. A platform that closes the loop takes the completed job, applies contract or rate-card pricing, produces the invoice with correct tax treatment, pushes it to the ledger, and brings payment status back so credit control can see which customers are slow. A job-tracking tool produces a completion record that somebody in accounts then re-enters.

Test it with your own ledger and your own awkward cases: part-billed jobs, retentions, credit notes, consolidated monthly invoices across many jobs for one customer, multi-currency if you operate across borders, and the tax rules of the jurisdictions you bill in. Ask specifically whether the integration is native and two-way or a scheduled file export, and who owns it when it breaks. The volume of manual re-entry left after go-live is the true measure of the integration, and it is rarely what the brochure implies.

9. Subcontractors, compliance and reporting

Almost every service business subcontracts something, and in many contracts the subcontracted spend is larger than the direct labour cost. Yet subcontractor handling is where platforms most often reveal that they were designed for a single directly-employed workforce. Look for subcontractors as a real resource type that can be scheduled; their own portal or mobile access so they update the job rather than emailing you; their own rate cards and purchase orders; their completion paperwork attached to your job record; and insurance and accreditation expiry tracking that blocks allocation when a document lapses.

Compliance capture is the related discipline: structured digital forms rather than free text, engineer competency held against the person so the system can refuse an unqualified allocation, certificates generated in the format your customer and your regulator expect, and an audit trail you can retrieve years later. In regulated trades this is not a nice-to-have, it is the reason the software exists. Where your forms map to a published standard or a maintenance specification, ask how the vendor keeps those task lists current, and whether updates are their responsibility or yours.

On reporting, the practical test is whether an operations manager can build a new report without a consultant, and whether you can get your own raw data out through an API or a database view. Data portability is a commercial protection as much as a technical feature.

10. The market tiers and who each one suits

The FSM market sorts into four reasonably distinct tiers. Products move between tiers as they develop and several straddle a boundary, so treat the placements below as orientation rather than classification, and verify current capability yourself. The named platforms are examples of where a tier's products tend to sit, not a ranking and not a shortlist.

Trades and mid-market examples. Products commonly encountered in the trades and mid-market service tiers include Joblogic, Simpro, ServiceTitan, BigChange, Commusoft and FieldEdge. They differ in trade focus, geography, contract depth and how far the commercial side extends, and several have moved up-market over time. Positioning here is indicative only.

Enterprise examples. At the enterprise end you will typically meet Salesforce Field Service, Microsoft Dynamics 365 Field Service, IFS, ServiceMax and SAP Field Service Management. The first two also illustrate the suite tier, since their value case leans heavily on the CRM and ERP record they sit inside.

11. Pricing models and cost drivers

I am not going to quote prices. They move, they vary by region and negotiation, and a published figure would be wrong by the time you read it. What is stable is the structure, and understanding the structure is what stops the surprise.

How FSM software is usually priced:

• Per user per month, tiered by user type. The most common model. A field or mobile user is normally cheaper than an office, dispatcher or full user. Read the definitions carefully, because how a part-time engineer or a subcontractor is counted can change the bill substantially.
• Feature tiers or editions. A base plan with contracts, advanced costing, optimisation, the customer portal or the finance connector held in a higher tier or sold as a module. Map your must-have list onto tiers before comparing any numbers.
• Minimum commitments and terms. Minimum user counts, annual or multi-year terms, and uplift clauses at renewal.
• Consumption elements. SMS and notification volumes, storage for photos and documents, API call allowances, extra environments.

The cost drivers that dominate the business case:

• Implementation and configuration. On mid-market and enterprise platforms this routinely rivals or exceeds the first year of subscription. Ask what is fixed price and what is time and materials.
• Data migration. Customers, sites, assets, contracts, PPM schedules and open jobs. Asset and contract history is the expensive part, and the cost is driven by the state of your current data, not by the vendor.
• Integration. The finance connector, and anything else. A supported native connector is a line item; a bespoke integration is a project with a maintenance tail.
• Forms and task list build. Digitising service specifications and certificates is often underestimated by a wide margin.
• Training and the productivity dip. Engineers and dispatchers are slower for several weeks. Budget it rather than being surprised by it.
• Internal ownership. Somebody has to own the system, configure it, and keep the data clean. If you do not name that person, the platform decays whatever you paid for it.

Build a three-year total cost view covering subscription, implementation, migration, integration, training and internal time, and ask every shortlisted vendor to price the same scope. Comparing headline per-user rates across products with different tier boundaries tells you almost nothing.

12. How to evaluate: the scripted demo

The way to get a truthful comparison is to stop letting vendors drive the demo. The approach I would recommend to any buying team:

• Write down your requirements first, weighted. Separate must-have from nice-to-have before you see any software, because demos rearrange your priorities. If you want a formal structure for this, the scoring method in a scoring framework for maintenance software transfers directly, and how to write an RFP covers the document itself.
• Shortlist by tier, not by brand recognition. Three or four products from the tier that matches your operation. Include one from the tier below to check whether you are over-buying. Approaches to building and cutting a shortlist are covered in how to shortlist maintenance software.
• Script the demo on your own job types. This is the highest-value step in the whole process. Send every vendor the same script in advance and make them run it.
• Put the same people in every session. A dispatcher, an engineer, someone from finance, and the person who will own the system. Score independently, immediately, on the same sheet.
• Do a hands-on trial with your own data. A sandbox with a sample of your real customers, sites, assets and contracts. Let two engineers use the app on real jobs for a fortnight.
• Take references in your trade and your region. Ask them what went wrong, how long it really took, and what they would do differently. The useful answers are never in the case study.
• Check the exit before you enter. Data export, API access, contract notice period and what happens to your records if you leave.

A demo script you can lift and adapt. Ask every vendor to perform these, live, in this order:

1. Take a reactive call from an existing contract customer, apply the right SLA, and dispatch it to a qualified engineer today.
2. Complete that job on the mobile app in airplane mode, including a form, two photos, a part issued from van stock and a customer signature. Reconnect and show the synced record.
3. Show the same job's cost and margin, using labour cost and parts cost, and then invoice it into the finance system.
4. Set up a new PPM contract covering three sites and two visit frequencies, and generate a year of planned visits levelled across the calendar.
5. Raise a remedial quote from a completed PPM visit, have the customer accept it in the portal, and convert it to a scheduled job.
6. Allocate a job to a subcontractor, raise the purchase order, receive their completion paperwork onto the job record, and reconcile their invoice.
7. Pause an SLA clock because the customer denied site access, record the reason, and show the audit trail and the reported performance afterwards.
8. Show an engineer certification expiring and demonstrate what the system does when you try to allocate them to work requiring it.
9. Produce a contract profitability report across a customer with multiple sites, then build one new report on screen without developer help.
10. Export your own data, in full, and show what an API call looks like.

Ten scenarios, scored consistently across three or four vendors, will tell you more than any amount of feature-matrix comparison. Watch specifically for the moments where the demonstrator says that is on the roadmap, or switches to a spreadsheet, or needs to bring in a specialist. Those moments are the real findings. For trade-specific variants of this script, the dispatch patterns in HVAC service management and dispatch software are a good template to adapt.

The idea to walk away with

Field service management platforms differentiate on the commercial loop, not the planner board. Everybody can draw a schedule and push a job to a phone. The questions that separate products are whether a contract with real SLA behaviour can be modelled properly, whether a job carries true cost and margin, whether the mobile app survives a basement with no signal, whether a subcontractor is a first-class resource, and whether the invoice reaches your ledger without being retyped. Score those heavily and the rest of the feature list will look after itself.

Choose the tier that matches the operation you run now, not the one you hope to run in five years. Over-buying is the dominant failure mode in this category: an enterprise platform in a mid-market business consumes budget and attention and delivers configuration debt, while a lightweight tool in a contract-heavy service business quietly loses you margin you cannot see. And whichever tier you land in, name the internal owner before you sign. The platforms that succeed are not the ones with the best demo; they are the ones somebody looks after.

Final thoughts

The most useful hour you can spend in an FSM selection is not with a vendor. It is with your own dispatcher, your own engineer and your own finance manager, writing down the ten jobs that cause you the most pain today and exactly what a better system would have to do differently. That document is your requirement, your demo script and your scoring sheet, and it is the only thing in the process that is genuinely yours rather than the vendor's.

Then be disciplined about the demo. Make every vendor run the same ten scenarios on your job types, score them the same afternoon, and treat every roadmap answer as a no. Do that and the decision usually makes itself, because after three or four scripted sessions the gap between the platforms that close the commercial loop and the ones that merely track jobs is impossible to miss.

Related reading: Field service management: a practitioner's guide, Field service vs CMMS: which do you need, Work order dispatch and scheduling software, Field service scheduling and route optimisation, Mobile field service apps for technicians, Field service KPIs, SLAs and contractor management, How to shortlist maintenance software.