ERP for Field Service: Why Standard Modules Always Need Customization
Odoo's Field Service module is capable. SAP S/4HANA's service management handles complex scenarios well. Business Central has the FSM extension. Every one of these covers the core workflow: create a work order, assign a technician, record the time and materials, generate an invoice. The problem is that real field service operations have scheduling constraints, mobile requirements and billing complexity that the standard module only partly covers. The rest always needs customization. After seven field service ERP implementations, the gaps are predictable. Here is the list.
Gap 1: scheduling optimization is not in the module
Standard ERP field service modules provide a scheduling calendar, a visual interface where you assign technicians to jobs. What they do not provide is scheduling optimization: automatically assigning the nearest available technician with the required skills who can reach the site within the committed service window, considering travel time between jobs, technician skill certifications, equipment requirements, and priority level.
This matters because manual scheduling, a dispatcher looking at a map and a calendar, does not scale. A team of 15 technicians with 40 daily jobs across a region produces a scheduling problem that has more variables than a human can optimize in real time. The standard module shows the problem; it does not solve it.
The options range from simple rule-based auto-assignment (nearest available technician with skill match, no travel optimization) to full route optimization integrations with tools like Google OR-Tools or dedicated FSM platforms that feed back into the ERP for billing. The right level of sophistication depends on team size and job density. Under 10 technicians or under 30 daily jobs, manual scheduling with good tooling is often adequate. Above those thresholds, the cost of poor scheduling (wasted travel time, missed SLAs, overtime) usually exceeds the cost of building auto-scheduling.
Gap 2: a mobile experience technicians will use
Standard ERP mobile apps for field service require internet connectivity, have UI that was designed for desktop workflows and adapted for mobile, and often take a dozen taps to complete a simple job check-in. Technicians who are standing at a customer site, sometimes with gloves on, in a hurry to start the job, will not use a system that requires 12 taps and an internet connection to log their arrival.
The practical requirements for field service mobile that standard apps frequently miss: offline mode with sync when connectivity returns, single-tap job start/complete, photo capture for before/after documentation that attaches directly to the work order, barcode scanning for parts consumption without manual entry, and signature capture for customer sign-off.
ERP mobile apps have improved and handle much of this in recent versions. Check the gaps in the one you are evaluating: how far offline mode goes, how many steps a photo attachment takes, and whether recording parts means moving to a separate screen. For HVAC technicians doing 6 to 8 jobs a day, the answer is often a simplified mobile interface built on the ERP's API just for the technician workflow. Four screens: today's jobs, job detail, record time and parts, customer signature. Technicians use an app like that. They route around one that fights them.
The test for field service mobile: give the app to a technician who has never seen it before, ask them to check in to a job and record 30 minutes of labor and two parts used. Time them. If it takes more than 90 seconds with no guidance, the interface will not be adopted in the field. Standard ERP apps often take several minutes for the same task.
Gap 3: contract billing complexity
Field service billing is more complex than standard ERP billing modules assume. The common billing models in field service each have their own rules for invoicing labor, parts and travel: time and materials, fixed-price contracts, service level agreements with penalty clauses, retainers with cap hours, and hybrid contracts where some work is in scope and some is billable.
Standard ERP modules handle time and materials billing and fixed-price contracts reasonably well. SLA contracts with escalation and penalty tracking, retainer billing reconciled monthly against cap hours, and hybrid billing rules need customization.
The specific gaps: travel time billing rules (is travel billed at the same rate as labor, at a flat fee, not billed at all, billed only if over a threshold distance?), parts markup rules by contract type, SLA breach detection and credit calculation, and retainer drawdown tracking that shows the customer their remaining hours in real time.
Our take
Gap 4: customer portal and real-time communication
Customers want to know when the technician is coming, where they are, and what the job will cost before the invoice arrives. Standard ERP field service modules are not built around real-time customer communication. They are built around internal workflow management.
The gaps: automated appointment confirmation and reminder SMS/email, real-time technician location sharing in the 30 minutes before arrival, job completion notification with photo documentation attached, and draft invoice approval before final posting for high-value jobs.
Most of these are buildable with ERP + webhook + SMS/email automation tools (Twilio, SendGrid, make.com). They require integration development rather than ERP customization, but they are not in the standard module, and customers notice them. Real-time arrival notifications alone take out a large share of the inbound "where is the technician?" calls.
Budgeting for the customization honestly
A field service ERP implementation that includes scheduling optimization, a proper mobile experience, complex billing logic, and customer communication should budget well above a standard ERP implementation for a company of similar size doing other work. Needing customization does not mean the product is badly designed. It reflects how complex field service operations are.
The mistake to avoid: a company buys an ERP with a field service module, budgets for a standard implementation, discovers the module does not handle its billing rules or its mobile requirements, and runs out of budget mid-project. The customization cost was always going to be there. Discovering it mid-project just costs more than planning for it. Ask the specific questions before signing: show us how your system handles SLA penalty billing, and show us how your mobile app works offline.