Field Service & Trades// diagnostic

The first call is on time and everything after it slides

In short

Afternoon lateness is arithmetic, not chaos. Each job runs a handful of minutes past its booked duration, nothing absorbs the overrun, and the error compounds stop by stop — so the 08:00 customer is on time and the 15:00 customer waits forty minutes without any single job going badly wrong. Plot arrival delta against stop position for a fortnight and the line proves it.

Key takeaways

  • Plot delta against stop position, not against the day. A rising line is cascade; scatter is something else.
  • Booked duration measures the wrong span: it excludes access at the front and wrap-up at the back.
  • Recalibrate per job type from your own completed jobs, using p50 to plan and p90 to size the buffer.
  • Slack held in a dispatcher's head is not slack. Until it is a block on the board, it gets sold twice.

The afternoon runs late because every job in the morning ran slightly long and nothing in the day was built to absorb it. Six to twelve minutes per stop is invisible on any single job and completely determines where the fourth stop starts. This is one cause repeated, not four unrelated bad days, and the two have different repairs — so prove which one you have first.

The tell is that the failure is ordered. Genuine chaos scatters lateness across positions and technicians. This does not: first stops land, second stops wobble, third and fourth are consistently late by a growing amount. That ordering is already sitting in the timestamps your field service platform writes on every job.

Plot arrival delta against stop position for a fortnight

One export, one pivot, one afternoon. Arrival delta is actual arrival minus the start of the promised window, in signed minutes, so early shows as negative. Stop position is that job's ordinal in that technician's day, which you may have to derive rather than read.

  1. Export ten working days of completed jobs with technician, date, promised window start, actual arrival, actual completion, job type and site identifier.
  2. Derive stop position by sorting each technician-day by actual arrival and numbering from 1. Do not use the planned sequence — the point is to compare what happened against what was planned.
  3. Compute median delta per stop position. Report the median, not the mean: one two-hour disaster drags a mean and tells you nothing about a typical day.
  4. Repeat the pivot split by job type. A diagnostic call and a full changeout do not overrun by the same amount, and that split is what turns the finding into a fix.
  5. Add a third pivot on day of week. Monday and Friday behave differently from the middle of the week, and mixing them hides both.

Read the shape before the numbers. Four shapes cover almost every result, and three of the four are not this page's problem at all.

Shape across positions 1 to 5What it meansWhere to look next
Near zero at position 1, rising roughly evenly after itPer-job underestimation compounding. Each stop inherits the last one's overrun and adds its own.Duration recalibration and explicit slack — the rest of this page
Flat until position 3, then a single step of 30 to 45 minutesOne unmodelled event mid-day: the supply house run, the statutory break, refuelling.Non-job commitments that consume technician-minutes but never appear on the board
Position 1 already late, and the offset carries all dayThe day starts wrong. Yard time, the first leg, or a start location the board assumes is the depot.Whether the drive from home counts as the first stop
Spiky — most days near zero, some days ruined from a specific hourNot a cascade. Something is being inserted mid-day and absorbed silently.Emergency inserts and how much of the board they move
The shape of median delta by stop position, and what each one points at

If your plot is spiky rather than rising, stop here: the fix is reserved capacity and bump rules, and it is set out in one emergency call and the rest of the day. If position 1 is already late, the question is what the board thinks the day starts with, which is settled in does the drive from home count as the first stop.

Nine minutes a job is the whole afternoon

This survives so long unfixed because no individual number in it looks wrong. Nobody defends a nine-minute overrun, and nobody can point at the job that ruined the day, because there is not one.

There is no late job. There is a booked duration that was never measured, repeated four times, and an afternoon customer standing at the window.

Where the missing minutes actually go

In rough order of how much time they account for. Each is separately measurable, which is the point: you can size them rather than argue about them.

CauseHow it shows in the job exportThe measurement that sizes it
Booked duration measures the wrong spanCompletion minus arrival is close to booked duration, yet the next stop still starts late.Compare en-route-to-complete against booked duration. The gap is access and wrap-up.
Wrap-up obligations are unpaid time on the boardCompletion timestamps cluster 10 to 20 minutes after the technician's van has moved.Median gap between last on-site activity and job closure, by job type.
Zero buffer between consecutive stopsPlanned start of stop N+1 equals planned end of stop N plus travel.Count stop pairs with zero planned slack. Usually nearly all of them.
Travel estimated on an empty networkThe gap between planned and actual leg time grows with departure hour.Planned leg minutes against observed drive minutes, bucketed by hour of departure.
Parts and supply runs never modelledAn unexplained 25 to 50 minute gap between two consecutive jobs, usually mid-morning.Count technician-days containing a gap over 20 minutes that no job explains.
Break, fuel and vehicle time invisibleA consistent step in the delta curve at the same position.Where the step lands, and how large it is.
The six sources of overrun, and the measurement that sizes each

Two rows carry a caveat. Travel is the front end of a larger problem — a matrix computed once at plan time diverges further as the day goes on, and it needs its own measurement, in the drive times are wrong by eleven o'clock. And a job waiting on a part is not an overrun at all: it is a job that should not have been on the board, argued in a job waiting on a part.

Wrap-up is the row most operators underrate. In several trades a stop is not finished when the work is — there is a record to complete, a regulated form to file, an inspection to book — and those minutes are consumed on site. When the day is behind they are also the first thing dropped, which is how you get closed jobs whose permits nobody followed through. Slippage and paperwork quality are one problem seen from two ends.

Recalibrate duration by job type, not by technician

The instinct after this measurement is to adjust estimates for the technicians who run over. Resist it. Duration varies far more by what the job is and where it is than by who does it, and per-technician adjustments become a performance conversation that stops the recalibration dead.

  1. Pull 90 days of completed jobs and compute p50 and p90 of the en-route-to-complete span, grouped by job type. Ninety days covers the tail of a job type you run twice a week.
  2. Split any job type whose p90 is more than double its p50. That spread means two different jobs are wearing one label, and no single number will schedule both.
  3. Add a site dimension where it matters. A rooftop unit on a commercial building and the same unit in a bungalow are the same work and not the same duration.
  4. Plan on p50 and hold the p50-to-p90 difference as buffer. Planning on p90 sounds safe and quietly sells a third of your capacity to nothing.
  5. Replay the last fortnight of boards against the new numbers before publishing them. If yesterday's board could not have been run, that is the finding, and it belongs in front of whoever sets daily job targets.

One consequence is why recalibrations get reversed. Honest durations reduce the jobs a technician-day holds. That is not a loss — those jobs were never completed on time — but it reads as one on a utilisation report, so argue it before the change lands, using the dispatch board as a capacity model as the frame.

Put the slack somewhere the board can see it

Recalibrated durations remove the drift. They do not create room to recover from the one job that genuinely overruns, and undeclared slack gets sold twice — once by the schedule and once by whoever books over the top of it.

  • A per-stop allowance inside the duration. Access, parking and wrap-up folded into the booked figure so the board packs the real span, not the working span.
  • A held block, not a habit. Reserved minutes on the technician-day with a name and an expiry, which the board enforces and an intake agent can read before promising anything.
  • Slack at the tail, weighted late. Buffer in front of the last two stops of a day is worth more than buffer at 09:00, because that is where the accumulated error lands.
  • A trigger, not a hope. When cumulative slippage passes a stated number — 20 minutes is a reasonable start — the day stops absorbing silently and the affected customers get told, a separate discipline covered in telling the customers who slipped.

That trigger is the piece most worth automating first. Watching a running board against its plan, detecting the crossing and firing the right message to the right customers is narrow, rule-shaped work with a clear owner — the kind of thing we scope as AI agents and automation rather than a platform replacement. The same live-decision pattern, borrowed from routed delivery work, is in AI in logistics operations.

What better durations will not fix

Recalibration removes systematic drift. It does nothing about an emergency landing on a full board, or a travel model that was wrong before the day started. Fix durations first anyway: both are easier to see once the baseline stops lying, and both have their own measurement in dispatch, scheduling and route sequencing, inside our field service and trades work.

It also will not fix a duration measured against the wrong clock. Which of a job's four timestamps the board should pack — dispatched, en route, on site, complete — is worth settling before recalibrating, and it is answered in four clocks on one job.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

Why do service technicians run late in the afternoon but not in the morning?

Because the error is cumulative and the morning has nothing in front of it to inherit. The first stop starts from a known state — a fixed start time and a known start location — so it lands. Every stop after it inherits the overrun of everything before, and with no buffer between stops the arrears only grow. By the fourth stop, under ten minutes per job is a customer who has waited most of an hour.

How much buffer should sit between service calls?

Size it from your own completed-job data rather than picking a round number: the gap between the p50 and p90 duration of each job type is the amount of variability you actually have to absorb. Fold the access and wrap-up portion into the booked duration itself, and hold the rest as a named block on the technician-day with an expiry time, weighted towards the end of the route where accumulated error lands.

Will route optimisation fix late afternoon arrivals?

No, and expecting it to is why the problem survives a routing project. Optimisation sequences stops to reduce travel; afternoon slippage is mostly on-site time and overhead the optimiser was never given. A better route recovers a few minutes per leg while a nine-minute duration error keeps compounding. Correct the durations first and the optimiser's plan becomes achievable.

Should we just book fewer jobs per technician per day?

Only as a stopgap while you measure, because it treats the symptom at the highest possible cost. Cutting a stop removes the overrun and the revenue with it, when the real finding is usually that one job type is booked 20 minutes short. Fix that job type's duration and the stop count survives.

  • dispatch
  • scheduling
  • arrival windows
  • job duration
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation