Operated function · dispatch
The commonest reasons a job does not complete are decided long before anybody drives anywhere: the fault was described wrong, the access requirement was not asked about, or it was always a two-person job booked as one. Sequencing a day of those more efficiently produces a more efficient failure.
A job is booked from a description given by somebody who is not a technician, over the phone or through a form, about a problem they can see but cannot diagnose. What gets recorded is their words, and their words determine which engineer goes, with which parts, for how long.
The day is sequenced the night before or that morning, usually by an experienced dispatcher who knows the patch, knows which engineers are quick, and knows which customers need a call ahead. That knowledge is genuine skill and it is entirely undocumented.
Then reality intervenes. A job overruns, an engineer calls in, a customer is not there, an emergency arrives that has to be inserted. Every insertion cascades, and the resequencing is done under pressure while three other things are also happening.
A visit fails. The reasons are consistent across the industry and mostly not about routing: the wrong part, no access, the job needed two people, the fault was different from the description, or the customer was not in during a window that was too wide to plan a day around.
And the customer experience is the arrival window. A window wide enough to be safe for you is wide enough to cost them a day, and narrowing it without changing anything else simply converts one failure mode into another.
Whether a visit can succeed is largely fixed by what was captured when the job was booked, and the effort goes into sequencing jobs whose success was already determined by a description nobody validated.
That is why routing investments disappoint so consistently in field service. They optimise the part that is measurable and downstream, and leave the upstream cause untouched — a perfectly sequenced day of under-specified jobs still fails at the same rate.
The upstream fix is a booking conversation that asks the questions the failure data says matter. Not a longer form: a conditional one, where the answer to a symptom question determines which access, parts and duration questions get asked. That is bounded rules work, and it is what turns a customer’s description into a specification.
The failure data has to exist first, and usually it does not in a countable form. Recording why a visit did not complete — against a written list your own field managers wrote — is the cheapest thing on this page and it is what makes every subsequent decision evidence-based rather than anecdotal.
Sequencing is genuinely delegable once the jobs are well-specified, including the resequencing that follows every disruption. It is high-frequency, it is exactly the work that competes with everything else during a busy morning, and getting it wrong costs a van on a motorway.
The arrival window then becomes a function of confidence rather than of caution. A job whose duration is well-specified can carry a narrower window honestly, and one that is not should not.
What is not delegated is the safety judgement. Whether a job is safe to attempt alone, whether a site requires a specific competence, and whether an engineer should refuse a task belongs to your field leadership and to the engineer on site.
Visits that fail, by recorded cause — measured by incomplete visits classified against your written reason list, from a baseline where the reason was free text or absent.
Failures attributable to specification rather than routing — measured by the share caused by wrong part, no access or wrong sizing — usually the majority, and usually a surprise.
Jobs whose specification survived contact with the site — measured by visits where the job matched its description, before and after conditional booking questions.
Productive hours against travel hours — measured by on-site time as a share of the working day, per engineer, on comparable job mixes.
Return visits, and their true cost — measured by second visits linked to the original job rather than booked as new, which is how the first failure becomes visible.
Arrival window width — measured by window offered against actual arrival variance, so a narrower window is earned rather than promised.
any safety, competence or fitness-to-work judgement, and no instruction to an engineer about how to perform a task. Nothing here decides whether a job can be attempted alone, whether a site is safe, or whether somebody is qualified for it. Those belong to your field leadership and to the person standing there, whose refusal is always final.
Jobs, engineers and schedules stay in your field service management system. Nothing migrates and no second schedule exists — two versions of where an engineer is going is how two customers get told the same slot.
The specification rules and the failure-reason list are yours: written by your field managers, versioned, owned. They encode what your engineers actually need to know before they travel, and no vendor can supply that.
Parts availability is read from your stock system where one exists, because a specification that requires a part nobody has produces a failure the routing cannot prevent.
Nothing overrides an engineer. A schedule is a plan, and a person on site who judges a job unsafe, out of their competence, or different from its description is right by definition — the schedule adapts, and the outcome is recorded rather than argued with.
Working-time and rest rules are constraints on the schedule rather than preferences it optimises against. A sequencing operation measured only on utilisation will produce a day that breaks them, which is why the constraint is set by you and cannot be traded.
Every assignment and resequence carries a receipt: what changed, why, and when. An engineer whose day was rearranged three times can see why, and a customer who was moved can be given a straight answer.
Operational access is not permission to train. Customer address and job data, and your engineers’ working patterns, do not become material improving anything serving another organisation.
Health and safety owns the boundary, and it is short: nothing here judges whether a job is safe or whether somebody is competent to do it, and an engineer’s refusal is final. That needs to be written rather than implied.
Employee representation should see how the schedule treats working time, breaks and travel. A sequencing operation is a change to how people’s days are constructed, and it will be experienced that way whether or not it is framed that way.
Where an obligation attaches through working-time regulation, a collective agreement or a licensing requirement, it is marked applicability-gated rather than presented as standing.
One region or job type over one trailing period — read-only, with no schedule changed — classifying every incomplete visit against a reason list your field managers write.
The first phase changes no schedule. It establishes why visits actually fail, in countable form, which most field operations cannot currently produce because the reason is free text or absent.
The result usually reallocates the whole problem. Where most failures are parts, access and sizing, the fix is at booking and it is available immediately — a conditional question set, built from your own failure data, deployed on your existing booking channel with no dispatch change at all.
Sequencing comes later and only if the specification work has already landed, because sequencing well-specified jobs is worth doing and sequencing badly-specified ones is not.
Then travel is probably not your constraint, and the first phase will confirm it cheaply. The question routing cannot answer is what share of your incomplete visits were caused by the wrong part, no access or wrong sizing — all decided at booking, none improved by sequencing. If your failure data already shows routing is the dominant cause, this is not for you.
They do, and that is the exposure as much as the strength — it is undocumented and it is unavailable when they are. The more useful early target is not replacing their sequencing but capturing the specification questions they already know to ask, which is the part currently absent from the booking channel entirely. Where a dispatcher’s sequencing outperforms, the honest scope is the booking end.
They would for customers and they are only honest if job duration is well-specified. Narrowing a window over jobs whose sizing is unreliable converts a wide-window complaint into a missed-window complaint, which is worse. The sequence matters: specify first, measure actual variance, then narrow the window by as much as the variance supports.
They will if the schedule cannot be overridden, so it can be — an engineer on site who judges a job unsafe, out of competence or different from its description is right by definition, and the outcome is recorded rather than challenged. Working time and rest are hard constraints rather than things a utilisation target trades against. If the scope as written does not obviously mean fewer wasted journeys and fewer jobs they cannot complete, it should be rewritten before it is presented to them.