Transforming Field Operations from Scheduling to Mobile Service Delivery

#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.

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.

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.

#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.

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.