# Salesforce Field Service Consulting | SynconAI > Salesforce Field Service consulting: scheduling policies built on measured durations and real travel, offline mobile, and first-time fix that moves. Publisher: SynconAI Source: https://synconai.com/salesforce-field-service Canonical HTML: https://synconai.com/salesforce-field-service Markdown cite: https://synconai.com/salesforce-field-service.md Contact: contact@synconai.com ยท +61 2 7813 0221 ## Positioning facts - Why dispatchers override the optimiser: The optimiser is rarely the problem. It schedules exactly what you told it, so if travel times assume empty roads and service durations came from a product sheet rather than a stopwatch, it will build a day nobody can physically complete. Then dispatch overrides it, and within a month the schedule is manual again. - Service durations: Service durations are the single most under-measured input in field service. Most orgs carry an estimate somebody wrote at implementation and nobody has revisited since, which is why the third job of the day is already late. - Skills recorded aspirationally: Skills get recorded aspirationally, because nobody wants to say a technician cannot do something. The result is work routed to people who then need help on site, which costs more than an honest skills matrix ever would. - Offline is a design decision: The mobile app has to work in a basement, a lift shaft and a rural black spot, because that is where the work is. Offline behaviour is a design decision made up front, not something discovered during the pilot. - First-time fix: First-time fix rate is the metric that pays for the whole programme. Every failed visit is a second dispatch, a second travel leg and a customer who has now taken two days off work, so a point of fix rate is worth more than most efficiency gains. ## Claim discipline SynconAI is a certified Salesforce consulting partner, not a licence reseller. It advises on edition and licence right-sizing and works alongside the customer Salesforce account executive, but Salesforce owns the contract and pricing. Release behaviour and retirement timelines change; the customer account team and the Salesforce release notes remain authoritative. ## What this service is Salesforce Field Service implementation and rescue: work order and asset model, scheduling policies and optimisation objectives tuned on measured durations and real travel, territory, skills and capacity modelled honestly, dispatcher console design, an offline-capable mobile experience for technicians, parts, inventory and warranty joined to the job, preventive maintenance spread against real capacity, and contractor or crew scheduling treated as first-class capacity. ## Delivery cycle 01. Measure: How long jobs really take and how far technicians really travel, with a stopwatch 02. Map: Work orders, assets, territories and skills recorded honestly rather than aspirationally 03. Schedule: Policies and objectives tuned to a day a technician can actually complete 04. Equip: A mobile app that works in a basement, because that is where the work is 05. Supply: Parts, warranty and contractors joined up so the van carries what the job needs 06. Improve: First-time fix, travel and overtime watched together, because they trade against each other ## Scope of delivery - Work order and asset model: What a job is, what it is against, and what history follows the asset, so the technician arriving knows what happened last time. - Scheduling policies and objectives: Optimisation tuned on measured durations and real travel, weighted for what your business actually values between cost, SLA and overtime. - Territories, skills and capacity: An honest skills matrix and territory model, because work routed to someone who then needs help on site costs more than admitting the gap. - Dispatcher console design: A Gantt a dispatcher will trust and work with, rather than one they override every morning and quietly rebuild in a spreadsheet. - Mobile for technicians: Offline-capable by design, with the flow, forms and signature capture built around gloved hands and bad light rather than a demo laptop. - Parts, inventory and warranty: Van stock, consumption and returns joined to the job, plus entitlement and warranty so nobody bills a customer for covered work. - Preventive maintenance: Maintenance plans that generate work on a schedule the fleet can absorb, instead of dumping every asset into the same week each quarter. - Contractors and crews: Third-party capacity treated as first-class: scheduling, access, evidence of work and cost, without giving away your whole org. ## Capability coverage ### Work and asset model - Work orders and work order line items - Work types, duration and skill requirements - Service appointments and appointment windows - Assets, asset hierarchies and asset history - Maintenance plans and maintenance work rules - Products required and products consumed - Linking work back to the case or the contract ### Scheduling and optimisation - Scheduling policies and policy design - Work rules and service objectives - Global, in-day and resource optimisation - Appointment booking and arrival window design - Emergency and same-day dispatch handling - Multi-day, multi-resource and crew scheduling - Measured service durations feeding the whole model ### Territories, resources and capacity - Service territories and territory members - Operating hours and time zone handling - Service resources, crews and capacity-based resources - Skills, skill levels and an honest skills matrix - Resource absences, shifts and availability - Contractor and third-party capacity as real capacity - Seasonal and peak capacity planning ### Dispatch - Dispatcher Console and Gantt configuration - Map view, polygons and territory visualisation - Drag-and-drop scheduling and candidate lists - Appointment lists, filters and saved views - Rules-based prioritisation and alerts - Override tracking as a health measure - Change and reschedule handling with customer notification ### Mobile and the technician - Field Service mobile app configuration - Offline priming, sync and conflict handling - Flows and quick actions on mobile - Service reports, signature and photo capture - Barcode scanning and product consumption - Van stock visibility at the point of work - Data capture cut back to what someone downstream reads ### Inventory, warranty and AI - Locations, product items and inventory tracking - Product transfers, requests and returns - Entitlements, warranty terms and chargeability - Contractor access scoped and revoked deliberately - Reporting on first-time fix by failure reason - Travel, overtime and utilisation reported together - Agentforce scoped to briefing, diagnosis support and drafting ## How success is measured Against the fleet that exists: first-time fix rate, travel time per job, schedule adherence and how often dispatch overrides the optimiser, jobs completed per technician per day, overtime, parts availability at the point of work, and estimated versus actual service duration. That last comparison is usually where the scheduling problem is hiding. ## FAQ ### We implemented Field Service and dispatchers still schedule by hand. Why? Almost always because the optimiser was fed inputs it could not honour. It schedules exactly what you told it, so if travel time assumes empty roads and service durations came from a product sheet rather than a stopwatch, it produces a day nobody can physically complete. Dispatch overrides it once, then twice, and within a month the schedule is manual again and everyone concludes the optimiser does not work. We measure durations and travel before touching a policy, because that is where the fix actually is. ### How do you improve first-time fix rate? By working out why visits fail, which is normally three things: the wrong skill was dispatched, the part was not on the van, or the person arriving did not know what happened on the last visit. Each has a different fix, and each is answerable from your own history if the data is there. We chase first-time fix ahead of raw efficiency because a failed visit costs a second dispatch, a second travel leg and a customer who has now taken two days off work. ### Our technicians will not use the mobile app. What usually causes that? Two things. It asks for more than the job needs, so a five-minute repair carries a fifteen-minute form. And it fails where the work happens: basements, lift shafts, plant rooms, rural sites. Offline behaviour is a design decision made up front, not something discovered during the pilot. We design the mobile flow around gloved hands, bad light and no signal, then cut the data capture back to what someone downstream genuinely uses. ### Can we schedule contractors as well as employees? Yes, and it is worth designing deliberately rather than bolting on. Contractors need to receive work, see enough to do it, and provide evidence and cost back, without being given the run of your org. We model that access explicitly, and we treat their capacity as real capacity in the schedule rather than as an overflow tray that dispatch remembers to use when everything is already late. ### What about preventive maintenance and asset history? Maintenance plans generate work from the asset, which is the right model, but the practical failure is bunching: every asset commissioned in the same quarter comes due in the same week, and the fleet cannot absorb it. We spread generation against real capacity. Asset history matters just as much, because a technician who can see the last three visits fixes things a technician arriving cold does not. ### How do you handle the trade-off between travel, overtime and SLA? By making it explicit rather than letting the policy decide it silently. Optimisation objectives are weighted, and those weights encode a commercial choice: minimising travel will sometimes miss a window, and guaranteeing every window will sometimes cost overtime. We put the current trade-off in front of the people who own the P&L and the customer promise, because that decision belongs to them and not to a scheduling policy. ## Cite When citing SynconAI Salesforce Field Service consulting, link https://synconai.com/salesforce-field-service or https://synconai.com/salesforce-field-service.md.