Una entrega falla, el repartidor llama, el cliente le da la referencia real (“es la casa con el portón verde, no la de la esquina”) y el paquete llega igual, con una hora de atraso. Para el negocio, ese pedido terminó bien: entregado, cliente contento, caso cerrado. El problema aparece en el próximo pedido de ese mismo cliente, cuando vuelve a fallar en el mismo punto, porque nadie guardó la corrección que un repartidor ya hizo una vez.
El dato se corrige en la calle, no en el sistema
La corrección existe: alguien la hizo, en el momento, por teléfono con el transportista. Lo que no existe es el paso que la lleva de vuelta al sistema que generó el pedido original (el ecommerce, el CRM o el ERP donde vive la ficha del cliente). La plataforma de logística sabe, por unas horas, cuál es la dirección correcta; después esa información se pierde entre un reparto y el siguiente, y el sistema de pedidos sigue con la versión incompleta.
Es la misma lógica que explica por qué el dato del cliente queda en silos: cada sistema guarda su propia versión de la misma persona sin compartirla. Acá el silo es la dirección, y el costo no se ve hasta la segunda compra.
Por qué la tasa general de entregas fallidas no muestra el problema
La mayoría de los negocios mide la tasa de entregas fallidas como un número agregado del mes, cuántas sobre el total despachado. Ese número puede estar estable mientras un grupo chico de clientes recurrentes falla una y otra vez en el mismo punto. La métrica que expone esto es otra: reincidencia por cliente, no tasa general. Cuántos de los que fallaron este mes ya habían fallado antes, en la misma dirección, por el mismo motivo.
Cómo cerrar el loop
- Dale al repartidor un solo lugar para registrar la corrección, dentro de la misma app donde ya confirma la entrega, no una llamada aparte a soporte que nadie transcribe.
- Conecta ese evento al perfil del cliente, no solo al pedido puntual. El objetivo es que la próxima compra arranque con la dirección corregida, no con la original.
- Precarga la dirección corregida en el próximo checkout de ese cliente, en vez de dejar que vuelva a tipear (o no corregir) el mismo dato incompleto.
- Mide la reincidencia como métrica propia, separada de la tasa general: es la que dice si el loop realmente se cerró o si cada corrección se pierde otra vez.
El mismo principio que usamos para convertir el aviso de envío en una oportunidad de retención aplica acá al revés: no es solo que el evento de logística no llegue al negocio, es que el dato que el negocio más necesita (dónde vive de verdad su cliente) a veces solo existe, por un rato, en la cabeza de quien hizo la última entrega.
Si tu equipo de logística corrige la misma dirección dos veces para el mismo cliente, el problema no es la calle: es que esa corrección nunca volvió adonde se generó el pedido.