¿Qué sucede si se cae Internet, WhatsApp, el TMS o alguno de los sistemas conectados a Empliados?

Empliados utiliza integraciones con los sistemas y canales de comunicación de las empresas de transporte para consultar información, interpretar eventos y ejecutar tareas.

Por eso, si se interrumpe Internet, WhatsApp, el TMS, el ERP, el GPS o alguno de los servicios conectados, determinadas funciones pueden verse afectadas.

La consecuencia depende de qué sistema dejó de funcionar y de qué información necesita cada agente.

Por ejemplo, si el proveedor de GPS deja de enviar ubicaciones, los agentes que dependen de esa información pueden perder temporalmente la capacidad de detectar movimientos, detenciones o desvíos.

Si WhatsApp no está disponible, los agentes pueden quedar impedidos de enviar o recibir mensajes por ese canal.

Si el TMS deja de responder, puede no ser posible consultar los viajes programados o registrar novedades.

Eso no significa necesariamente que toda la plataforma deba dejar de funcionar.

Los agentes que utilizan otros sistemas disponibles pueden continuar realizando las tareas para las que tengan información y permisos suficientes.

Sin embargo, no corresponde asumir que una operación puede seguir funcionando normalmente cuando faltan datos críticos.

La prioridad es evitar que una falla tecnológica se convierta en una decisión operativa incorrecta.

¿Qué tipos de fallas pueden afectar a los agentes?

1. Caída de Internet en la empresa. Puede impedir el acceso de empleados a determinadas herramientas y servicios.
2. Interrupción de conectividad del chofer. Puede retrasar respuestas de WhatsApp o actualizaciones de seguimiento.
3. Caída del TMS. Puede impedir consultar viajes, asignaciones y estados.
4. Caída del ERP. Puede afectar procesos administrativos, facturación y cobranzas.
5. Interrupción del GPS. Puede dejar de proporcionar ubicaciones actualizadas.
6. Caída de WhatsApp. Puede impedir comunicaciones automáticas por ese canal.
7. Problemas con el email. Pueden demorar el envío o recepción de mensajes.
8. Fallas en servicios de llamadas. Pueden impedir contactos telefónicos automatizados.
9. API fuera de servicio. Puede bloquear consultas o actualizaciones de un sistema específico.
10. API demasiado lenta. Puede producir demoras o tiempos de espera agotados.
11. Límites de uso de APIs. Pueden impedir temporalmente nuevas solicitudes.
12. Credenciales vencidas. Pueden bloquear accesos previamente autorizados.
13. Permisos modificados. Pueden impedir acciones que antes estaban habilitadas.
14. Datos desactualizados. Pueden generar una visión incorrecta de la operación.
15. Información contradictoria. Puede dificultar la interpretación de estados.
16. Archivos inaccesibles. Puede impedir leer remitos o comprobantes.
17. Fallas de sincronización. Pueden provocar diferencias entre sistemas.
18. Interrupciones del proveedor de IA. Pueden afectar temporalmente el procesamiento de determinadas tareas.
19. Errores en una integración. Pueden impedir completar acciones o devolver información incorrecta.
20. Cambios técnicos no comunicados. Pueden afectar conexiones que funcionaban previamente.

Cada situación requiere una respuesta diferente.

Ejemplo concreto: se cae el TMS durante la mañana

Imaginemos una transportista que realiza 200 viajes diarios.

A las 8:00, el TMS deja de responder.

Empliados utiliza ese sistema para consultar los viajes programados y sus estados.

El agente de viajes intenta verificar qué unidades deberían haber comenzado sus recorridos.

Pero no consigue obtener información actualizada.

En ese escenario, no debería asumir que todos los viajes están demorados.

Tampoco debería enviar automáticamente mensajes a cientos de choferes basándose en una ausencia de datos que puede deberse a la caída del TMS.

Lo correcto es distinguir entre dos situaciones:

Una cosa es que el sistema confirme que un viaje no comenzó.

Otra muy distinta es que el sistema no pueda informar si comenzó.

Según la configuración y las capacidades de monitoreo disponibles, la falla puede registrarse y notificarse al responsable correspondiente.

Las tareas que dependen de información no disponible pueden quedar pendientes de verificación.

Cuando el TMS vuelve a responder, debe comprobarse qué información cambió durante la interrupción.

Por ejemplo:

• Qué viajes comenzaron.
• Qué viajes terminaron.
• Qué estados fueron modificados manualmente.
• Qué incidencias se registraron.
• Qué comunicaciones siguen siendo necesarias.

Antes de reanudar acciones, conviene validar que los datos sean actuales.

El objetivo es recuperar el trabajo pendiente sin duplicar mensajes ni modificar incorrectamente los registros.

¿Qué pasa si se cae WhatsApp?

Los agentes que utilizan WhatsApp pueden verse impedidos de enviar o recibir mensajes mientras el servicio no esté disponible.

Esto puede afectar procesos como:

1. Check calls.
2. Confirmación de salidas.
3. Consulta de demoras.
4. Solicitud de POD.
5. Rendición de gastos.
6. Comunicación con transportistas tercerizados.
7. Avisos a clientes.
8. Seguimiento de incidencias.
9. Confirmación de llegadas.
10. Recordatorios y seguimientos.

Las tareas pendientes pueden necesitar reprogramarse o escalarse según su importancia.

En determinados casos, la empresa puede utilizar otros canales habilitados, como email o llamadas.

Pero esa alternativa debe estar configurada y autorizada.

No debe asumirse que todos los procesos pueden cambiar automáticamente de canal.

Además, una interrupción puede dejar incertidumbre sobre si un mensaje fue enviado, recibido o respondido.

Por eso, al restablecerse el servicio, es importante verificar el estado real de las comunicaciones antes de reintentarlas.

¿Qué pasa si el GPS deja de actualizarse?

Cuando un proveedor de GPS deja de enviar posiciones, los agentes pueden perder visibilidad sobre la ubicación actual de determinadas unidades.

Eso puede afectar:

• Seguimiento de viajes.
• Detección de detenciones.
• Identificación de desvíos.
• Cálculo de ETA.
• Confirmación de movimientos.
• Alertas de llegada.

Es importante diferenciar una detención real de una falta de actualización.

Por ejemplo, si la última posición de un camión tiene 40 minutos de antigüedad, no corresponde afirmar automáticamente que el vehículo estuvo detenido durante 40 minutos.

Puede haber un problema de conectividad.

La información debe tratarse como desactualizada hasta obtener una nueva confirmación.

Según las reglas configuradas, el agente puede consultar al conductor por otro canal disponible o escalar el caso.

El objetivo es evitar conclusiones incorrectas basadas en información incompleta.

¿Qué pasa si el chofer se queda sin Internet?

Un conductor puede perder conectividad durante un recorrido.

En ese caso, sus mensajes pueden demorarse y determinadas fuentes de seguimiento pueden dejar de actualizarse.

Esto no significa necesariamente que exista una incidencia operativa.

La empresa puede definir reglas para distinguir entre falta de comunicación y una demora confirmada.

Por ejemplo:

"Si no se recibe una actualización durante 30 minutos, verificar si existe otra fuente de información antes de generar una alerta".

Si no hay información suficiente, el agente puede dejar constancia de la incertidumbre y aplicar el procedimiento configurado.

No debe inventar una ubicación ni confirmar una entrega sin evidencia.

¿Qué pasa si una API permite leer pero no escribir?

Puede ocurrir que un sistema permita consultar información, pero que una falla o cambio de permisos impida actualizar registros.

Por ejemplo, Empliados puede consultar el estado de un viaje y recibir una respuesta del chofer.

Pero si no puede registrar la novedad en el TMS, no debería afirmar que el sistema fue actualizado.

La acción puede quedar pendiente, registrarse como fallida o requerir intervención humana, según la configuración.

La diferencia entre recibir información y completar una actualización es fundamental.

Un agente no debe considerar terminada una tarea solamente porque intentó ejecutarla.

Debe poder verificar el resultado cuando el proceso lo requiere.

¿Cómo se evitan acciones duplicadas después de una falla?

Las interrupciones pueden generar un problema particular.

Un agente envía una solicitud, pero no recibe confirmación.

Entonces surge una duda:

¿La acción no se ejecutó o se ejecutó y falló solamente la respuesta?

Por ejemplo, el agente intenta registrar un gasto en el ERP.

La conexión se interrumpe.

Si vuelve a enviar la misma operación sin verificar, podría duplicar el registro.

Por eso, los procesos deben contemplar mecanismos de control.

Entre ellos:

1. Identificadores únicos de operaciones.
2. Verificación del estado antes de reintentar.
3. Registro de acciones iniciadas.
4. Confirmación de acciones completadas.
5. Límites de reintentos.
6. Detección de duplicados.
7. Validación de información actualizada.
8. Escalamiento de situaciones ambiguas.
9. Revisión de operaciones sensibles.
10. Auditoría de errores.

La implementación concreta de estos mecanismos depende de las capacidades de cada integración.

No todos los sistemas externos permiten el mismo nivel de control.

¿Los agentes pueden continuar trabajando si falla un solo sistema?

En algunos casos, sí.

Por ejemplo, una interrupción del GPS no necesariamente impide que un agente administrativo procese comprobantes de gastos recibidos por un canal disponible.

Una caída del ERP puede no afectar determinadas comunicaciones operativas que dependen exclusivamente del TMS y WhatsApp.

Pero hay que analizar las dependencias de cada proceso.

Si una tarea necesita consultar tres sistemas y uno de ellos está caído, puede ser necesario suspenderla.

El criterio es simple:

Un agente puede continuar cuando dispone de la información necesaria para actuar correctamente.

Cuando faltan datos críticos, debe evitar decisiones no fundamentadas.

¿Qué tareas deberían requerir más precauciones?

Especialmente aquellas que pueden generar consecuencias económicas, legales u operativas importantes.

Por ejemplo:

1. Emitir o modificar facturas.
2. Registrar pagos.
3. Aprobar rendiciones de gastos.
4. Modificar importes.
5. Confirmar entregas.
6. Cerrar incidencias sensibles.
7. Reprogramar viajes críticos.
8. Cambiar asignaciones.
9. Informar compromisos comerciales.
10. Comunicar situaciones de seguridad.
11. Actualizar datos bancarios.
12. Autorizar pagos a proveedores.
13. Registrar documentación obligatoria.
14. Ejecutar acciones irreversibles.
15. Modificar registros con efectos contables.

Estos procesos pueden necesitar verificaciones adicionales y aprobaciones humanas.

La autonomía debe configurarse según el riesgo.

¿Cómo se recuperan las tareas pendientes?

La recuperación debería considerar el estado real de cada proceso.

Por ejemplo:

1. Identificar cuándo comenzó la interrupción.
2. Determinar qué sistemas estuvieron afectados.
3. Identificar tareas que no pudieron completarse.
4. Verificar cuáles fueron ejecutadas parcialmente.
5. Consultar los datos actualizados.
6. Detectar acciones realizadas manualmente durante la falla.
7. Evitar duplicaciones.
8. Priorizar tareas urgentes.
9. Reanudar procesos cuando sea seguro.
10. Escalar casos ambiguos.
11. Registrar las acciones recuperadas.
12. Revisar errores posteriores.
13. Confirmar el cierre de tareas críticas.
14. Medir el impacto de la interrupción.
15. Ajustar reglas para futuras fallas.

No debe suponerse que todas las tareas pendientes pueden ejecutarse después de una caída.

Algunas pueden haber perdido sentido.

Por ejemplo, no corresponde consultar a un chofer si comenzó un viaje que ya terminó.

Antes de reintentar, debe revisarse el contexto actualizado.

¿Qué papel tienen los empleados durante una interrupción?

Los empleados siguen siendo fundamentales para supervisar la operación y resolver situaciones excepcionales.

Por ejemplo, pueden:

• Confirmar información por otros medios.
• Priorizar viajes críticos.
• Contactar a clientes importantes.
• Coordinar acciones manuales temporales.
• Resolver incidencias urgentes.
• Verificar registros.
• Autorizar reanudaciones.
• Revisar tareas pendientes.

Empliados busca reducir el trabajo manual repetitivo, no eliminar la necesidad de supervisión humana.

Cuando un sistema crítico deja de funcionar, puede ser necesario activar procedimientos de contingencia definidos por la empresa.

¿Cómo se mide la confiabilidad operativa?

Algunos indicadores útiles son:

1. Disponibilidad de las integraciones.
2. Cantidad de interrupciones detectadas.
3. Duración de cada interrupción.
4. Tiempo hasta identificar la falla.
5. Tiempo hasta notificar al responsable.
6. Tareas afectadas.
7. Tareas recuperadas.
8. Tareas que requirieron intervención humana.
9. Reintentos realizados.
10. Acciones duplicadas detectadas.
11. Errores de actualización.
12. Mensajes no entregados.
13. Datos desactualizados.
14. Tiempo de recuperación.
15. Impacto sobre los viajes.
16. Impacto sobre los clientes.
17. Costo administrativo de la contingencia.
18. Incidencias pendientes después de la recuperación.
19. Cumplimiento de procedimientos de seguridad.
20. Calidad de los registros de auditoría.

Estos indicadores ayudan a distinguir los problemas propios de los agentes de las fallas de los servicios externos.

¿Empliados garantiza que nunca habrá interrupciones?

No.

Ninguna plataforma que depende de Internet, APIs, servicios de mensajería y sistemas externos puede garantizar que todos esos componentes estarán disponibles permanentemente.

La disponibilidad concreta depende de la infraestructura, los proveedores y los acuerdos de servicio aplicables.

Por eso, la continuidad operativa debe abordarse mediante monitoreo, controles, procedimientos de recuperación y supervisión humana.

El objetivo es reducir el impacto de las fallas, no prometer que nunca existirán.

¿Cuál es el beneficio?

El principal beneficio de una operación correctamente configurada es que los agentes pueden realizar tareas automáticamente sin perder de vista las limitaciones de los sistemas que utilizan.

Empliados no reemplaza el TMS, ERP, GPS o WhatsApp.

Trabaja sobre ellos.

Por eso, cuando uno de esos componentes falla, es importante reconocer qué información dejó de estar disponible y qué acciones ya no pueden ejecutarse con seguridad.

Una demora confirmada no es lo mismo que un dato faltante.

Un mensaje enviado no es necesariamente un mensaje recibido.

Y una actualización solicitada no es necesariamente una actualización completada.

Estas diferencias son fundamentales para operar con agentes de inteligencia artificial.

La automatización no debería consistir en ejecutar acciones a cualquier costo.

Debería consistir en ejecutar el trabajo correcto, con información suficiente, permisos adecuados y controles proporcionales al riesgo.

Cuando falta información crítica, la respuesta correcta puede ser esperar, verificar o pedir intervención humana.

Cuando el servicio se restablece, la prioridad es recuperar el trabajo pendiente sin generar duplicaciones ni inconsistencias.

En definitiva, una operación automatizada necesita algo más que agentes capaces de actuar.

Necesita agentes capaces de reconocer cuándo no deben actuar.

Esa es una condición esencial para incorporar inteligencia artificial a procesos reales de transporte.

Conservá esta versión como aprobada y pasemos a la pregunta 68, también con un campo editable.