IA para gestionar reclamaciones de transporte sin perder el contexto de la expedición

Las reclamaciones de transporte llegan a un buzón, pero su respuesta se encuentra repartida entre el TMS, el justificante de entrega, las conversaciones con el transportista y las notas del equipo. Clasificar el correo es útil. Lo decisivo es que el caso no pierda la relación con su expedición y con las decisiones ya tomadas.

Este artículo propone el flujo completo para reclamaciones de mercancías: entrada, asociación, investigación, respuesta y cierre. El caso concreto de daño, fotografías y reserva en entrega se desarrolla en una reclamación por mercancía dañada. El artículo general de automatización documental para transitarios se centra en documentos de operación que alimentan el TMS, no en la atención de reclamaciones.

Clasificar por siguiente acción, no solo por palabras

«No ha llegado», «llegó incompleto» y «llegó dañado» pueden aparecer en un mismo hilo. Una categoría única para todo el correo puede ocultar dos tareas: verificar el estado de la expedición y tramitar una reclamación por faltantes. El equipo debe definir qué situaciones requieren prioridad, a quién se asignan y qué datos mínimos hacen falta.

Una clasificación práctica puede distinguir solicitud de información, aviso de incidencia, reclamación formal, documentación adicional y respuesta a un caso abierto. El modelo propone la categoría. Reglas y responsables determinan la ruta. Si la intención no está clara, el sistema pregunta al operador o prepara una aclaración.

La fecha del correo tampoco debe confundirse con la fecha del hecho. Un mensaje reenviado hoy puede describir una entrega de la semana pasada. El expediente conserva ambas.

Asociar el caso y conservar el hilo

La vinculación usa referencias de pedido, expedición, albarán o contenedor, junto con cliente y otros datos de operación. El número de seguimiento en un asunto puede estar mal copiado. Una coincidencia con un nombre de empresa común no es suficiente. Cuando quedan varias opciones, el estado debe ser «pendiente de asociación».

Una vez asociado, cada mensaje y documento se incorpora al caso con su versión. Microsoft Graph expone propiedades de mensaje y conversación de Outlook, pero la aplicación debe diseñar la relación con el expediente del TMS y manejar reenvíos o conversaciones partidas.

El historial visible para el equipo debe incluir solicitudes realizadas al cliente, respuestas del transportista, tareas abiertas y borradores aún no enviados. Un resumen generado ayuda a entrar en el caso, pero no debe sustituir las fuentes. El revisor tiene que poder abrir el correo o el documento del que salió cada afirmación.

Una cola de trabajo con estados claros

Estado	Qué falta	Siguiente acción
Nueva	Asociación o clasificación	Revisar referencia y asignar responsable
En investigación	Evidencia interna o externa	Solicitarla y registrar plazo interno
Pendiente de cliente	Dato o documento concreto	Enviar petición revisada
Respuesta preparada	Aprobación de contenido	Verificar hechos, destinatario y tono
Cerrada	Decisión registrada	Conservar motivo y comunicación final

Estos estados son un ejemplo de diseño. La empresa puede necesitar subestados por transporte propio, colaborador o aseguradora. Lo importante es que «correo contestado» no se confunda con «reclamación resuelta».

Ejemplo: dos mensajes, un caso y una corrección

En un escenario ficticio, el cliente pregunta por tres palés que no constan como recibidos. El TMS marca entrega completa. El justificante solo permite leer dos unidades con claridad. El sistema no debería responder «entregado» basándose en el estado del TMS. Abre investigación, muestra la discrepancia y prepara una petición al operador que gestionó la entrega.

Más tarde el transportista envía una foto nueva. La IA puede proponer una actualización del resumen. El responsable revisa si cambia la conclusión y si hay un borrador al cliente que debe corregirse. El valor está en mantener conectadas evidencia, estado y comunicación, no en redactar más deprisa una frase incorrecta.

Dónde automatizar comunicaciones

El acuse de recepción puede automatizarse si la empresa define destinatario, lenguaje y límites. Una solicitud de información puede prepararse con una plantilla y los datos que falten. Las conclusiones, compensaciones o afirmaciones sobre responsabilidad requieren una aprobación específica.

La IA puede resumir hilos, detectar preguntas sin respuesta y preparar borradores basados en información validada. Debe distinguir expresamente hechos del sistema, afirmaciones del cliente y decisiones internas. El envío automático de una respuesta definitiva solo tendría sentido en casos muy acotados y probados. No debe ser el objetivo inicial.

Separar la cola interna de la comunicación externa

Una reclamación puede tener tareas simultáneas: pedir una foto al cliente, solicitar el POD al transportista y comprobar un evento en el TMS. El cliente no necesita ver cada nota interna, pero sí recibir una actualización cuando el equipo disponga de una novedad o cuando se haya comprometido a responder. La herramienta debe mostrar quién tiene cada tarea y qué hito desbloquea la siguiente comunicación.

Si la IA redacta una nota interna, puede incluir hipótesis para investigar. El borrador externo debe limitarse a información autorizada y comprobada. Esa separación no se consigue solo con una instrucción en un prompt: conviene construir entradas y plantillas diferentes para ambos usos y verificar el destinatario antes de enviar.

Una reclamación puede pasar de simple consulta a disputa formal. En ese cambio, se revisan permisos, responsables y tono de respuesta. La clasificación inicial no debe quedar congelada. El sistema necesita detectar nuevas evidencias y permitir que una persona cambie la ruta del caso sin perder su historial.

Dar a cada caso una identidad estable

La expedición y la reclamación son objetos distintos. Un envío puede originar dos reclamaciones —por retraso y por daño—, y una reclamación puede abarcar varias entregas de un mismo pedido. Si el sistema iguala «caso» y «expedición», mezclará responsabilidades o cerrará todo cuando solo se resolvió una parte.

La identidad del caso puede combinar una referencia interna, cliente, motivo y expediciones vinculadas. Los correos entrantes se asocian a ese caso mediante referencias y contexto, con revisión de ambigüedades. Un asunto de correo editado por el cliente no debería abrir una reclamación nueva si sigue tratando la misma incidencia. Tampoco una respuesta sobre otro envío debe añadirse por llevar el mismo nombre de cliente.

El caso conserva una línea de tiempo de mensajes, documentos, hitos y decisiones. En esa línea debe distinguirse cuándo ocurrió un hecho y cuándo se registró. Una actualización tardía del TMS puede entrar hoy y describir una entrega de ayer. Ordenar solo por fecha de recepción haría parecer que ocurrió después de la reclamación.

Esta estructura permite que el equipo busque «qué quedó pendiente» y no solo «qué dijo el último correo». También sirve para identificar si una respuesta preparada se apoya en información anterior a un nuevo evento.

Asignar trabajo según la siguiente decisión

La clasificación por tipo de reclamación ayuda a entrar en la cola, pero la asignación útil pregunta quién puede tomar la siguiente decisión. Atención al cliente puede acusar recibo. Tráfico debe contrastar un evento. Almacén puede aportar fotos de carga. Otra función puede revisar una compensación. Un caso puede tener varias tareas abiertas con responsables distintos, sin que se duplique la comunicación externa.

La prioridad puede combinar fecha, impacto declarado por el cliente y estado operativo. No conviene dejar que el modelo deduzca «urgente» solo por el tono del mensaje. Una línea de producción detenida puede ser crítica aunque el correo sea escueto. Un mensaje enfadado puede referirse a una consulta rutinaria. La empresa define señales y niveles de escalado.

La interfaz debería mostrar tareas bloqueantes y no bloqueantes. Mientras se espera una foto, puede confirmarse al cliente que se recibió el caso. No puede cerrarse la investigación si la evidencia es imprescindible. Es una distinción pequeña que mejora tiempos sin convertir una respuesta rápida en un cierre prematuro.

Cuando se completa una tarea, el sistema revisa si hay borradores afectados. Por ejemplo, si llega un POD que contradice el resumen, la respuesta pendiente vuelve a revisión. Esa dependencia debe ser visible para quien atiende el buzón.

La comunicación debe tener una política propia

Antes de automatizar correos, acordaría qué se puede enviar en cada estado. Un acuse puede salir con referencia y plazo interno de revisión si la empresa lo ha definido. Una solicitud de documentación requiere comprobar qué falta de verdad. Una conclusión necesita aprobación y una explicación respaldada por el expediente. El sistema no debe usar una plantilla de «caso resuelto» porque alguien marcó una tarea como terminada.

También hay que decidir quién recibe copias. Un transportista colaborador puede necesitar ciertos datos del envío, no la conversación completa con el cliente. Una separación de vistas y permisos evita que un resumen interno acabe en el correo externo. Los borradores de IA deben generarse con el contexto adecuado para cada destinatario.

Las promesas de actualización se registran. Si se dijo «te informaremos mañana», el caso debe generar una tarea para revisar el estado antes de ese plazo, incluso si no hay una nueva evidencia. El texto del siguiente mensaje puede reconocer que aún se investiga. La automatización no debe olvidar compromisos que ella misma ayudó a redactar.

Una comunicación útil responde a la pregunta concreta del cliente. Si pregunta por una mercancía dañada, un resumen de todos los hitos de tránsito puede no ayudar. La IA puede condensar el expediente en una explicación breve, pero debe mantener los datos que sostienen la respuesta y los pendientes relevantes.

Decidir si hace falta una herramienta nueva

Un TMS o CRM puede incluir ya tickets, tareas y plantillas de correo. Antes de construir una aplicación paralela, comprobaría qué partes cubre: identidad del caso, adjuntos, permisos, API, estados y confirmación de envíos. Quizá el trabajo nuevo sea solo vincular el buzón y resumir documentos. Si el sistema actual no permite representar una reclamación que atraviesa varios equipos, una capa de coordinación puede tener sentido.

La arquitectura no necesita copiar todos los datos del TMS. Puede guardar referencia y consultar eventos autorizados cuando se prepara una respuesta, dejando claro cuándo se actualizó cada dato. Si se conserva una copia para la cronología, debe existir una política de corrección cuando la fuente cambie. El modelo no puede resolver un problema de sincronización entre sistemas solo por leer ambos.

El primer despliegue debería mantener revisión humana de toda respuesta externa. Esa fase permite descubrir formulaciones ambiguas y casos de asociación incorrecta. Con evidencia suficiente, se podrían automatizar acuses o solicitudes muy delimitadas. Las decisiones sobre responsabilidad y compensación seguirían en el circuito competente.

Medir resolución, no volumen de correos

Un piloto puede empezar por un tipo de servicio y un buzón de reclamaciones. Probaría asociaciones fáciles y ambiguas, expediciones con varias entregas, correos duplicados y cambios de estado tardíos. Atención al cliente y tráfico marcarían los resultados correctos.

Mediría tiempo hasta primera respuesta útil, tiempo hasta resolución, reasignaciones, errores de asociación y correcciones de borradores. Un descenso del tiempo de respuesta que aumente las aclaraciones posteriores no es una mejora. La meta es que el equipo llegue antes al hecho comprobable y sepa qué debe comunicar en cada fase.

Para no confundir velocidad con calidad, mediría cuántos casos se reabren y por qué. Una reclamación marcada como cerrada puede volver porque apareció un POD, porque el cliente aportó fotos nuevas o porque la respuesta no atendía su pregunta. Cada motivo señala una mejora distinta: integración documental, política de cierre o redacción. Un número agregado de casos cerrados no muestra ese aprendizaje.

El piloto debe tener un procedimiento para los fallos del propio sistema. Si el buzón no se sincroniza, si el TMS deja de responder o si una respuesta preparada queda atascada, el caso debe seguir visible y asignado. No se debe asumir que ausencia de nuevos mensajes significa ausencia de actividad. Un responsable operativo necesita una forma sencilla de detectar y resolver esos fallos.

Cuando el flujo funcione, la empresa puede decidir si ampliar a otras clases de incidencias. Haría esa expansión por tipo de decisión y evidencia, no por volumen de correos: una solicitud de estado, un daño y una disputa de facturación pueden compartir buzón, pero tienen responsables, riesgos y criterios de cierre diferentes.

En cada ampliación comprobaría también la carga del equipo. Una clasificación más fina puede descubrir reclamaciones que antes no se registraban. El número de casos visibles podría subir sin que el servicio haya empeorado. La medida útil combina calidad de registro, tiempo de resolución y esfuerzo humano, y evita interpretar una cifra aislada como éxito o fracaso.