Salesforce Field Service - historically Field Service Lightning, hence the still-common FSL acronym - is, in our reading, the most powerful and most frequently misimplemented cloud on the platform. Set up properly, it turns whiteboard-driven field operations into a well-oiled machine. Set up badly, it produces absurd schedules and furious technicians. Here is how to end up in the first category.
01Why: the hidden cost of manual operations
An organization that schedules its jobs by hand pays three times over: schedulers' time, unoptimized travel, and field information that comes back late or never. Field Service tackles all three at once:
- Automatic scheduling - the scheduling and optimization engine identifies qualified technicians, checks their availability, then arbitrates according to your priorities: skills, territories, availability, and weighted objectives (minimal travel, urgency, preferred resource…).
- Optimized routes - optimization aims for fewer kilometers, more jobs per day and time slots that are kept, with three modes: a global schedule optimization (typically overnight), an in-day optimization to absorb emergencies and cancellations, and a per-resource optimization.
- A connected field - the mobile app, designed to work offline, pushes statuses, photos and signatures as soon as the device gets back online; head office knows, and so does the customer.
02For whom: the telltale signs
Field Service is made for you if you recognize yourself in at least two of these situations:
- Dozens of jobs a day, scheduled in Excel or on a board.
- Technicians (in-house or subcontracted) spread across geographic zones.
- Customer appointments with time slots to honor - and penalties when they slip.
- Repeatable job types: installation, maintenance, repair, fitting.
Equipment, energy, property maintenance, medtech, telecoms: this is where we see Field Service deliver the most. We are implementing it, among others, for a fast-growing home-services company - scheduling of installations in homes, territories and assignment rules end to end, a mobile app calibrated for technicians.
03How: the three foundations that make all the difference
90% of Field Service failures stem from botched foundations - that is what we see on the projects we take over. The three that matter:
- The territory model. It must reflect your operational reality, not your org chart: hierarchical territories, operating hours, zones drawn or imported. One poorly cut territory, and the optimizer sends your technicians across the region.
- Scheduling policies. This is the brain of automatic scheduling, and it has two halves: work rules - non-negotiable filters (resource availability, territory match, skills) that say who can - and weighted service objectives (minimal travel, urgency, preferred resource, overtime to avoid…) that say who is best. Poorly calibrated, the optimizer "works" - but produces aberrations. The real value lever is tuning the objective weights, measurable directly on the Gantt: utilization rate, scheduled hours, average travel.
- Calibrated job durations. The work type carries the estimated duration, inherited by work orders and appointments: fanciful durations ruin the best of engines. Classic trap: changing a work type does not fix the orders already created.
Automatic scheduling invents nothing: it executes your rules and arbitrates according to your priorities. If the rules are fuzzy, so is the schedule.
04Three points that get settled at scoping
- Preventive maintenance. Maintenance plans automatically generate work orders - by calendar, by criteria or by usage. For repeatable job types, this is what moves you from reactive to anticipated scheduling.
- Roles and licenses. Dispatcher, technician, agent: each has its own set of permissions, and the scheduling and mobile licenses are carried by the service resource. A point to scope early, along with the activation order that goes with it.
- The mobile app, calibrated for the field. Sync windows trimmed to the necessary, narrow list views, lighter screens: less embedded data, more reliability and more adoption. An overloaded app is the first cause of rejection by technicians.
05The right sequence
Our approach: a pilot on one territory and one job type within a few weeks - scoping in immersion with the dispatchers, sprint-based build tested on real cases, then extension territory by territory. Optimization is in fact activated territory by territory: the pilot is not a compromise, it is how the tool is designed.
Want to assess whether Field Service is the right choice for your operations? Our Field Service page details the typical scope, or tell us about your operations - a Field Service architect will get back to you.