Um voluntário disposto a ajudar, mas não disposto a dirigir quarenta minutos para ir e mais quarenta para voltar, é um voluntário que discretamente para de responder aos pedidos, e uma organização comunitária sem fins lucrativos que coordenava várias centenas de voluntários em uma região metropolitana descobriu que o seu antigo processo de correspondência, em que um coordenador se lembrava manualmente de quem morava mais ou menos perto de uma determinada necessidade e entrava em contato individualmente, era lento e cada vez menos confiável à medida que a lista de voluntários crescia além do que qualquer pessoa conseguiria guardar de cabeça.
Os dois lados do problema de correspondência, os endereços residenciais dos voluntários e os endereços das necessidades em andamento, fosse um banco de alimentos que precisava de ajuda regular, um morador idoso que precisava de assistência ocasional ou um evento comunitário que precisava de voluntários para a montagem, existiam como endereços em texto coletados por formulários simples de cadastro e de solicitação. Transformá-los em algo que pudesse ser combinado pela proximidade real começou com a geocodificação das duas listas pelo /v1/forward, feita em lote para a lista existente de voluntários e de necessidades e depois a cada nova entrada, à medida que chegavam novos cadastros e solicitações.
Com coordenadas dos dois lados, a correspondência se tornou um cálculo de distância que o próprio banco de dados simples da organização podia fazer diretamente: para qualquer nova necessidade, classificar os voluntários cadastrados pela distância real do endereço residencial deles e entrar em contato começando pelos mais próximos, em vez de depender de quem um coordenador por acaso se lembrasse que morava na parte certa da cidade. Isso revelou voluntários que estavam parados no sistema por motivos que não tinham nada a ver com disposição, simplesmente porque um coordenador não sabia pessoalmente que eles moravam perto de uma determinada necessidade recorrente.
A organização manteve um coordenador humano no processo para o contato em si e para a decisão de correspondência, já que a distância era um fator importante, mas não o único: as habilidades específicas de um voluntário, a disponibilidade dele ou uma relação já existente com uma determinada necessidade às vezes importavam mais do que ser a opção mais próxima, e o papel da ferramenta era apresentar uma lista classificada por distância que um coordenador pudesse percorrer rapidamente, e não automatizar totalmente uma designação que o coordenador preferia revisar antes.
As taxas de resposta dos voluntários melhoraram visivelmente quando o contato passou a priorizar de forma consistente as pessoas realmente próximas, um resultado que fazia todo o sentido depois que a organização o viu claramente nos próprios dados: um pedido que era de fato conveniente para um voluntário atender simplesmente tinha mais chance de receber um sim do que um mais distante, para o qual um coordenador tinha recorrido por familiaridade e não por proximidade.
Por operar como uma organização sem fins lucrativos com restrições orçamentárias reais, o custo importava especialmente aqui, e o uso do projeto, uma geocodificação em lote modesta para a lista inicial mais um pequeno fluxo contínuo para novos cadastros e solicitações, coube confortavelmente na cota diária gratuita sem nunca precisar considerar crédito pré-pago ou uma chave Unlimited, o que significa que toda a capacidade de correspondência por localização saiu sem custo para uma organização para a qual cada real de um orçamento limitado fazia diferença.
Se uma organização comunitária está pensando em algo parecido, o ponto de partida é menor do que parece: geocodifique os endereços que você já tem e veja como a correspondência por distância realmente fica com as suas listas reais de voluntários e de necessidades antes de construir qualquer coisa mais elaborada em cima disso. A documentação do endpoint está em /docs/forward-geocoding/.