Delivery routing optimises visits where the work is largely identical. Field service scheduling optimises visits where the work is different at every stop, takes an uncertain amount of time, requires specific skills and specific parts, and may not be completed on the first attempt.
Buying delivery routing software for field service work is a common and expensive mistake.
The additional constraints
| Constraint | Delivery | Field service |
|---|---|---|
| Job duration | Fairly predictable | Highly variable, sometimes unknown |
| Skills required | Driving licence | Specific certifications and experience |
| Parts | Loaded from an order | May be needed and unknown in advance |
| Completion | Almost always first visit | First-time fix rate is a key metric |
| Customer presence | Sometimes required | Almost always required |
| Follow-up work | Rare | Common — return visits, escalations |
| Job value variation | Low | Very high |
| Priority | Time windows | Contractual SLAs and severity |
Skills matching
The core distinguishing capability. The scheduler must know:
- Which technicians hold which certifications, and when they expire
- Which equipment types each is competent on
- Which are approved for specific customer sites or security clearances
- Experience levels, where a complex job needs a senior engineer
- Language requirements for particular customers
- Territorial familiarity, where it materially affects duration
Then it must trade skill fit against travel: sending the perfectly qualified engineer 90 minutes across a region when a competent local engineer is 10 minutes away is a common and expensive scheduling failure.
Good systems express this as a cost function rather than a hard constraint, so the trade-off is explicit and tunable.
Duration uncertainty
Delivery service times cluster; field service durations do not. A "boiler service" may be 40 minutes or four hours depending on what is found.
Approaches that work:
- Duration distributions rather than point estimates, planning to a percentile rather than a mean.
- Job type plus asset history: this customer's equipment has needed extended work before.
- Deliberate buffer placement, with slack distributed across the day rather than concentrated at the end.
- Dynamic re-planning when a job overruns, since the rest of the day is now wrong.
- Emergency capacity held deliberately rather than assumed.
Parts and first-time fix
First-time fix rate is the dominant economic metric in field service. Each return visit costs a full visit and damages customer satisfaction.
Software support required:
- Van stock visibility — what each technician carries.
- Parts prediction from job type and asset history.
- Parts reservation at scheduling time, not at dispatch.
- Inter-technician transfers and depot collection scheduling.
- Return-visit scheduling that carries forward the diagnosis and required parts.
The link between scheduling and inventory is what separates field service management products from routing tools with a job field.
SLA and priority handling
Field service work is usually governed by contractual response and fix times, varying by customer and severity.
The scheduler needs to:
- Understand contractual response clocks and their start conditions
- Prioritise by breach risk rather than by simple urgency flags
- Show the cost of accepting a new emergency — which existing jobs are displaced
- Support deliberate SLA breach where the alternative is worse, with a recorded decision
- Report on SLA attainment by contract
Dispatch models
Fully automated. The system assigns and sequences; dispatchers manage exceptions. Suits high volumes of similar jobs.
Assisted. The system proposes; a dispatcher confirms. The most common model in complex environments and usually the right starting point.
Territory-based with self-scheduling. Technicians manage their own day within a territory. Works with experienced teams and predictable work; scales poorly.
Real-time dynamic. Continuous reoptimisation as jobs are completed and raised. Powerful for emergency-heavy operations, and demanding on data quality and technician acceptance.
Most operations should start assisted and move towards automation as data quality and trust improve.
What to test in a demo
- A job requiring a certification only two technicians hold, one of whom is on leave.
- An emergency arriving at 14:00 that must displace existing work — show me what it displaces and what it costs.
- A job that overruns by two hours — re-plan the remainder of that technician's day.
- A job needing a part that is on another technician's van.
- A return visit that must be assigned to the same engineer.
- A customer site requiring two technicians simultaneously.
Products built for delivery routing typically fail at items 1, 4 and 6.
Frequently asked questions
Can delivery routing software handle field service?
For simple, predictable, single-skill work such as meter reading or standard inspections, sometimes. For anything requiring skills matching, parts or SLA management, it lacks the necessary concepts and you will end up managing the difference manually.
What is a realistic first-time fix rate?
It varies enormously by trade and equipment complexity. What matters is your own trend and the reasons for failures — analyse whether the cause is parts, skills, diagnosis or access, because each has a different fix.
How do we handle jobs with unknown duration?
Schedule a diagnostic visit with a defined duration and treat the repair as a separate, scheduled job. This is more honest to the customer than a schedule built on hope, and it produces far better utilisation data over time.
Should technicians see their whole day or just the next job?
Whole day, in almost all cases. Technicians manage their own pace, travel and breaks better with visibility, and hiding the schedule creates suspicion. Reserve next-job-only for genuinely dynamic dispatch environments where the day changes constantly.
How much slack should a schedule contain?
Enough that a typical overrun does not cascade — commonly a meaningful proportion of the day held as buffer or emergency capacity. The right figure comes from your own duration distributions rather than from a rule of thumb.
