Por qué tu ERP dice que el pedido está expedido y el cliente dice que no ha llegado

Lo escribe el albarán. En el momento en que se genera el documento de salida, el pedido cambia de estado, y a partir de ahí tu sistema lo trata como atendido. Eso es correcto dentro del ámbito del ERP: un ERP registra muy bien lo que ocurre dentro de él y no tiene forma de registrar lo que ocurre fuera. El problema no es el estado, es que se lee como si afirmara más de lo que afirma.

Merece la pena comprobar una cosa concreta en tu instalación, porque cambia mucho la conversación: en qué momento exacto se escribe ese estado. Hay tres momentos posibles y los tres se llaman igual en distintas configuraciones — cuando el almacén termina de preparar, cuando se imprime el albarán, o cuando se confirma la salida del bulto. Si el tuyo es el primero o el segundo, «expedido» es compatible con una mercancía que sigue en tu muelle, y eso hay que saberlo antes de decirle nada a un cliente.

A partir de ese documento vienen cuatro hechos más que nadie anota: la recogida pedida, el transportista presentándose, la entrega, y la prueba de esa entrega volviendo a alguna parte. Los cuatro ocurren fuera de tus sistemas y ninguno tiene un sitio donde registrarse salvo que alguien lo meta a mano. Ese es todo el mecanismo de este artículo.

La llamada siempre suena igual, y detrás hay cinco situaciones que no se parecen en nada: cambian quién tiene la mercancía, quién tiene la culpa y qué se le puede prometer a quien está al teléfono. Merece la pena tenerlas delante antes de empezar a buscar, porque la búsqueda es distinta para cada una.

Fíjate en la última fila, que es la que decide si esto es un problema administrativo o un problema de dinero. Las cuatro primeras se cierran enseñando algo. La quinta no se cierra: la mercancía salió, el cliente dice que no la tiene y no existe nada que enseñar. Ahí la discusión ya no va de logística.

El error habitual es empezar por el final —llamar al transportista— y el motivo por el que sale caro es que esa llamada tarda horas en devolverse y no descarta nada. Cada pregunta de esta lista elimina una familia entera de casos, así que en el orden correcto la mayoría se resuelve sin salir de tus propios sistemas.

1. 1

   ¿Existe número de seguimiento, y ha registrado alguna lectura?

   Si no existe, el bulto no ha salido: el albarán se emitió y la recogida no llegó a pedirse, o el transportista no vino. Se acabó la búsqueda y está en tu muelle. Si existe pero no tiene ni una lectura, la etiqueta se generó y el bulto tampoco se recogió — que a efectos prácticos es el mismo caso. Esta pregunta sola resuelve una parte notable de las llamadas y se responde en tu pantalla, sin hablar con nadie.

2. 2

   ¿Qué dice el rastreo y de cuándo es su última actualización?

   Aquí se separa «va en camino» de «pasó algo». Un rastreo que avanza con normalidad significa que no hay incidencia, y entonces la respuesta al cliente no es una disculpa: es una fecha. Un rastreo cuya última lectura es de hace cuatro días es una incidencia del transportista y hay que abrirla con él, no investigarla por dentro. La fecha de la última lectura importa tanto como el estado — un «en tránsito» de hace una semana no es un «en tránsito».

3. 3

   ¿Lo que salió es lo que se pidió?

   Compara las líneas del albarán con las del pedido antes de asumir que el problema es la entrega. Si se sirvieron ocho de diez, para el cliente eso es «no me ha llegado», y tiene razón desde su lado del mostrador: lo suyo no ha llegado. Y es el que peor se gestiona de los cinco, porque se responde como si fuera un problema de transporte cuando es un problema de no haberle avisado.

4. 4

   ¿Tienes la prueba de entrega, y a nombre de quién?

   Si el transportista da la entrega por hecha, pide la prueba: casi siempre existe y está en su portal aunque no haya llegado nunca a tus sistemas. Y cuando la tengas, mira el nombre de quien firmó. Ese dato separa los dos últimos casos, que desde fuera parecen el mismo: una entrega recibida por otra persona o en otra delegación —donde el problema es de comunicación interna del cliente, y se cierra enseñando el nombre— y una entrega que nadie puede acreditar, que es la que te deja sin defensa.

Porque en casi toda configuración «expedido» o «servido» es un estado terminal para operaciones. El pedido se considera atendido, sale de las bandejas de trabajo y deja de contar como pendiente. Visto desde dentro del ERP tiene todo el sentido: su parte terminó.

Visto desde la operación completa, es exactamente al revés. El sistema deja de vigilar el pedido justo en el tramo en el que el control lo tiene un tercero y en el que tú tienes menos visibilidad que en ningún otro momento. Mientras el pedido estaba en tu almacén, estaba en cinco listas; en cuanto sale y pasa a depender de alguien a quien no puedes preguntar por pantalla, no está en ninguna.

Eso explica una cosa que suele atribuirse a la desidia y no lo es: que estos casos se descubran siempre desde fuera. No hay ninguna pantalla donde ponga «expedido hace nueve días y sin prueba de entrega». No es que nadie mire esa lista: es que esa lista no existe. Y como no existe, el reloj lo pone el cliente cuando llama, que es varios días después de que el dato ya fuera conocible.

Una cosa, y es barata: construir la lista que tu ERP no tiene. Casi cualquiera puede producir un listado de pedidos en estado expedido con su antigüedad; lo que no hace ninguno por defecto es cruzarlo con si ha vuelto la prueba de entrega. Si ese cruce no es posible con tus herramientas, la versión pobre sirve igual para empezar: expedidos de hace más de X días que siguen sin facturar.

Con esa lista delante cambian dos cosas. Un día fijo a la semana y un dueño — no un procedimiento, una persona — y de repente los casos se descubren antes de la llamada. Y aparece algo que antes no se podía ver: cuántos son al mes. Esa cifra es la que convierte una molestia difusa en un problema con tamaño.

Para ponerle horas y euros, el método está en el artículo sobre lo que cuesta una incidencia de pedido, que descompone cada caso en cuatro sumandos. Y si lo que quieres es entender por qué estas llamadas se concentran siempre en los mismos puntos del recorrido, las siete costuras donde se queda parado un pedido son el mapa completo — tres de las siete desembocan en esta llamada.

Lo que no, primero, porque es lo que importa si estás comparando opciones: Pliuz no sustituye a tu ERP ni a tu sistema de almacén, y tampoco te va a dar visibilidad del camión — esa la tiene el transportista y sale de su portal. Si lo que te falta es conectar el ERP con el transporte, eso es un problema de integración y está tratado en el pilar sobre conectar el ERP, el almacén y el transporte.

Lo que estamos construyendo es la capa de encima: que un pedido expedido hace nueve días sin prueba de entrega deje de ser invisible y se convierta en un caso con dueño y con plazo, antes de que llame nadie. Ese motor de casos se está construyendo con las primeras distribuidoras y no se puede comprar hoy: decir lo contrario sería vender una pantalla que todavía no existe.