The package installs in an afternoon. The deployment is the real work.

Integration count and data migration, far more than technician headcount. Adding fifty technicians to a designed territory model is a roster exercise. Adding one ERP integration means field mapping, error handling, reconciliation design and a round of testing against real financial data. The second driver is how much of your dispatch logic is genuinely standard — if your priorities can be expressed as work rules and service objectives, it is configuration; if they cannot, it becomes development, which is a different cost and maintenance profile.

Yes, and we recommend it. A single-territory pilot proves the territory model, the scheduling policy and the mobile rollout against real jobs before the rest of the business depends on them. It also contains the blast radius: if the schedule is wrong in week one, it is wrong for one depot rather than for every technician you employ. The pilot territory should be representative rather than easy — piloting in your simplest region proves very little.

The managed package is what brings the dispatcher console, the scheduling and optimization tools, guided setup and a set of additional objects. Work orders and service appointments exist in Salesforce without it, but scheduling them by hand defeats the purpose of the platform. If you intend to use automated scheduling or the dispatcher console — which is almost always the reason for adopting Field Service — you need the package installed and configured, and that configuration is the bulk of the implementation.

Three things early, and they are the usual cause of delay when they arrive late. First, an accurate technician roster with real certifications — not job titles, but what each person is actually trusted to do. Second, your genuine dispatch priorities: what a good schedule looks like when an SLA job and a nearby job compete. Third, named owners and credentials on every system we have to integrate with. Later we need scheduled time from real dispatchers and technicians for UAT and training; sending proxies is how deployments pass testing and then fail in the field.

Yes, and it is a common engagement. We start with an audit rather than a rebuild: what has been configured, what the territory and scheduling model assumes, what is genuinely broken versus simply untuned, and what can be kept. Stalled implementations usually have a sound package configuration and an unsound foundation design, which is recoverable. We give you an honest assessment of what is salvageable before you commit to the remediation, because occasionally the correct answer is to redo the foundation rather than patch it.

Dispatchers override the optimizer. It is the single most common early signal, and it is rarely a defect — it means the scheduling policy does not yet reflect how the business really prioritises work. The fix is to watch which assignments get overridden and why, then reweight the service objectives accordingly. The second common issue is technicians not completing debrief properly, which quietly destroys your first-time fix reporting. Both are why we keep tuning in the engagement rather than treating go-live as the finish line.