Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Building a field service dispatch tool by distance
Assigning the nearest available technician sounds obvious until you look at how most small dispatch systems actually work, which is often by simple availability, next job to whichever technician finishes their current job first, regardless of whether that technician happens to be on the far side of the service area from where the new job is located. A home appliance repair company running a fleet of technicians found this was quietly costing it drive time across the board, technicians crossing the service area to reach jobs that a nearby colleague could have reached in a fraction of the time.
Fixing this required knowing, in coordinates, where every technician currently was and where every new job was located, rather than treating both as text descriptions a dispatcher had to reason about by memory of the local area. New job addresses were geocoded through /v1/forward as they came in, converting each service request into a coordinate the moment it was scheduled. Technician locations, tracked through their own mobile app as they moved between jobs, arrived as coordinates directly from device location, needing no geocoding themselves, but the reverse lookup, /v1/reverse, gave dispatchers a readable street-level description of where a technician currently was, useful for a human dispatcher glancing at a screen who needed to understand a technician's position quickly rather than parsing raw coordinates.
With both sides expressed as coordinates, the dispatch system could calculate actual distance between every available technician and a new job, and assign based on a combination of distance and availability rather than availability alone, weighted so that a technician who was slightly less immediately available but much closer often came out as the better assignment than one who was free right now but far away, a tradeoff the company tuned over a few weeks of watching real assignment outcomes.
The measurable effect was a reduction in average drive time per job across the fleet, which translated directly into more completed jobs per technician per day, since less time spent driving between jobs meant more time available for the jobs themselves. Fuel cost per job also dropped, a smaller but real additional benefit the company had not specifically been trying to solve for when it started the project.
The company kept a dispatcher in the loop rather than fully automating assignment, since distance is an important factor but not the only one, a technician's specific certification for a particular appliance brand or a customer's preference for a technician they had seen before sometimes outweighed a purely distance-optimal assignment, and the tool surfaced the distance-ranked suggestion as a strong default a dispatcher could override rather than an automatic assignment with no human check at all.
Volume scaled with job volume, one geocoding call per new job plus a smaller number of reverse lookups for dispatcher-facing technician location display, comfortably inside the free daily allowance for a company running a fleet of this size, with headroom into prepaid credit available if the company expanded into additional service areas.
Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/reverse-geocoding/.