«¿Dónde está mi envío?»: avisa al cliente de cada estado sin coger el teléfono

El problema no es el envío, es el teléfono

A las nueve de la mañana la persona de tráfico ya tiene tres llamadas y cinco correos. Ninguno es un problema de verdad. Todos preguntan lo mismo: ¿dónde está mi pedido, llega hoy, por qué pone «en tránsito» desde ayer? Para contestar, abre el portal del transportista, busca el número de seguimiento, lee el estado y lo traduce al cliente. Dos minutos por consulta que se convierten en media mañana.

En el comercio electrónico esta avalancha tiene nombre: WISMO, de «where is my order» (dónde está mi pedido). Es una de las categorías de consulta más repetidas en atención al cliente, y se dispara en campañas y festivos. No aporta nada: el cliente solo quiere saber por dónde va su paquete, y tú ya tienes esa información en un sistema. El coste no es el envío, es el tiempo de una persona haciendo de intermediaria entre dos pantallas.

La buena noticia es que esto es de lo más automatizable que hay en un operador logístico, porque el dato ya existe y solo hay que moverlo. La mala es que todo el mundo lo vende como magia, y la magia se rompe en cuanto el transportista da el estado tarde. Vamos a montarlo de forma que funcione y a decirte dónde deja de funcionar.

Qué significa cada estado que ve el cliente

El primer problema es de idioma. El cliente ve «aceptado por el operador logístico» y entiende que su paquete está parado en un almacén sin moverse, cuando en realidad es una buena señal: el transportista ya lo tiene registrado y en su cadena. Los nombres cambian de un transportista a otro (uno lo llama «admitido», otro «aceptado», otro «en trámite»), pero el ciclo de vida es casi siempre el mismo. Antes de montar nada, conviene abrir la web de seguimiento de los transportistas con los que trabajas y apuntar cómo llama cada uno a cada fase. No te fíes de lo que creas recordar: compruébalo en su portal.

Esta es la traducción que uso para decidir qué comunicar. La última columna es la que de verdad importa, porque avisar de todo es tan inútil como no avisar de nada.

De dónde se lee el estado (y por qué esto decide todo)

El aviso automático no inventa nada: repite lo que le dice una fuente. Esa fuente puede ser el sistema del transportista o tu propio TMS si ya recoge los estados. El canal por el que se obtiene el dato marca lo bien que va a funcionar todo lo demás, así que no es un detalle técnico, es la decisión principal.

Hay tres formas de conseguir el estado, de mejor a peor:

• Webhook del transportista. El transportista avisa a tu sistema en cuanto el estado cambia. Es lo ideal: en segundos sabes que un envío ha pasado a «en reparto» sin preguntar nada. No todos los transportistas lo ofrecen.
• API de seguimiento. Tu sistema pregunta al del transportista cada cierto tiempo (cada 15 o 30 minutos, por ejemplo). Funciona muy bien, con un pequeño retraso respecto al webhook. La mayoría de transportistas serios tienen API, y FedEx, por ejemplo, documenta notificaciones de eventos y de prueba de entrega en la suya.
• Portal web (scraping). Si no hay API ni webhook, se lee la página de seguimiento de forma automática. Es la opción frágil: cualquier cambio en su web lo rompe, y conviene tratarla como provisional, no como base.

Qué cambios merecen un aviso y cuáles no

El error más común es avisar de cada movimiento. El cliente recibe ocho mensajes por un paquete y acaba silenciándote, justo cuando llega el aviso que sí importaba. Avisar de más es tan dañino como no avisar: le enseñas a ignorarte.

Mi regla es comunicar solo los hitos en los que el cliente puede o quiere hacer algo:

• Ha salido. Confirma que el pedido está en camino y da una fecha estimada. Corta de raíz el «¿se ha enviado ya?».
• En reparto hoy. El aviso de más valor. El cliente decide si se queda en casa o cambia la entrega.
• Incidencia. Dirección incorrecta, ausencia, segundo intento. Aquí el aviso tiene que incluir qué debe hacer el cliente, no solo que hay un problema.
• Entregado. Con la prueba de entrega adjunta o accesible. Reduce las reclamaciones de «no me ha llegado».

Qué canal para cada aviso: correo o WhatsApp

Los dos canales valen para avisos de seguimiento, pero no son intercambiables. El correo deja rastro documental y es el sitio natural de la confirmación de envío y de la prueba de entrega: puedes adjuntar el POD y queda archivado. WhatsApp es inmediato y se lee casi al momento, así que encaja en el aviso de «en reparto hoy» y en la gestión conversacional de una incidencia, donde el cliente quiere responder rápido.

Una combinación que funciona bien: correo para la confirmación de salida y para la entrega con POD, y WhatsApp para el «en reparto» y para resolver incidencias donde hace falta ida y vuelta. No dupliques: si mandas el mismo aviso por los dos canales, vuelves al problema de saturar.

Avisar por WhatsApp a un cliente tiene reglas: se necesita su consentimiento y hay que usar plantillas aprobadas para los mensajes que tú inicias. No lo repito aquí porque ya lo conté en detalle en qué es legal, qué funciona y qué cuesta un chatbot de WhatsApp para empresas. Léelo antes de montar el canal, porque enviar notificaciones comerciales sin permiso te puede costar caro.

Cómo se monta el circuito, paso a paso

No es un proyecto de meses. Es un circuito con piezas conocidas, y la mayor parte del trabajo está en limpiar los datos de entrada, no en el aviso en sí.

1. Unifica el origen del estado

Decide de dónde sale el estado de cada transportista: webhook, API o, si no queda otra, portal. Traduce todas las nomenclaturas a un conjunto de estados internos tuyos (salido, en reparto, incidencia, entregado). Este paso es el 70% del trabajo y el que casi nadie cuenta.

2. Asocia cada envío a su cliente y sus datos de contacto

El número de seguimiento tiene que estar ligado al pedido, al cliente, a su correo y, si procede, a su móvil con consentimiento. Si esa relación está rota o incompleta, no hay aviso que valga: no sabrás a quién escribir. Aquí es donde se cae la mitad de los proyectos.

3. Define las reglas de aviso

Qué estado dispara qué mensaje, por qué canal y con qué texto. Un cambio a «en reparto» dispara el WhatsApp con plantilla; un cambio a «entregado» dispara el correo con el POD. Escribe los textos pensando en el cliente que no sabe logística: nada de jerga interna.

4. Separa la incidencia del resto

Cuando el estado es una incidencia, el circuito no la resuelve: avisa al cliente y abre un aviso para una persona de tu equipo, con el contexto ya cargado. Esto lo trato más a fondo en 6 conversaciones de transporte que ya no debería atender una persona.

5. Mide antes y después

Cuenta cuántas llamadas y correos de «¿dónde está mi envío?» entran hoy. Es tu línea base. Si no la tienes, no sabrás si ha servido. Para ponerle números al ahorro, tienes la plantilla en cómo calcular el ROI de una automatización.

Cuándo NO compensa (la parte honesta)

Este circuito no es para todo el mundo ni arregla todos los problemas. Hay casos en los que montarlo es gastar esfuerzo para repetir un fallo más rápido.

No compensa si el transportista da el estado tarde o mal. Si su sistema marca «entregado» cuando el bulto sigue en la furgoneta, tu aviso automático mandará al cliente un «ya lo tienes» cuando no lo tiene. El aviso es tan bueno como el dato de origen. Automatizar encima de un transportista que no actualiza a tiempo amplifica el problema en lugar de taparlo.

No compensa para las incidencias de verdad. Un envío dañado, una dirección imposible, una reclamación: eso necesita a una persona que decida, negocie y a veces se disculpe. La automatización avisa y prepara el terreno, pero no cierra el caso. Si alguien te vende que la IA resuelve las incidencias sola, desconfía.

No compensa si haces pocos envíos. Si mandas diez paquetes al mes, el WISMO no te está comiendo la mañana y montar el circuito es matar moscas a cañonazos. El cálculo cambia cuando el volumen es alto o muy estacional.

Y no compensa si tus datos de contacto están sucios. Si la mitad de los pedidos no tiene un correo o un móvil fiable asociado, lo primero es arreglar eso, no montar avisos que no llegan a nadie. Para la parte de devoluciones y posventa, que es prima hermana de esto, escribí qué se automatiza de verdad en logística inversa.

La prueba de entrega es la que cierra el círculo

El estado más valioso para ti no es «en reparto», es «entregado con POD». La prueba de entrega es el registro, físico o digital, que confirma que el pedido llegó, a quién y cuándo: firma, nombre, foto, fecha y hora. Es lo que te defiende cuando un cliente dice que no ha recibido nada.

Si el aviso de entrega incluye o enlaza el POD, cortas de raíz una segunda oleada de consultas y, sobre todo, de disputas. El cliente ve la firma o la foto y la conversación se acaba ahí. Para que esto funcione, el POD tiene que entrar en tu sistema sin papel y bien asociado al envío. El circuito entero de albaranes y pruebas de entrega lo monté paso a paso en albaranes y pruebas de entrega sin papel.

Un apunte de un operador logístico con el que trabajamos: lo que más les redujo las consultas no fue el aviso de salida, fue adjuntar el POD al correo de entrega. Las reclamaciones de «no me ha llegado» bajaron de forma notable porque el cliente tenía la prueba delante antes de pensar en escribir. No te doy un porcentaje porque es su dato interno, pero el patrón se repite: la prueba de entrega accesible evita la discusión.

Preguntas frecuentes

Fuentes

• Seguimiento de envíos y gestión de entrega (Correos Express)
• Estado del envío de paquetes en Seur: qué significa cada uno (Envíos y Pedidos)
• ¿Qué es el WISMO (Where Is My Order) y cómo afecta a tu e-commerce? (Ecommerce News)
• Proof of delivery: qué es en logística (EAE Business School)
• Track API (seguimiento y notificaciones de eventos) (FedEx Developer Portal)

Seguir leyendo