The tow truck closest to a pickup pin may be on the wrong side of a river. Another truck is farther away on the map but can get there faster. A dispatch screen that sorts by straight-line distance can send the wrong vehicle even when every GPS location is correct.
Google Maps’ Compute Route Matrix can compare driving times from several vehicles to the same pickup. The useful part is what you do around that request: shortlist eligible drivers, match each response to the right vehicle, and give the dispatcher a clear answer when an estimate is missing.
Compare vehicles to the pickup, then calculate the job route separately
For a single job, use the available vehicle locations as origins and the pickup as the one destination. Google’s Compute Route Matrix guide describes how the method evaluates origin and destination pairs. Six vehicles and one pickup produce six elements. Six vehicles and four pickups produce 24, even if you only care about a few of those pairs.
That first leg estimates how long a driver takes to reach the customer. It is different from the loaded trip from pickup to drop-off. A 12-minute approach and a 31-kilometre tow answer different questions. If your quote depends on loaded distance, calculate it from the pickup and drop-off according to your pricing rules.
Shortlist by eligibility before sorting by ETA
Begin with rules you already know: which trucks are available, which equipment the job requires, and how recently each vehicle reported its position. A rough geographic filter can keep distant vehicles out of the first request. Leave room for bridges, motorway ramps and other barriers that make a nearby vehicle slow to reach.
Suppose Truck A is three kilometres away in a straight line but has a 17-minute route. Truck B is five kilometres away and can arrive in 11 minutes. Truck C has a nine-minute estimate but lacks the equipment for this job. Truck B is the strongest recommendation. The matrix supplies the travel estimates; your application decides which vehicles are eligible.
Rear view of a flatbed recovery truck on a road alongside workshops. Fictional AI-generated editorial image.
Fictional editorial image of a recovery truck on its approach.
Keep the original vehicle list attached to each request
The REST method reference shows a response field mask with originIndex, destinationIndex, status, condition, distanceMeters and duration. Request those fields and use the indices to map each element to the exact input arrays you sent. Don’t match results to the current order of the rows on screen; a dispatcher may have sorted or filtered the list while the request was running.
- If an element reports a valid route and has a duration, parse the seconds numerically before sorting. For example, 90 seconds should sort ahead of 600 seconds regardless of how the API encodes them.
- If a route cannot be found or an element reports an error, show that vehicle as having no estimate. Never substitute zero minutes for missing data.
- If the pickup changes while a request is running, discard the old response. A perfectly valid ETA for the previous address is wrong for the current job.
On a dispatch screen, show when the estimate was calculated and when the vehicle last checked in. A new route calculation from a stale vehicle location is still based on stale input. Label the result as estimated driving time; driver acceptance and time spent getting ready can add to the actual arrival.
Control the number of pairs you ask Google to calculate
Google’s Routes API usage and billing guide explains that matrix billing is based on elements rather than one charge per request. It also documents a 100-element request cap when using TRAFFIC_AWARE_OPTIMAL. Check the limits for your routing settings before choosing a batch size.
Splitting 120 pairs into two requests helps with a per-request cap, but it still asks for 120 pairs. Removing ineligible vehicles before calling the API reduces the work itself. Refresh when something relevant changes, such as the pickup or the position of an active candidate, instead of calling the API on every screen redraw.
Try the awkward cases before automating assignments
- Test two vehicles separated by a river or divided highway and verify that the screen sorts by travel time, not by distance to the pin.
- Simulate one unavailable route, one stale GPS report and a total API failure. The dispatcher should still be able to make a manual choice.
- Change the pickup while a request is in flight and confirm that only the new estimate appears.
- Have two dispatchers try to assign the same vehicle. Recheck availability at assignment time; a good ETA does not reserve a truck.
For a related example of Maps in an order workflow, see my Snowbirdship shipping quote plugin project. If you’re building a dispatch or booking tool, I can help map out which distances drive pricing, which estimates help staff choose a vehicle, and where a manual override belongs.
