Work / Roadside Service Locator
Roadside Service Locator
A truck breaks down somewhere on an interstate. This finds the nearest shop that will actually help — and remembers whether it did.
Illustration of the flow: GPS point → 150-mile radius search → ranking by how past call-outs went.
Given GPS coordinates, the module returns repair shops, pilot services and service points within a 150-mile radius. The part that matters is not the search — it is that every call-out is scored afterwards, so the ranking improves with use.
The nearest shop is not the best shop
When a truck goes down, dispatch searches maps, calls numbers and hopes. Distance is the only thing a map gives you, and distance is a weak predictor of whether a shop answers the phone at 11 p.m., has the part, or charges what it quoted.
That knowledge existed — in the heads of the dispatchers who had called before. It just was not written down anywhere.
Decisions
Capture the outcome, not just the search. After every call-out, dispatch records what happened: answered or not, fixed or not, price as quoted or not. Two fields at the end of an incident turn a directory into something that learns.
Rank on distance and history, weighted. A shop 30 miles further that has never let anyone down beats a nearer unknown. Both factors are visible in the result so dispatch can override.
Cache aggressively. The set of service points in a region barely changes week to week. Hitting the maps API on every breakdown would be slow and expensive for no benefit.
Where it stands
Dispatch starts from a ranked list instead of a map search. The institutional knowledge that used to leave with an employee now stays in the database.
What I would do differently
The outcome form was optional at launch, so for the first weeks it was mostly skipped and the ranking had nothing to learn from. Making it a required step to close an incident — one screen, three taps — would have got the system useful a month earlier.