Salesforce Field Service implementation

Dispatch needs more than an available time slot

A service appointment can look correctly scheduled while the technician lacks the right skill, part, access instructions or warranty information. The cost appears as repeat visits, delayed completion and frustrated customers. Emerge designs Salesforce Field Service around the complete work order and the decisions dispatchers and technicians need to make.

Salesforce currently markets the field-service portfolio as Agentforce Field Service. We assess the actual enabled products, mobile requirements and operating arrangements before specifying features. The delivery objective remains concrete: connect customer demand, asset context, scheduling, execution and verified completion without losing responsibility between teams.

Define the work and asset model

A work order describes the requested service; an appointment represents a planned visit or allocation of time. An asset, location and customer relationship provide the context needed to perform the task. We establish those distinctions with the service organisation before configuring the workflow.

Asset information may come from an ERP, installation record or existing maintenance platform. The design identifies the authoritative serial number, product model, warranty status and service history. A technician should be able to understand the source and freshness of the information rather than treating every copied field as current fact.

Work types specify the required skills, expected activities and evidence of completion. A routine inspection, breakdown response and installation may need different forms, parts and approval steps. We define what can be standardised and which exceptions require a dispatcher or specialist to make a decision.

An illustrative service-to-visit workflow

A customer request becomes a case or service demand with a clear reason and relevant asset context. The responsible team validates entitlement and the work required, then creates a work order with the information needed for dispatch. Missing access details or uncertain warranty coverage enter a visible review step.

Scheduling considers the agreed service territory, skills, availability and practical constraints. A customer-facing appointment is confirmed through the selected communication channel. A later change follows a documented process so a revised time does not remain inconsistent across the dispatcher, technician and customer views.

The technician receives the approved job context on the selected mobile experience. They record work performed, parts used, observations and any required evidence. If the job cannot be completed, the reason creates an actionable follow-up rather than a misleading closure. Accepted completion updates the service record and the downstream commercial or maintenance process.

Design for the conditions in the field

Mobile connectivity, device policies and the working environment influence the implementation. We inspect the actual requirements for offline access and synchronisation in the selected product configuration. The test plan includes interruptions and conflicting updates instead of assuming every technician has a stable connection throughout the visit.

Job forms should collect information that someone will use. Excessive mandatory fields can encourage inaccurate completion, while missing evidence can leave service or finance unable to accept the work. We prototype the workflow with technicians and supervisors, using real task sequences and safe representative data.

Scheduling automation also needs an override model. An efficient proposed route may be impractical because of customer access, a safety constraint or a part that has not arrived. Dispatchers need to understand the reason for a recommendation and retain appropriate control over exceptions. Automation does not replace the organisation’s responsibility for safe work practices.

Connect completion to the receiving business process

Service completion may trigger billing, warranty recovery, inventory updates or a future maintenance task. We define which system accepts each change and what evidence it requires. A mobile submission is distinguished from an approved commercial completion when a supervisor or destination system still has to review it.

Integration contracts handle repeated synchronisation and partial failures without duplicating parts usage or billing requests. The operating team can reconcile the work order, appointment and downstream record. Exceptions have an owner who can resolve the business issue rather than simply rerun a technical job.

Release with dispatchers and technicians

Acceptance follows routine work, urgent work, an unavailable customer, a missing part, reassignment and an incomplete visit. Access tests cover technicians, dispatchers, supervisors and external resources where applicable. The team verifies the information visible on mobile and the effect of a role or territory change.

We pilot with a defined work type or service area and inspect the actual handovers. Reporting distinguishes scheduled activity, completed work, repeat visits and unresolved exceptions. Measures are agreed with the service owner; no generic productivity or service-level improvement is promised before the baseline is understood.

Keep the service model current

Emerge hands over work-type definitions, asset mappings, scheduling rules, mobile release procedures and exception runbooks. Named owners manage changes to skills, territories, parts and completion evidence. The operating review examines why work cannot be completed and whether the system gives the team enough context to prevent avoidable repeat visits.