Una entrega fallida de muebles es cara de una forma en que no lo es la de un paquete. Un camión, un equipo de dos personas y una franja horaria programada se desperdician cuando la dirección del pedido no lleva a ningún sitio útil, y una tienda de muebles que enviaba artículos grandes en franjas de entrega programadas estaba asumiendo ese coste varias veces por semana.
La mayoría de los fallos tenían la misma causa de fondo: una dirección que, según el cliente, estaba escrita correctamente, pero que en realidad no se resolvía en una ubicación donde se pudiera entregar, ya fuera por un error tipográfico en el nombre de la calle, un código postal que no coincidía con la ciudad introducida o un número de apartamento que faltaba por completo. Nada de esto es evidente al leer el texto de la dirección. Solo se hace evidente cuando algo intenta cotejar esa dirección con datos geográficos reales.
La tienda añadió una comprobación en la confirmación del pedido, antes de que el pedido pasara al sistema de programación de entregas. La dirección que introducía el cliente se enviaba a /v1/forward, que intenta encontrar una coincidencia y devuelve un resultado de ubicación junto con una indicación de la calidad de la coincidencia, mostrando con qué confianza se resolvió la dirección en lugar de fingir que todas las entradas son igual de fiables. Por separado, el código postal que introducía el cliente se comprobaba con /v1/postcode, que consulta a qué corresponde ese código, detectando el caso concreto en el que un código postal y el nombre de una ciudad no concordaban entre sí, un desajuste que un cliente comete con facilidad por un error del autocompletado del navegador y que es muy difícil de detectar leyendo el formulario del pedido.
Los pedidos en los que ambas comprobaciones salían limpias pasaban directamente a la programación. Los pedidos en los que la dirección solo coincidía parcialmente, o en los que el código postal y la ciudad no concordaban, se marcaban para una llamada o un correo electrónico rápido de confirmación antes de reservar cualquier franja de entrega. Ese único paso adicional, ejecutado automáticamente y aplicado antes de incurrir en ningún coste de camión, adelantó la corrección en el proceso, de "descubierto por un equipo plantado en la dirección equivocada" a "resuelto con un correo electrónico el mismo día en que se hizo el pedido".
La tienda fue cuidadosa con lo que afirmaba ante los clientes. Una comprobación de verificación como esta confirma que una dirección está bien formada y es geográficamente plausible. No confirma que exista un número de unidad concreto dentro de un gran complejo de apartamentos, ni que la persona que hace el pedido viva realmente allí, así que la lógica de marcado se ajustó para detectar direcciones claramente incorrectas en lugar de rechazar cualquier cosa mínimamente inusual, lo que habría generado más falsas alarmas de las que resolvía.
Como la comprobación se ejecutaba una vez por pedido y no por cada vista de página, el volumen era fácil de predecir y se mantuvo muy por debajo de la cuota diaria gratuita para una tienda de este tamaño, con crédito prepago para cubrir cualquier exceso durante una campaña de rebajas. El retorno del cambio se reflejó directamente en menos franjas de entrega desperdiciadas, un coste fácil de medir y fácil de justificar frente a un precio por solicitud muy bajo.
La documentación de ambos endpoints, incluida la forma en que se representa la calidad de la coincidencia, está en /docs/forward-geocoding/ y /docs/postal-code-lookup/.