# Transforming Field Operations from Scheduling to Mobile Service Delivery > An equipment manufacturer where the schedule was rebuilt by hand every morning, because the optimiser had been fed durations copied from the last job that looked similar. - Source: https://synconai.com/case-studies/field-operations-scheduling-to-mobile-delivery - Publisher: SynconAI (https://synconai.com) - Type: Case study - Evidence: Illustrative scenario. This describes how SynconAI approaches the problem. It is not an account of one named customer, and no outcome is claimed as measured. - Organisation: An equipment manufacturer running installation and planned maintenance through employed technicians and subcontractors - Industry: Manufacturing - Products: Field Service, Service Cloud, Field Service Mobile, Flow - Service: Salesforce Field Service (https://synconai.com/salesforce-field-service) - Reading time: 12 minutes ## In short Field service scheduling fails on data, not on the optimiser. This scenario models work types that make duration and skill predictable, territories and skills built from how dispatch actually happens, subcontractors represented honestly as service resources, and a mobile app designed for offline use in a plant room. Optimisation is switched on last, over inputs the dispatchers already trust. ## Key points - A work type is where duration and skill live. An estimate copied from the last similar job is one noisy sample rather than a duration, and the optimiser cannot tell the difference. - Build skills backwards from the work types, not forwards from the training register. Qualifications describe a person; the schedule needs to know what they can be sent to do today. - Model a subcontractor the way the business actually dispatches them. Naming individuals you neither train nor roster produces a resource list nobody maintains. - Switch optimisation on last. A field team that experiences one confidently wrong schedule remembers it long after the durations have been fixed. ## Demand to completion evidence Work reaches the system from three places: a customer case, a maintenance plan running against an installed asset, and an installation commitment made at the point of sale. Each becomes a work order, and the work type attached to it supplies the estimated duration and the required skills, which is what turns a job into a schedulable service appointment. Scheduling then reads that appointment against service territories, operating hours, resource absence and a scheduling policy, and optimisation orders the day within those constraints. Dispatch lands the appointment on a service resource in a territory, whether that resource is an employed technician or a named subcontractor. The technician then works from Field Service Mobile with the asset history and instructions already on the device, because there is frequently no signal where the equipment lives. Completion evidence flows back the other way: parts consumed, photographs, readings and status update the asset record, close the entitlement position and release the job for invoicing, which is also what makes the next duration estimate better than the last one. ### 1. Demand - Case - Maintenance plan - Asset - Entitlement - Work order Reactive, planned and installation work all become work orders, so one model schedules all three. ### 2. Definition - Work type - Estimated duration - Required skills - Service appointment The work type is what makes a job schedulable. Without it there is nothing for the optimiser to reason about. ### 3. Scheduling - Scheduling policy - Service territory - Operating hours - Resource absence - Optimisation Constraints first, preferences second. Optimisation orders the day, it does not invent missing facts. ### 4. Dispatch - Service resource - Skills - Territory membership - Subcontractor capacity Employed technicians and contracted firms sit in the same model but carry different guarantees. ### 5. Mobile execution - Field Service Mobile - Offline record set - Asset history - Parts consumed Built for a plant room with no signal, not for the demonstration on office wi-fi. ### 6. Completion evidence - Work order line items - Photographs and readings - Asset update - Invoice trigger What the technician records is what the next duration estimate learns from. ## The problem, as it actually presented The brief in this situation is almost never "our data is wrong". It is "the schedule does not work", and increasingly it is "we turned optimisation on and it made things worse". Trace it back and the same shape appears. Installation and planned maintenance are dispatched by two people who hold the plan in their heads and on a whiteboard that gets photographed at the end of each day. Duration comes from whatever the last similar job took, adjusted by whoever is typing. Skills exist as a list of names in a spreadsheet the HR team maintains for training records, and nobody has mapped that list to the work anyone is actually sent to do. Territories are drawn around depots, some of which closed years ago. Subcontractors are booked by phone and appear in the system, if at all, as a note on the work order. Then someone turns on optimisation, and it does exactly what it was told. It packs the day using the durations it was given, in the territories it was given, against the skills it was given. Every one of those inputs is partly fiction, so the output is confident nonsense produced faster than a human dispatcher could produce it. The technicians notice inside a week and start working around the schedule, which is the point at which the programme is in real trouble, because trust is much harder to rebuild than a data model. ::: warn The tell is not a metric. It is a dispatcher who overrides the optimised schedule every morning before anyone else sees it. That override is a manual correction for facts the system does not hold, and like every heroic workaround it hides the gap rather than closing it. ::: The second thing worth noticing early is that the field is where all of this becomes visible. A form designed at a desk gets filled in by a technician standing in a plant room with no signal, wearing gloves, holding a torch. Whatever the design assumed about typing, scrolling and photography is tested there, and the honest answer is usually that it assumed too much. ## What we designed, and why ### Work types are the unit that makes work predictable The highest-value decision in a field programme is to define work types properly, and to define them before anything else is configured. A work type carries the estimated duration, the required skills, the entitlement behaviour and the shape of the mobile experience for that kind of job. It is the object that turns "somebody needs to go and do something" into a schedulable service appointment with known demands. Everything the scheduling engine does rests on it. The hard part is duration. An estimate copied from the last job is not a duration, it is a single sample carrying all of that job's noise: the morning the technician waited for a site induction, the afternoon the plant was already shut down, the visit where the customer wanted a long conversation. What the schedule needs is a duration describing the work the work type describes, with the variability that belongs elsewhere moved elsewhere. In practice that means splitting work types further than the business first wants to. An annual service is not one work type if the annual service on a rooftop unit and the annual service on a basement unit differ by an hour of access. Access, asset model and site conditions are legitimate reasons to split. Customer name is not. ::: tip A useful test: if two jobs sharing a work type would sensibly be given different durations by an experienced planner, the work type is not finished. Either split it, or move the difference onto something the schedule can read, such as the service territory or the asset. ::: ### Skills and territories modelled on how dispatch actually happens Skills are where field programmes go quietly wrong, because there is always an existing list and it is almost always the wrong list. A training register describes qualifications held by a person. The schedule needs to know what someone is permitted and competent to be sent to do on a specific work type. Those overlap without being the same thing, and the register is usually at the wrong granularity in both directions: too coarse to match against work, too fine to maintain. So we build the skill set backwards from the work types. Every skill exists because at least one work type requires it, and a skill no work type requires does not get created. Territories are the same argument expressed in geography. A service territory should describe how the business dispatches, not how it reports. Sales regions and finance regions were drawn for other reasons and get inherited into field service simply because they were already there. If the real dispatch question is who is near enough today, then boundaries need to reflect travel reality, and the operating hours on the territory need to be the hours people actually work, including the site that only accepts visits before nine in the morning. Resource absence is the piece nobody budgets for and everybody needs. If leave, training days and vehicle servicing do not reach the system, the schedule will book someone who is not there, and the field team will conclude, correctly, that the system does not know what is going on. It is a small integration and it is not optional. ### Subcontractors who are not employees Most businesses of this shape run a mix: employed technicians for the core, contracted firms for overflow, distant geography or specialist work. The design has to represent that mix honestly rather than pretend everyone is on the payroll. A subcontractor is a service resource with genuinely different properties. Capacity is influenced rather than controlled. Operating hours are negotiated rather than set. Skills were trained by somebody else and cannot be verified from your own records. And an assignment is a request with commercial weight behind it, not an instruction. Where the business dispatches named individuals from a contracted firm, those people belong in the model as service resources with their own skills and operating hours, because that is what is really happening. Where the business hands a block of work to a firm and the firm decides who goes, modelling individuals is fiction that will not survive contact with staff turnover. That distinction is a commercial question rather than a technical one, and it is settled per contractor rather than as a blanket policy. Getting it wrong in the generous direction, modelling everyone individually, produces a resource list nobody updates and skills nobody trusts, which is precisely the failure the whole design exists to prevent. ### The mobile app as it is actually used Field Service Mobile is used offline, in a plant room, by someone wearing gloves. That sentence deserves to be pinned above the design work, because it invalidates a great deal of otherwise reasonable form design. Offline is the constraint that shapes everything else. If a step depends on a live lookup, it fails at exactly the moment it matters. So the record set the technician needs, the asset and its history, the work type instructions, the entitlement position, the parts expected, has to be on the device before they arrive rather than fetched when they get there. What a form can reasonably ask changes too. Free text is expensive when typing is hard, so the fields that survive are the ones answerable by tapping. Photographs are cheap and carry far more evidence than a paragraph, so completion evidence leans on them heavily. Long picklists that scroll comfortably on a desk monitor are miserable on a phone held in one gloved hand. And a form that asks the same question twice, once for the technician and once for the back office, gets answered accurately once. The rule we apply is that every field on a mobile flow must be consumed by something downstream: an invoice, a compliance record, a warranty claim, the next maintenance plan. Fields that exist because somebody once wanted to know get removed, because their cost is paid in the plant room by the person least able to afford it. ### Parts and van stock, where the design meets reality This is where an otherwise sound scheduling design meets the physical world and frequently loses. A schedule that quietly assumes the part is on the van is a schedule that produces return visits. A return visit costs the travel, the appointment slot, the customer relationship and the schedule integrity the optimiser was trying to protect in the first place. So the design has to answer three questions honestly. What is on each van, and how accurately is that actually known. What does each work type typically consume. And what happens when a technician uses something nobody expected, because that third case decides whether the stock picture is still trustworthy in month three. The answer is rarely a perfect inventory. It is more often a deliberate decision about which parts are worth tracking accurately, usually the high value and the high frequency, plus a consumption step at completion simple enough that it genuinely gets done. A precise stock model that has been abandoned is worse than a coarse one that is maintained, because the schedule will trust it either way. ## Scheduling policy and what optimisation can and cannot fix A scheduling policy is where the business states its priorities: how it weighs travel against response time, whether preferred resources matter, which boundaries are hard and which are preferences. It is worth being blunt about the limits. A scheduling policy can express a trade-off between competing good outcomes. It cannot invent information the system does not hold. If durations are wrong, no weighting repairs them. If a skill is missing from a resource, no policy conjures it. If absences are not recorded, no rule stops the schedule booking someone who is on leave. We usually end up with more than one policy, because the business genuinely operates in more than one mode. Overnight scheduling of planned maintenance is a different problem from an emergency at eleven in the morning where response time dominates everything else. Those deserve separate policies rather than one compromise that serves neither well. The harder point is about trust. Optimisation is not adopted because it produces mathematically better schedules. It is adopted when dispatchers stop needing to correct it, and that only happens once the inputs are right. Turning it on early to demonstrate progress is the most reliable way to lose the field team, because they experience the bad schedule and remember it long after the data has been fixed. ## Implementation The sequence matters more than the components. **Work types first, before anything is configured.** This is a facilitated argument with the people who do the work, not a requirements workshop. Duration estimates get challenged against what actually happened, and the splitting decisions are settled here. Everything downstream is cheap once this is agreed and expensive to revisit afterwards. **Then resources, skills, territories and operating hours,** built backwards from those work types. Then absence, because a resource model without absence is not a resource model. **Then dispatch with scheduling assistance but without optimisation.** Dispatchers schedule against the system, see the candidates it proposes, and reject them out loud. Every rejection is a defect report about the underlying data, and this phase surfaces more genuine correction than any amount of analysis done in advance. **Then mobile, with the technicians who will use it,** tested in the conditions it will be used in rather than in a meeting room. Offline behaviour is an acceptance criterion, not a hardening task for later. **Then optimisation, last,** and only once the schedule it produces is already close to what the dispatchers would have built themselves. ::: note We deliberately do not automate the assignment of emergency work in the first phase. When response time matters and the customer is on the phone, a dispatcher making the call with full visibility beats a rule that has to anticipate every situation. Some things should stay manual on purpose, and this is one that often stays manual permanently. ::: ## The decisions that were contested **Splitting work types further than the business wanted.** More work types means more to maintain, and the operations team argued for fewer. What settled it was that a work type is where duration lives, so a single type spanning jobs of visibly different length guarantees the schedule is wrong for both of them. **Not modelling every subcontractor individually.** The tidier design puts everybody in the resource model. For the firms that allocate their own people we argued against it, because maintaining skills and operating hours for staff employed by someone else is a commitment nobody was realistically going to keep. **Taking fields out of the mobile flow.** Every field had a requester and a reason. The rule applied was that a field survives only if something downstream consumes it, and several did not survive. Those conversations were not comfortable, and they were worth having. **Delaying optimisation.** There was real pressure to switch it on early, because it is the visible part of the investment and the part the board heard about. We argued to wait until durations had been through a cycle of real jobs, on the grounds that a bad first impression with the field team is expensive and slow to repair. ## What changes The outcomes worth claiming from this design are operational, and they follow from the decisions rather than from effort. | Before | After | What made the difference | | --- | --- | --- | | Duration copied from the last job that looked similar | Duration held on the work type and argued from real jobs | Work types split where access and asset model genuinely differ | | Skills taken from the training register | Skills built backwards from what work types require | Qualifications describe a person, the schedule needs task competence | | Territories inherited from sales regions | Territories drawn on how dispatch actually happens | Travel reality and real operating hours treated as scheduling data | | Absence known informally by the dispatcher | Resource absence recorded where the schedule reads it | A small integration nobody had budgeted for | | Subcontractors booked by phone, invisible to the schedule | Contractors modelled as service resources where they are dispatched individually | The modelling decision made per contractor, not as a policy | | Mobile forms designed at a desk | Forms answerable offline, by tapping, with gloves on | Every field traced to something downstream that consumes it | | Optimisation running over unverified inputs | Optimisation switched on last, over inputs dispatchers trust | Sequencing, rather than a better scheduling policy | The second-order effect is the one operations leaders notice. When the schedule is built from durations the technicians helped set, the morning conversation stops being an argument about the plan and becomes an exception list. That is a smaller conversation, and it is the one that scales. ## What we would tell you before starting If your schedule is not trusted, do not start with the optimiser. Start with work types, get durations argued out with the people who do the work, and expect that to take longer than the configuration. Every programme of this shape that goes badly goes badly there, and no amount of scheduling policy tuning recovers it afterwards. And be honest about whether Field Service is heavier than the business needs. It is a substantial platform with a real maintenance cost, and it earns that cost when there are enough resources, enough geography, enough skill variation and enough parts complexity that no single person can hold the day in their head. A handful of technicians covering one city, all of whom can do all of the work, do not need optimisation and may not need Field Service at all. Work orders on Service Cloud with a shared calendar stay the right answer for longer than most roadmaps assume. Recognising that you are not there yet is a better outcome than a platform the field team quietly refuses to use. ## Questions ### Do we need Field Service, or will work orders on Service Cloud do? It depends on whether coordination is genuinely hard. Field Service earns its cost when there are enough resources, enough geography, enough skill variation and enough parts complexity that a person can no longer hold the day in their head. If a handful of technicians cover one city and all of them can do all of the work, work orders on Service Cloud with a shared calendar are honestly enough, and the heavier platform will sit unused. ### How long before we can turn optimisation on? Later than the plan usually says, and the gate is data rather than elapsed time. We want durations that have been through a cycle of real jobs, skills that match the work types, territories with the operating hours people actually work, and absences reaching the system reliably. Until those hold, optimisation produces a schedule that is wrong faster than a human could be wrong, which is the worst possible first impression with the field team. ### Our technicians already resist the current system. Does mobile make that worse? It makes it worse if you add fields without removing any. The discipline is that every field on a mobile flow has to be consumed by something downstream: an invoice, a compliance record, a warranty claim, a maintenance plan. Anything that exists because somebody once wanted to know gets removed, because the cost of it is paid in a plant room by the person least able to afford the extra minute. --- SynconAI. https://synconai.com/case-studies/field-operations-scheduling-to-mobile-delivery