Field Service & Trades// definition

Dispatched, en route, on site, complete: four clocks, one job

In short

A service call carries 4 timestamps — dispatched, en route, on site, complete — and the durations between them are not interchangeable. The board has to pack the span from arrival to release, because that is what occupies the technician. Most boards pack wrench time, which excludes access at the front and wrap-up at the back, so every estimate is short by the same amount.

Key takeaways

  • 4 timestamps produce 5 durations, and only 1 of them is what the board should be booking.
  • Pack arrival-to-release. Wrench time excludes access at the front and wrap-up at the back.
  • Access and wrap-up stay invisible because no 5th mark records when work actually started.
  • Travel is an edge between 2 stops, not a property of either. It belongs to the route model.
  • A timestamp set by a geofence measures the van, not the technician.

Every service call carries 4 timestamps, routinely treated as one number. Dispatched is when the job is assigned and released to a technician; en route is when they start travelling; on site is when they arrive; complete is when they close it. The scheduler has to pack the span from on site to complete — arrival to release — and most schedulers pack something shorter.

That choice is why estimates are wrong in 1 direction. Wrench time — the span a technician would call doing the job — sits inside arrival-to-release with unbooked minutes on both sides: parking, access and finding the equipment at the front, paperwork and the customer conversation at the back. Book the inner span and the day is short by the outer minutes, every stop.

What each mark means, and what usually sets it

TimestampWhat it meansWhat normally sets itHow it lies
DispatchedAssigned to a named technician and visibleThe dispatcher, or an auto-assign ruleStamped at board-build time, so it describes the board
En routeTravel to this stop has begunA tap in the technician app, or a geofence exitTapped at the kerb after 10 minutes of van packing
On siteThe technician is at the service addressA tap, or geofence entry on a wide radiusFires while the van is still looking for parking
CompleteThe job is closed and the technician releasedA tap after paperwork, or an end-of-day batch closeRecorded at 17:40 for a job that ended at 14:15
The 4 timestamps, their usual source, and how each goes wrong

The 5th mark that would make this legible — work started — almost never exists. Without it access hides inside the job, and a slow site cannot be told from a slow job.

The five spans, and who owns each

  • Travel, en route to on site. A property of the pair of stops rather than either one, so it belongs to the route model — and it degrades through the day, for reasons in why the drive times are wrong by eleven o'clock.
  • Access, on site to work started. Parking, gates, reception, lifts, locating the unit, and the 6 minutes of conversation before anyone looks at the equipment. A property of the site, not the job type, and it repeats every visit.
  • Wrench time. The work itself, and the only span most estimates are built from. It also varies least, which is why estimating from it feels accurate and schedules badly.
  • Wrap-up, work finished to complete. The record, photographs, the customer walkthrough, payment or quote, and in several trades a regulated entry such as refrigerant added and recovered, recorded per appliance. Consumed on site whether or not the board booked it.
  • The gap after release, complete to next en route. Notes, restocking, a supply run, a break. Real technician-minutes belonging to no job, so no job accounts for them.

Book arrival to release, and hold travel separately

The rule is 1 sentence: the board books the span in which the technician cannot be anywhere else, and holds travel as an edge between consecutive stops. Arrival to release is that span, and it is the only one the customer experiences, which makes it the honest basis for a promised window.

Two consequences follow, both commercial. Honest durations reduce the stops a technician-day holds, which reads as a capacity cut even though those stops were never completed on time. And durations belong to the job type and the site, not the person — who may attend is a separate model, in what a skill matrix has to know before it can pick a technician.

Getting the real spans out of the history you already have

  1. Export 90 days of completed jobs with all 4 timestamps, job type, site and technician. That covers the tail of a job type you run twice a week.
  2. Compute arrival-to-release per job, take the median per job type, and compare it with the booked duration in the picker. The difference is your standing shortfall, and it is 1-sided.
  3. Approximate the missing work-started mark with the first work event the system does record — a photo, a part scanned, a form opened. The gap from on site to that event is a serviceable access estimate.
  4. Group access by site rather than job type, and hold a per-site allowance for addresses that consistently cost more: gated estates, hospitals, plants with an induction, anywhere with a reception desk.
  5. Discard jobs whose complete timestamp lands in the last 20 minutes of a shift. Those are batch closures and they drag every median computed from them.

Turning those numbers into booked durations is the recalibration in the cascade diagnostic. What matters here is that the 5 spans are separated at all, because 1 field called duration cannot be argued with. Making that visible is bounded software over the platform you already run — work we scope as an MVP and product build, inside dispatch, scheduling and route sequencing and our field service and trades work.

Frequently asked questions

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

What is the difference between job duration and on-site time?

On-site time is the span from arrival at the address to job closure; job duration is whatever the board books, which in most systems is wrench time. The difference is access at the front and wrap-up at the back, typically 15 to 25 minutes a stop. Booking wrench time makes every day short by that margin, cumulatively.

Should travel time be included in a job's booked duration?

No. Travel is a property of the pair of consecutive stops, not of either job, so folding it in makes the same job take different amounts of time depending on what preceded it. Hold it as an edge in the route model, computed for the actual departure time, and book the job as arrival to release.

Which timestamp should trigger the customer's on-my-way message?

En route, but only if a technician actually departing sets it rather than a geofence or a dispatcher. A message fired while the van is still being loaded arrives 10 minutes early and trains customers to ignore the next one. Where the timestamp is unreliable, send an estimated arrival window instead of a departure claim.

  • dispatch
  • scheduling
  • job duration
  • timestamps
// 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