Field Service & Trades// diagnostic

One emergency call and the rest of the day is unrecoverable

In short

One emergency should move one job, not five. When it moves five the cause is rarely the emergency itself: it is a board holding no reserved minutes to absorb it, no written order of who may be bumped, and an insertion rule that chases the shortest detour instead of the least disruption. Counting jobs moved per insert against how full the board was separates those failures in a week.

Key takeaways

  • Blast radius is the measurement: jobs moved per insert, logged against how full the board already was.
  • Reserve minutes per technician-day with a stated expiry, or the first emergency is paid for by four customers.
  • Insert on lowest disruption cost, not shortest detour. The nearest van is often the one with most to lose.
  • Write the bump ladder down. Undeclared, it resolves to whichever customer complains loudest.

A single emergency taking out an afternoon is a board problem, not an emergency problem. Emergencies are predictable in volume even when they are unpredictable in timing, so a day with no minutes held for them is a day that has already spent its recovery budget. Everything after the insert — the five moved jobs, the apology calls, the technician driving back across the same suburb — follows from that and from the absence of a written rule about who gets moved.

Two different faults produce the same complaint, and they need opposite repairs. One is capacity: the board was genuinely full and something had to give. The other is insertion: there was room, and the assignment logic moved four jobs it never needed to touch. Guessing between them costs a quarter. Measuring takes a fortnight.

Count the jobs that moved, not the calls that came in

Emergency volume is the wrong metric and it is the one everybody reports. What matters is what each insert cost. Blast radius is the count of jobs whose planned start moved by more than 15 minutes as a direct consequence of one insertion, recorded at the moment it happens.

  1. Snapshot the board immediately before every emergency assignment: job ids, assigned technician, planned start. Most platforms will not do this on their own, and a small listener writing one row per job is enough.
  2. Snapshot again 30 minutes later and diff the two. Any job whose planned start moved by more than 15 minutes counts, including jobs on other technicians' routes.
  3. Record board fill at the moment of insert — committed minutes divided by available minutes for that day, across the technicians eligible for the job.
  4. Tag each moved job with what it was: promised window, contractual response clock, routine maintenance, already-moved-once. That tagging is what turns a count into an argument about rules.
  5. Run for two weeks, then plot blast radius against board fill. Four points on that chart tell you which fault you have.
Jobs moved per insertBoard fill at insertWhat it points at
0 to 1Under 85%Working as intended. The slack absorbed it and nothing needs building.
0 to 1Over 95%Someone is holding this together manually. It will fail the week they are on leave.
4 or moreUnder 85%An insertion problem. There was room and the logic moved jobs it did not have to.
4 or moreOver 95%A capacity problem. Nothing was held back, so the emergency is funded by promised customers.
Blast radius against board fill, and what each quadrant means

Rising blast radius with a flat emergency count is the clearest signal in the whole exercise: the days are not getting worse, the board is getting tighter. If instead the chart is flat and the afternoon is still late, you are looking at accumulated drift rather than inserts, which is a separate measurement in the first call is on time and everything after it slides.

Minutes held back before the phone rings

Reserved capacity is the single highest-leverage change here, and it is unpopular because it looks like deliberately selling less. It is not: it is refusing to sell the same minutes twice. Size it from arrivals you have already had, not from a feeling about how busy things are.

  • Count, do not guess. Ninety days of emergency arrivals, grouped by weekday and by three-hour band. Take the 80th percentile count per band, not the mean — the mean is a day you never have.
  • Convert count to minutes. Multiply by the median duration of the job type emergencies actually turn out to be, which is usually not the job type the caller described.
  • Hold it per technician-day, not per branch. A branch-level reserve is a number nobody can enforce at the moment of assignment.
  • Give every reserve an expiry and a destination. Unclaimed emergency minutes released to routine work at a stated hour are capacity; unclaimed minutes with no release rule are lost revenue that will get the whole policy cancelled.

Where a reserve cannot be found, the honest outcome is that the job does not go on today's board at all. That is a legitimate answer, but only if the queue it lands in is watched — an unplaced emergency sitting quietly is the failure described in jobs sitting in the unassigned queue.

Who may be bumped, decided before the day starts

Every operation has a bump order. Most have never written it down, so it resolves in the moment to whichever customer is least likely to shout — which correlates poorly with which customer costs least to move. Three tiers are enough.

TierTypical membersThe field the board needs
Never movableA contractual response clock already running, a return visit on the same fault, an appointment the customer took leave for, a booked inspection.Response deadline, revisit flag, fixed-access flag
Movable with a costPriority or membership customers, jobs already moved once, jobs at the end of a long-promised window.Customer tier, bump count, window end time
Freely movableRoutine maintenance with a wide window, internal or yard work, jobs the customer flagged flexible at booking.Flexibility flag captured at intake
A three-tier bump ladder, and what each tier has to encode

Bump count is the field most often missing and the one that prevents the worst outcome. A job moved once is promoted to the middle tier and a job moved twice becomes immovable, which stops the same unlucky customer absorbing every emergency in the week. Commercial response clocks belong in the top tier because breaching one has a defined consequence and disappointing a homeowner does not — an asymmetry the person doing the inserting cannot see unless the board shows it.

The emergency did not break the day. The day held no minutes for one, and no rule about whose afternoon pays when it arrives.

Rank insert positions by disruption, not by detour

Proximity is the default rule almost everywhere, and it is wrong often enough to matter. The nearest technician is frequently the one carrying the most promised windows, so the shortest detour buys ten minutes of driving and spends an hour of somebody else's commitments.

Score each candidate position as added travel minutes plus the sum, over every job it displaces, of minutes moved multiplied by that job's tier weight — with any position that displaces a never-movable job rejected outright rather than penalised. That is a short function, it is explainable to a dispatcher, and it turns the choice into a ranked list rather than a reflex. Note that its first term inherits whatever your travel model believes, so if planned and actual legs diverge as the day goes on, fix that first: the drive times are wrong by eleven o'clock is the prerequisite, not a parallel project.

Who gets the final say is a separate decision, and a real one. A computed ranking that a dispatcher can override with a reason code is usually the right shape, for reasons argued in who assigns the job, the algorithm or the person who knows the customer.

Re-sequence the tail, never the whole day

The most damaging habit is re-solving the entire day after every insert. A global re-optimisation is free to move jobs that had no reason to move, and every one of those moves is a call the office has to make. Freeze everything already dispatched or en route, freeze every job whose customer has been given a window in the last two hours, and re-sequence only the stops after the insertion point on the affected route.

There is a quality cost to a churned tail as well as an operational one. Technicians working a compressed afternoon shorten the wrap-up, and the evidence they capture on the way out is the first casualty — which is how you end up with the situation in the photos are there but they prove nothing. Telling the customers who did move is a separate discipline with its own rules, set out in telling the customers who slipped.

None of this needs a platform replacement. A reserve field with an expiry, a bump tier on the job record, a disruption score and a frozen-window rule are a fortnight of work against the board you already run, which is the shape of engagement we describe under MVP and product builds. It sits with the rest of dispatch, scheduling and route sequencing, inside our field service and trades work.

Frequently asked questions

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

How much capacity should we reserve for emergency calls?

Size it from your own arrival history: count emergencies by weekday and time band over 90 days, take the 80th percentile rather than the mean, and multiply by the median duration those jobs actually turn out to be. Hold that as named minutes per technician-day with a release time, then tune it monthly on two numbers — how often the reserve was claimed, and how often it was released and refilled with routine work.

Why does one emergency job move five other jobs?

Because the insert is placed by proximity and the day has no slack, so the displaced job displaces the next one and the movement propagates down the route. Add a bump rule that only ever moves freely-movable jobs and the chain stops at the first one. The count of jobs moved per insert is worth logging on its own — it is the number that tells you whether the fault is capacity or insertion logic.

Should the dispatcher or the system decide which job gets bumped?

The business decides, in advance, and writes it down as a bump ladder; the system applies it and ranks the options; the dispatcher overrides with a reason code. Leaving the choice entirely to a person makes it unrepeatable and unauditable, and leaving it entirely to software means a customer relationship nobody encoded gets sacrificed. The reason codes are also the fastest route to a better ladder, because they show exactly which rule keeps being wrong.

Is re-optimising the whole day after an emergency a good idea?

No. A full re-solve moves jobs that had no reason to move, and each of those moves is an apology call and a customer who trusts the next promise less. Freeze anything dispatched, en route, or promised in the last couple of hours, and re-sequence only the stops after the insertion point on the affected route. A smaller, worse-looking solution that touches four fewer customers is the better one.

  • dispatch
  • emergency work
  • capacity
  • scheduling rules
// 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