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 nonprofit volunteer matching tool by distance
A volunteer willing to help but unwilling to drive forty minutes each way is a volunteer who quietly stops responding to requests, and a community nonprofit coordinating several hundred volunteers across a metro area found that its old matching process, a coordinator manually recalling who lived roughly near a given need and reaching out individually, was both slow and increasingly unreliable as the volunteer list grew past what any one person could keep in their head.
Both sides of the matching problem, volunteer home addresses and the addresses of ongoing needs, whether a food pantry needing regular help, an elderly resident needing occasional assistance, or a community event needing setup volunteers, existed as text addresses collected through simple signup and request forms. Turning those into something that could be matched by actual proximity started with geocoding both lists through /v1/forward, run as a batch for the existing volunteer roster and needs list, then per new entry as fresh signups and requests came in.
With coordinates on both sides, matching became a distance calculation the nonprofit's own simple database could run directly: for any new need, rank registered volunteers by actual distance from their home address, then reach out starting with the closest ones rather than relying on whoever a coordinator happened to remember lived in the right part of town. This surfaced volunteers who had been sitting unused in the system for reasons that had nothing to do with willingness, simply because a coordinator did not personally know they lived near a particular recurring need.
The nonprofit kept a human coordinator in the loop for the actual outreach and matching decision, since distance was an important factor but not the only one, a volunteer's specific skills, availability, or existing relationship with a particular need sometimes mattered more than being the closest option, and the tool's job was to surface a ranked, distance-sorted list a coordinator could work through quickly rather than to fully automate an assignment a coordinator would rather review first.
Response rates from volunteers improved noticeably once outreach started consistently targeting genuinely nearby people first, an outcome that made intuitive sense once the organization saw it clearly in its own data: a request that was actually convenient for a volunteer to fulfill was simply more likely to get a yes than one further away that a coordinator had reached for out of familiarity rather than proximity.
Because it operated as a nonprofit with real budget constraints, cost mattered specifically here, and the project's usage, a modest batch geocoding run for the initial roster plus a small ongoing trickle for new signups and requests, fit comfortably inside the free daily allowance without ever needing to consider prepaid credit or an Unlimited key, meaning the entire location matching capability came at no cost to an organization for whom every dollar of a limited budget mattered.
If a community organization is considering something similar, the starting point is smaller than it sounds: geocode what addresses you already have, and see what distance-based matching actually looks like against your real volunteer and need lists before building anything more elaborate on top of it. Documentation for the endpoint is at /docs/forward-geocoding/.