Multi-location home services · the ETA nobody recalculates

Your fleet GPS knows exactly where the technician is. Your booking window still says “2 to 4pm.”

Fleet-tracking software already has live technician location — it is the entire point of the category. The arrival window a customer was given is still a calendar estimate set at booking, not updated from where the technician actually is right now.

The desire, and the window that never updates

Nobody searching “vehicle tracking software” wants a map with dots on it. They want a customer waiting at home to know when the technician will actually arrive, not a two-hour guess made when the job was booked and never revisited.

1. 1. The data — live vehicle location. Already running, for dispatch and route efficiency. This is the well-known half, and most fleet-tracking purchases are justified on it alone.
2. 2. The gap — the window it never updates. The customer-facing arrival estimate was generated once, at booking, from a schedule template. The GPS feed that could tighten it runs in a separate dashboard nobody wired to customer messaging.
3. 3. The close — recalculate from where the truck actually is. As the technician finishes the job ahead of this one, push an updated estimate — the same expectation delivery and rideshare apps set years ago, applied to a service call.

The two systems are often bought together and still act like strangers — one produces a number nobody downstream ever asks for.

Which platform this runs on

• Field-service software, by scale — the platform that owns dispatch, booking, and often fleet tracking itself.
• Online booking software: the urgency note nobody reads — a different unread input on the same booking flow.
• Dispatch software: the event your reviews never see — the same dispatch data, feeding a different gap.

Some links on the recommendation page are partner links: the vendor pays us if you sign up, your price does not change, and each button says which.

How to build it yourself, end to end

Five steps. Each names the vendor touchpoint from the picks above.

1. 1. Confirm the GPS feed and the booking system can talk to each other. Same vendor or an API bridge — either works, but the two need a live connection, not a nightly export.
2. 2. Recalculate the estimate on each job completion, not on a timer. A technician finishing early or running long should shift every downstream estimate immediately, not on the next scheduled refresh.
3. 3. Narrow the window, do not just confirm it. A two-hour window that becomes a thirty-minute one as the technician gets close is the actual improvement; simply repeating the original window back adds nothing.
4. 4. Send the update through the channel the customer is already using. Text, not a portal login — the same channel the original confirmation went through.
5. 5. Track how often the narrowed estimate actually holds. An updated ETA that misses as often as the original window did is not worth the added complexity; this only pays off if it is measurably more accurate.

Step 3 is the one worth insisting on — a live feed that only ever confirms the original static window was not used for anything.

Or have it scoped and built

Wiring fleet GPS into a customer-facing live ETA is scoped work against your specific dispatch and messaging stack — the readiness assessment is where that gets mapped out before anything is built.