«¿Dónde está mi expedición?» Respuestas a clientes basadas en datos del TMS

Un cliente industrial pregunta por una expedición que abastece su línea de producción. En el TMS consta «salida de plataforma» de ayer. El correo del transportista habla de una demora, pero todavía no hay una hora nueva confirmada. Una respuesta automática que diga «en reparto, llega hoy» sería rápida y poco fiable.

El objetivo es contestar con el último hecho verificable y reconocer lo que aún no se sabe. La IA puede entender la pregunta y preparar una respuesta clara. El TMS y las demás fuentes autorizadas aportan los hechos. Las reglas deciden cuándo responder, pedir datos o escalar al equipo.

Esta pieza trata la pregunta puntual del cliente sobre el estado. Dónde pierde capacidad un operador logístico analiza los traspasos de información entre equipos. Aquí diseñamos una respuesta externa concreta. Si las fuentes se contradicen, la respuesta queda en revisión hasta aclarar qué hecho puede confirmarse.

La referencia no demuestra quién puede ver el envío

El mensaje puede llegar con número de pedido, referencia de cliente o número de expedición. Primero se identifica la operación. Después se comprueba que el remitente está autorizado a recibir sus datos. Conocer una referencia no basta, especialmente si existen destinatarios, cargadores y colaboradores distintos.

El alcance de la respuesta también depende del interlocutor. Un cliente puede tener acceso al estado y a la fecha prevista, pero no a comentarios internos o información de otro cliente en una carga agrupada. El modelo solo debería recibir el contexto autorizado para esa respuesta.

Traducir eventos a hechos comunicables

El TMS registra hitos, no necesariamente una localización continua. GS1 describe EPCIS como un estándar de eventos de visibilidad que expresa qué ocurrió, cuándo, dónde y en qué contexto. El principio sirve para responder con precisión: un evento de salida confirma una salida registrada. No confirma que el vehículo ya esté en la siguiente parada.

Dato disponible	Respuesta prudente	Afirmación que no se desprende del dato
Salida de plataforma a las 08:40	«La salida quedó registrada a las 08:40»	«Está a una hora de destino»
Entrega prevista para mañana	«La previsión actual es mañana»	«La entrega está garantizada»
Incidencia abierta sin nueva fecha	«Estamos confirmando una nueva previsión»	«Se entregará hoy»

La tabla es ilustrativa. La empresa debe definir qué estados y previsiones puede comunicar según la calidad y la actualización de sus fuentes.

Qué hace la IA en la conversación

Puede interpretar «¿llega antes del turno de noche?» como una pregunta sobre fecha y hora de entrega, consultar los campos disponibles y preparar un borrador en lenguaje natural. También puede detectar que la consulta incluye una instrucción adicional, como cambiar destino, que no debe ejecutarse dentro del simple flujo de estado.

La respuesta debe separar último evento confirmado, previsión y acción en curso. Si la previsión está caducada o no existe, se dice. Si el sistema no encuentra una expedición inequívoca, se pide un dato adicional sin exponer información de posibles coincidencias.

Un modelo no debería extraer una hora de llegada de un comentario antiguo en un correo y presentarla como estado actual. Las fuentes necesitan fecha de actualización y prioridad definida. La integración con el TMS debe comprobar que consulta la operación correcta y registrar qué datos se usaron en cada respuesta.

Ejemplo de respuesta con incertidumbre bien expresada

En un ejemplo ficticio, el último evento confirmado de EXP-624 es «salida de terminal» el martes a las 18:20. La entrega estaba prevista para el miércoles, pero hay una incidencia abierta y ningún nuevo compromiso registrado.

Una respuesta revisable sería: «La última salida registrada fue el martes a las 18:20. La previsión anterior era para el miércoles, pero ahora hay una incidencia abierta y estamos confirmando una nueva fecha. Te la comunicaremos cuando quede validada». No hace falta enumerar comentarios internos ni inventar una causa. El responsable puede añadir contexto aprobado y decidir el envío.

Si el cliente pregunta de nuevo, el sistema debe recuperar el caso anterior y comprobar si cambió el estado. Repetir la misma frase sin consultar de nuevo el TMS transmite una falsa sensación de seguimiento.

Avisos automáticos y respuestas a preguntas no son lo mismo

Un aviso por hito conocido puede resolverse con reglas: «salida confirmada» o «entrega registrada». Una pregunta abierta necesita interpretar intención, verificar identidad y elegir qué información disponible responde de verdad. La IA tiene más sentido en esa segunda parte.

Antes de añadirla, comprobaría si el TMS ya ofrece un portal o notificaciones que cubran las preguntas habituales. La automatización a medida debe resolver huecos concretos, como combinar referencias de cliente, comunicación por correo y excepciones, sin duplicar información en otro sistema.

Definir cuándo un dato deja de ser suficiente

Un evento puede ser correcto y, aun así, demasiado antiguo para responder a una pregunta urgente. La empresa debe fijar reglas de frescura por tipo de servicio y estado. Tras una salida de plataforma, quizá el siguiente hito se espera horas después. Tras una entrega prevista incumplida, el mismo dato puede ser insuficiente. El sistema debe poder decir «necesita actualización» sin fabricar una localización actual.

La previsión también tiene dueño. Puede proceder del transportista, de una planificación interna o de una estimación calculada. En el borrador, esas procedencias deben conservarse. «Fecha confirmada» y «estimación pendiente» no se pueden mezclar en una misma frase. Si el cliente depende de la entrega para producir, la diferencia cambia sus decisiones.

Por último, la herramienta debería registrar qué consulta resolvió la respuesta. Si el cliente preguntó por la hora y el sistema solo conoce el día, no conviene contar el correo como «resuelto» por el mero hecho de haber enviado una respuesta. Puede abrirse una tarea para confirmar la hora o explicar que todavía no existe una previsión más precisa.

Crear un vocabulario de estados para hablar con clientes

Los estados internos del TMS suelen responder a necesidades de tráfico: «planificado», «asignado», «salida registrada», «incidencia abierta». El cliente hace preguntas distintas: ¿se ha recogido?, ¿está en tránsito?, ¿hay una hora fiable?, ¿se ha entregado? No conviene copiar el nombre técnico del estado al correo si puede inducir a error.

Definiría una tabla que relacione cada evento interno con un hecho comunicable, su fuente y sus condiciones. «Asignado a ruta» no equivale a «en reparto» si el vehículo aún no ha salido. «Entregado» quizá requiera además la confirmación documental que la empresa utiliza para cerrar el servicio. La tabla debe incluir estados sin respuesta automática, como una incidencia sin nueva previsión.

La traducción no la decide un modelo leyendo nombres de campos. Operaciones y atención al cliente acuerdan el vocabulario y prueban ejemplos reales. La IA puede convertir después el hecho aprobado en una frase natural adaptada a la pregunta, sin ampliar su significado. Si el cliente pregunta por una fecha y solo existe un evento de salida, el borrador debe reconocer que no tiene la fecha solicitada.

También importa la granularidad. Una orden de compra puede dividirse en varias expediciones y una expedición en varias entregas. La respuesta «tu pedido está entregado» puede ser falsa si solo llegó una parte. El flujo necesita saber qué nivel está consultando el cliente y desglosar el estado cuando corresponda. Si no logra asociar la pregunta a un nivel concreto, solicita aclaración.

Datos actuales, permisos y respuesta en un mismo recorrido

La herramienta recibe una pregunta por correo o portal. Identifica a la organización, comprueba que el interlocutor está autorizado y resuelve la referencia hacia una o varias expediciones. Solo entonces consulta el TMS y otras fuentes permitidas. Esta secuencia impide que una referencia conocida funcione como llave para obtener información de otra empresa.

Cada dato recuperado debe llevar fecha de actualización y procedencia. Si un estado llegó del transportista a través de una sincronización, conviene distinguir la hora del evento de la hora en que entró en el TMS. Un evento observado hace media hora y sincronizado ahora no es lo mismo que una observación hecha ahora. La respuesta puede citar el último hito sin afirmar una ubicación presente que no se conoce.

Un modelo puede interpretar preguntas como «¿podemos planificar la descarga mañana?» y detectar que no basta con saber la última posición. Puede preparar una respuesta que separe «último evento confirmado», «previsión disponible» y «confirmación pendiente». Pero no puede crear una reserva de descarga o modificar la dirección dentro del mismo flujo de consulta salvo que haya una acción específica, permisos y validaciones.

El borrador se muestra al operador con los datos usados. Si una fuente no responde o devuelve un valor caducado, el estado de la consulta se mantiene pendiente. Una frase fluida no compensa la falta de hechos. El sistema debe poder decir por qué no contesta automáticamente: referencia ambigua, permiso no confirmado, incidencia abierta o previsión antigua.

Diferenciar estado, estimación y compromiso

Un estado describe un hecho registrado. Una estimación anticipa lo que podría ocurrir. Un compromiso es una decisión comunicada con autoridad. Estas tres categorías pueden compartir una fecha, pero no tienen el mismo significado para quien organiza un muelle o una línea de producción.

Imaginemos un ejemplo ficticio: la expedición EXP-624 salió el lunes. El TMS estima llegada el jueves. Tráfico todavía no ha confirmado una cita. La respuesta prudente dice «la última salida registrada fue el lunes. La previsión actual es el jueves. La cita de descarga está pendiente de confirmación». No debería decir «entregaremos el jueves a las 09:00» porque ninguna fuente respalda esa hora ni ese compromiso.

Si un transportista comunica una nueva previsión por correo, el equipo debe decidir si pasa a ser la estimación vigente del expediente. La IA puede localizar el mensaje y proponer la actualización, pero no debería usarlo como fuente oficial sin esa decisión. De lo contrario, dos clientes podrían recibir plazos diferentes según qué hilo consultó el sistema.

La misma distinción importa después de una incidencia. Una previsión anterior no debe seguir apareciendo como válida simplemente porque está rellena en un campo. El flujo puede marcarla como obsoleta y pedir una nueva fecha. Responder «sin previsión confirmada» es más útil que repetir un dato que ya no ayuda a planificar.

Elegir canal y grado de automatización

Si las consultas son frecuentes y simples, un portal con estados claros puede resolverlas sin IA. Si llegan por correo con referencias incompletas, preguntas compuestas y excepciones, una capa de interpretación puede ayudar. Un aviso automático por hito se activa por un evento conocido. Una respuesta a pregunta debe comprobar intención, permisos y suficiencia del dato.

Empezaría con borradores para atención al cliente. Clasificaría después las consultas que resultaron correctas sin edición y las que necesitaron datos adicionales. Solo automatizaría un tipo de respuesta cuando exista un alcance explícito: cliente autenticado, expedición inequívoca, evento reciente y ausencia de incidencia. Si falta una condición, se escala.

La empresa también debe fijar expectativas de actualización. Si una respuesta promete «te avisaremos cuando tengamos nueva fecha», el sistema necesita una tarea o suscripción al cambio relevante. De otro modo, la frase se convierte en una promesa vacía. El seguimiento forma parte del flujo, no solo del texto generado.

Piloto y límites de publicación

Probaría un conjunto de clientes y tipos de expedición con estados claros. Incluiría referencias ambiguas, incidencias abiertas, previsiones obsoletas, cargas compartidas y peticiones de cambio que no son simples consultas. Atención al cliente marcaría qué respuestas serían aceptables.

Mediría tiempo hasta respuesta útil, correcciones humanas, consultas que se escalan, respuestas basadas en datos desactualizados y reclamaciones posteriores. El primer piloto puede limitarse a preparar borradores. Solo después de demostrar calidad convendría automatizar respuestas rutinarias en un alcance delimitado.

Un control final debería comparar lo que el cliente preguntó con lo que recibió. Si pidió una hora de llegada y el sistema solo conoce el día, la respuesta puede ser honesta y aun así dejar una tarea abierta. Contarla como resuelta distorsionaría las métricas. La empresa necesita medir preguntas realmente satisfechas y preguntas derivadas a tráfico.

También probaría cambios de estado mientras el borrador espera aprobación. Si el TMS recibe un nuevo hito, el texto anterior debe actualizarse o invalidarse antes de enviarlo. La precisión no depende solo de consultar una fuente fiable. Depende de consultarla en el momento adecuado.