Every repeat visit is a systems failure. We engineer them out.

Yes. It is one product that has been renamed twice. It launched as Field Service Lightning (FSL), was renamed Salesforce Field Service, and is currently marketed by Salesforce as Field Service and Operations. Job specs, consultants and documentation still use all three names, so if you are comparing proposals that use different terms, they are describing the same platform.

It depends far more on integration scope than on technician count. A single-territory deployment with standard scheduling and no ERP integration is a short project. A multi-territory rollout with ERP, inventory and billing integration, offline mobile requirements and a migration from an existing field service system is a substantially longer one, and is phased by territory rather than launched at once. We scope it in discovery and give you a staged plan before any build begins — we will not quote a duration before we have seen how your dispatch actually works.

Field Service is built as an extension of Service Cloud and shares the Work Order object with it, so the two are designed to run together. Licensing depends on which users need what — dispatchers, technicians and contractors are licensed differently — and that mix is worth confirming with Salesforce directly as part of scoping, because it materially affects cost. We map the user roles in discovery so the licence conversation is based on how many people genuinely need each type of access.

Almost always because the scheduling policy does not reflect how the business really prioritises work. Work rules are hard filters — they reject any resource that violates them and are applied first. Service objectives are weighted scores applied only to the candidates that survive those rules. If the objectives are weighted for minimum travel while your dispatchers are actually optimising for SLA risk, the engine will keep producing technically valid schedules that a human overrules. Fixing it is a configuration exercise, not a reimplementation.

Only if it is configured to. The Field Service mobile app supports offline working, but records have to be primed onto the device before connectivity is lost, and anything built with Lightning Web Components has to be built for offline use specifically. Work completed offline is stored locally and queued until the device reconnects. Deciding what gets primed, what syncs and how conflicts resolve is a design decision we make during the build — not something that can be switched on afterwards.

Territories, operating hours, skills, work types, scheduling policies, standard work rules, service objectives, Flow automation and the dispatcher console layout are all configuration. Custom scheduling logic, Apex on work orders and service appointments, Lightning Web Components for the console or the mobile app, and anything the managed package does not expose are development. The boundary matters commercially, because configuration is cheaper to build, cheaper to maintain and survives Salesforce releases more predictably. We push as far as configuration will go before we write code, and we tell you when we are crossing that line.

It depends entirely on your data. Agentforce for Field Service covers scheduling assistance, on-the-job troubleshooting and job report summarisation, and its answers are grounded in your own CRM records, knowledge articles and asset data rather than the open web. That grounding is the point — and the catch. An organization with a thin installed base, no maintained knowledge articles and inconsistent debrief capture will get an agent that is confidently wrong. We usually recommend fixing asset and knowledge data first; the AI is worth far more six months later on clean data than it is now on poor data.