El estado del paquete, en admin y en el cliente.

Tres verdades del mismo paquete (Excel, web del transportista, WhatsApp del comercial) generan tickets. El envío nace del pedido, con transportista y código; los estados llegan por webhook o por jobs de refresco si el transportista no empuja. El cliente mira el seguimiento en su cuenta. Operaciones mira la cola. El pantallazo deja de ser el procedimiento.

Sin número de tracking no hay magia: primero se crea el envío. Cuando el paquete se extravía de verdad, el ticket de service desk parte de un envío ya identificado, no de diez reenvíos. Pedido, envío y cliente quedan alineados. No calcula rutas ni sustituye el TMS del transportista. No cotiza el porte como un tarifador de mostrador.

Los jobs cubren agencias que no notifican al momento. Un estado «en tránsito» obsoleto se nota si nadie refresca: por eso existe el job, no un milagro. Si el código está mal tecleado, el sync fallará; corrige el envío, no abras un ticket de «la web no va».

El objetivo operativo es que «¿dónde va?» se consulte antes de escribir a soporte. Si aun así hay rotura o retraso grave, el desk usa el mismo identificador. El comprador no debería entrar al panel de envíos interno.

Un pedido sin envío creado es un hueco: el comercial cree que salió y ops no tiene fila. Crea el envío cuando haya etiqueta, no cuando el cliente pregunte. El listado interno no es un mapa logístico mundial; es el estado de vuestros pedidos.