An elevator company with 200 field technicians. Paper work orders, phone-based dispatching, a spare parts inventory that is never synchronised with the accounting ERP. The result: a technician drives to a site for an annual inspection, discovers a secondary fault, does not have the part on the van, drives back, returns three days later. The customer waits. The SLA is missed. The cost of the visit doubles.
This scenario — common in facility management, utilities, HVAC and telecoms — is precisely what Field Service Management integrated with an ERP is supposed to eliminate. But the gap between the marketing promise and deployment reality is wide. This guide gives you the tools to close it.
What is Field Service Management, and how does it differ from traditional after-sales service?
Field Service Management (FSM) refers to the set of processes that allow an organisation to schedule, dispatch, execute and close work orders carried out by technicians working off-site. Preventive maintenance at client premises, emergency repairs, equipment installation, meter readings — all of these activities fall under the FSM umbrella.
The difference from traditional after-sales service is first and foremost organisational. A conventional service desk handles inbound requests from a call centre, with office-based agents. FSM manages mobile resources — field technicians, vehicles, van stock — in an environment where geolocation, real-time availability and mobile connectivity are permanent operational constraints.
Five challenges facing field teams without unified FSM
Wasted travel and poor skills matching. Without a routing algorithm, a dispatcher assigns the geographically nearest technician — not necessarily the one with the required skill set, or whose van carries the needed part. The first visit fails and a second must be scheduled.
SLA breaches with no early warning. When contractual commitments are not tracked inside the ERP, no one knows a critical SLA is about to be missed until it already is. Escalation comes too late.
Unsynchronised parts inventory. Spare parts exist in three places: central warehouse stock (in the ERP), technician van stock (in a local spreadsheet), and a regional hub stock (in a parallel system). The result: duplicate orders, stockouts on parts supposedly available, and unnecessary holding costs.
Paper work reports. The technician fills out a paper form on site, brings it back to the office, and someone re-keys it into the ERP two days later. In the meantime, billing is blocked and the customer history is not current for the next visit.
Invisible field productivity. Without real-time data, the operations manager does not know how many jobs are in progress, which are running late, or what the first-time fix rate was last week. They are flying blind.
FSM native to the ERP vs. dedicated module vs. best-of-breed solution: trade-offs
| Approach | Advantages | Limitations |
|---|---|---|
| Native FSM module (e.g. D365 Field Service, SAP FSM) | Unified data, no interface to maintain, billing direct from the work order | Less functionally rich than a specialist, roadmap driven by the ERP vendor |
| Dedicated connected module (e.g. FieldAware, Synchroteam) | Deeper FSM capability, sector specialisation, faster deployment | Bidirectional sync to maintain, double cost (ERP + FSM), data consistency risk |
| Integrated FSM suite in a vertical ERP (e.g. IFS, ServiceMax) | Best-in-class functionality for a sector (complex maintenance, utilities) | High licence and implementation cost, long project, low flexibility if scope changes |
The choice between these approaches depends primarily on the complexity of your field workflows and the level of financial integration required. An organisation that must invoice every work order with a quote, delivery note and same-day accounting close-out needs native or very tight integration.
Key FSM capabilities to demand from an ERP
Optimised scheduling and dispatch
A FSM scheduling algorithm must be able to cross-reference multiple constraints simultaneously: technician availability, skill required for the job type, real-time location, presence of the needed part on the van, and the applicable SLA window.
In practice, this means a heatmap dispatch view where the dispatcher can see the entire field team’s availability for the day or week at a glance, drag and drop a work order, and immediately receive an optimisation score (estimated travel time, first-time fix probability, SLA risk).
The most advanced solutions include an automatic optimisation engine: the system proposes the optimal assignment across all jobs for the day, which the dispatcher validates or adjusts. SAP Field Service Management, Microsoft D365 Field Service and IFS FSM all offer this capability.
Offline mobile application for technicians
The mobile application is the most frequent friction point in FSM projects. A technician in a dead zone — basement, remote industrial site, multi-storey car park — must be able to access the customer history, equipment drawings and schematics, job procedures and parts references without an internet connection.
Criteria to evaluate during selection:
- True offline mode (not just a cache): the technician can complete their work report offline, and data syncs automatically when connectivity returns.
- Photo and video capture: visual documentation of the job directly in the work order.
- Electronic customer signature: close the job on site with legal proof of completion.
- Connected equipment access: read IoT sensors or QR codes on equipment to retrieve its maintenance history.
Spare parts management and mobile van stock
Van stock management is often the blind spot of generic FSM solutions. A proper FSM module must manage three inventory levels simultaneously: central warehouse stock, regional hub or branch stock, and technician van stock.
When a technician consumes a part on site, their van stock is automatically decremented in the ERP. A replenishment order can be generated automatically when the minimum threshold is reached. The value of parts used feeds directly into the job cost in management accounting.
This level of integration eliminates the lag between field reality and what the procurement team sees — a lag that accounts for a significant share of operational overspend in under-tooled field teams.
SLA management and automatic escalation alerts
A maintenance contract may include dozens of SLA levels depending on equipment type, customer site priority, or time of call. The FSM must handle this matrix automatically.
In practice: as soon as a work order is created, the system calculates the first-response deadline and resolution deadline, generates progressive alerts (50% of SLA consumed, 80%, breach imminent), and automatically escalates to a supervisor if the deadline is about to be missed. This audit trail also serves as contractual evidence in the event of a customer dispute.
Overview of ERP solutions with integrated FSM
SAP Field Service Management (formerly Coresystems) — strengths and limitations
SAP acquired Swiss startup Coresystems in 2018 and integrated it into its FSM offering. The solution, now called SAP Field Service Management, is available as SaaS and can operate standalone or integrated with SAP S/4HANA via standard connectors.
Strengths: automatic dispatch algorithm (Crowd Service), service contract management, native IoT connectivity with SAP IoT, and financial integration with S/4HANA for existing SAP customers. The mobile application is robust with a proven offline mode.
Limitations: the SAP FSM licence is added on top of an already substantial S/4HANA implementation cost. For an organisation not yet in the SAP ecosystem, the total project cost can be prohibitive. Initial configuration is complex and requires a certified SAP integrator.
Microsoft Dynamics 365 Field Service — strengths for Microsoft-stack organisations
D365 Field Service is the natural choice for any organisation already on the Microsoft stack (D365 Business Central, D365 Finance, Microsoft 365, Teams). The Teams integration is particularly relevant: a technician can video-call an expert for a remote diagnosis directly from the mobile app, without leaving the job context.
Assisted scheduling uses the Universal Resource Scheduling (URS) module, which can be applied to different resource types (technicians, equipment, rooms), offering genuine configuration flexibility.
Limitations: D365 Field Service remains weaker than SAP FSM or IFS on complex industrial maintenance contract management. For organisations with highly granular multi-tier contracts, parameterisation can reach its limits.
IFS Field Service Management — specialist for complex maintenance
IFS is historically positioned in high-complexity technical sectors: aerospace, defence, utilities, energy, large-scale facilities management. Its FSM module is one of the most complete on the market for resource management, planned preventive maintenance and warranty management.
For a mid-market organisation of 200 to 1,000 employees in industrial maintenance or utilities, IFS FSM offers a functional depth that is hard to match with D365 or a generalist module. The trade-off: higher licence and implementation costs, and a longer project.
Worth noting: IFS has strengthened its IoT and predictive AI capabilities in recent years, making it a serious candidate for organisations planning to integrate sensors on customer equipment in the medium term.
Salesforce Field Service (formerly ServiceMax) — the choice for large fleets
Salesforce Field Service (from the ServiceMax acquisition in 2021) is designed for organisations with large technician fleets — several hundred — and a strong need for CRM integration. The 360-degree customer view (intervention history, active contracts, measured satisfaction) is its main differentiator.
For a mid-market organisation, Salesforce Field Service is often oversized, and its pricing model (per user, on top of an already expensive Salesforce base) makes it difficult to justify. It remains relevant for subsidiaries of international groups already standardised on Salesforce.
Mid-market alternative: FieldAware and Synchroteam are pure-play SaaS FSM alternatives worth considering for organisations seeking a dedicated FSM solution connected to their existing ERP via API. Both are more accessible financially than SAP FSM or D365, with strong sector expertise and API-first integration.
Deploying FSM in your ERP in 6 steps
Step 1: Map current processes (as-is) and define target KPIs
Before selecting a solution, document your current intervention processes in detail. How many work orders per month? What is your current First-Time Fix Rate (FTFR) — the proportion of jobs resolved on the first visit? What is your Mean Time to Repair (MTTR)? What is your average cost per intervention, including travel, technician time and parts consumed?
These baseline figures are the essential starting point for measuring post-deployment ROI. Without a baseline, you cannot demonstrate project value — to management or to the field teams.
Step 2: Choose the architecture (native module or API connector)
The choice between a native FSM module in your ERP and a specialist solution connected by API depends on three criteria:
- SLA complexity: simple service contracts (single deadline, straightforward job type) work well with a generalist module. Contracts with differentiated service levels by equipment, site or call time require a more sophisticated solution.
- Technician headcount: below 20 technicians, a standard ERP module is often sufficient. Above 50, automatic schedule optimisation generates a measurable return on investment.
- Financial integration: if you need to invoice every job on the day with immediate accounting close-out, native integration is preferable to a connector that introduces synchronisation delays.
Step 3: Run a 3-month pilot with one region or one job type
Never deploy FSM across your entire fleet simultaneously. Identify a homogeneous pilot scope: a regional branch, one equipment type, or a specific contract portfolio. This scope must be representative of your workflows but small enough that configuration adjustments can be made quickly.
The 3-month pilot will let you validate the dispatch algorithm on real data, identify edge cases not covered by the initial configuration, and measure KPI impact before rolling out more broadly.
Step 4: Train technicians on the mobile application
Mobile application adoption by technicians is the success factor most often underestimated in FSM projects. A technician accustomed to paper reports may resist a tool perceived as surveillance rather than support. This resistance must be addressed before deployment, not after.
Practical recommendations: involve two or three senior technicians in the configuration phase, beta test with volunteer users, train in small groups using real examples from the branch’s actual workload, and measure usage (proportion of reports filed via app vs. paper) from the very first week.
Step 5: Measure post-deployment ROI
Three months after full rollout of FSM, measure how your KPIs have evolved against the baseline established in Step 1:
- FTFR (First-Time Fix Rate): the proportion of jobs resolved without a return visit. Research from Aberdeen Group consistently shows that organisations with advanced FSM integration significantly improve this ratio compared to manual practices.
- MTTR (Mean Time to Repair): average time between work order creation and closure.
- SLA compliance rate: the proportion of jobs meeting contractual commitments.
- Cost per intervention: total cost (technician + travel + parts) per unit.
- Technician NPS: an often overlooked indicator, but a reliable signal of actual tool adoption.
Step 6: Extension roadmap and field data governance
A successful FSM project is never finished. After the pilot and full rollout, plan the following extensions: integration of IoT data from customer equipment, automation of preventive maintenance plans, and connection with your CRM module to feed contract renewals from field data.
Data governance is the long-term watchpoint: who is responsible for data quality in the mobile application? Who validates the parts codes used by technicians? Without clear rules, data quality degrades within months and the FSM loses much of its value.
IoT and predictive maintenance: the next leap for ERP-integrated FSM
The convergence of FSM and IoT represents a paradigm shift: moving from reactive maintenance (the customer calls because equipment has failed) or preventive maintenance (scheduled visits on a fixed calendar) to predictive maintenance (the equipment itself signals an anomaly before failure occurs).
In practice: an IoT sensor on a HVAC compressor continuously measures vibration, temperature and power consumption. When readings drift beyond a defined threshold, the signal is sent to the ERP, which automatically creates a preventive work order, assigns it to an available technician with the right part on their van, and notifies the customer. The visit happens before the failure. The uptime SLA is met. The cost is that of preventive maintenance, not emergency replacement.
SAP FSM, IFS and D365 Field Service all offer IoT connectors. The initial investment — sensors, connectivity, alert configuration — is real, but ROI is well-documented across several sectors: reduction in unplanned downtime, extended equipment lifespan, fewer emergency call-outs (which cost significantly more than preventive visits).
Checklist: is your ERP ready for FSM?
Ten questions to answer before launching your project:
- Are your service contracts digitalised in your ERP with SLA levels per customer and per asset?
- Do your technicians have access to customer history on mobile at the time of the visit?
- Is your spare parts inventory real-time — including van stock?
- Are your work reports digitalised, or are you still re-keying paper forms?
- Do you know your current FTFR from reliable data (not estimates)?
- Do you have a dispatch view showing your entire field team’s availability in real time?
- Are your SLA alerts automatic, or do you wait for a breach to be flagged manually?
- Are job invoices issued within 48 hours of work order closure?
- Is customer equipment registered in your ERP with serial number, installation date and maintenance history?
- Does your operations leadership have a dashboard updated in real time on field KPIs?
If you answer “no” to more than five of these questions, your organisation is not yet ready for an advanced FSM project. Start by making the foundational data reliable (contracts, equipment, stocks) before deploying a dispatch algorithm or IoT sensors. An FSM built on poor data will only accelerate visibility into poorly controlled processes — without fixing them.
To go deeper on related topics, see our guide to ERP and CMMS integration for industrial maintenance and our article on warranty management and after-sales service in ERP. If your teams already use mobile tools in the field, our guide to field team productivity with mobile ERP covers adoption drivers and pitfalls in detail.
