La hora sin cobertura: qué hace tu operación cuando falla la conexión

Un conductor entra en un túnel de carretera, en un muelle de carga subterráneo, en la cubierta de un ferry o simplemente en un valle con una sola antena débil que cubre tres pueblos, y durante cinco minutos o durante cuarenta el teléfono se queda sin cobertura. Esto no es un fallo del sistema ni un caso excepcional: es una parte normal de mover vehículos por geografía real, y cualquier operación que gestione más de un puñado de rutas se lo encontrará con regularidad. La pregunta interesante no es si ocurre. Es qué hace al respecto la aplicación instalada en el soporte del salpicadero, y qué hace la pantalla de despacho de vuelta en la oficina — y si alguien, más adelante en la cadena, puede distinguir entre «aquí no ha pasado nada» y «aquí ha pasado algo y todavía no lo sabemos».

Tres problemas distintos con un solo nombre

«Sin conexión» se usa como si fuera una sola condición, pero la aplicación del conductor pierde tres cosas separables cuando falla la señal, y las tres se comportan de forma distinta cuando la señal vuelve.

La primera es el estado que ya era local — la lista de paradas de hoy, la ruta, el manifiesto de carga del envío que va a bordo en ese momento. Nada de eso necesita una conexión en vivo para ser útil; necesita haberse descargado antes de entrar en la zona sin cobertura, lo cual es una cuestión de cuándo sincronizó la aplicación por última vez, no de qué hace mientras está sin conexión. Un conductor que consulta su próxima entrega dentro de un túnel está leyendo datos que llegaron hace una hora y no necesita nada más de la red.

La segunda es una acción que hay que registrar en el momento en que ocurre, coopere o no la red en ese instante. Una entrega se rechaza en la puerta. Un palet llega dañado. Una parada se cierra porque el destinatario ha firmado. Son hechos con una marca de tiempo, y esa marca es ahora, en la zona sin cobertura, no cuando vuelvan las rayitas de cobertura. Una aplicación que no puede registrar el hecho hasta que también puede comunicarlo le pide al conductor que espere al borde de la carretera o que confíe en su memoria para la versión que introducirá más tarde — y «lo apunto en cuanto tenga señal» es exactamente cómo un registro operativo se convierte en una reconstrucción.

La tercera es un flujo en vivo que no admite respuesta retroactiva — principalmente, dónde está el vehículo ahora mismo. La posición no es un dato que se pueda recuperar después en ningún sentido honesto: si un camión pasa dieciocho minutos dentro de un túnel, no hay una respuesta verdadera a «dónde estaba en el minuto nueve» más allá de «en algún punto del túnel, entre los dos puntos que lo delimitan». El comportamiento correcto aquí no es fabricar continuidad. Es mostrar la última posición conocida con su marca de tiempo y dejar que quien la observa saque la conclusión obvia, en lugar de interpolar en silencio una línea recta a través de roca sólida y presentarla como un dato real.

El registro y su prueba casi nunca coinciden en quién va primero

La mayoría de los eventos operativos no son una sola escritura de datos — son un registro más algo que lo respalda: una entrega más una firma, un rechazo más una foto, una inspección más sus fotografías del defecto. En una zona sin cobertura, normalmente solo uno de los dos puede escribirse en local y sin coste (el registro en sí, que pesa poco), mientras que el otro — una fotografía, en particular — pesa lo suficiente como para que «simplemente reintentar la subida» sea una espera real, no algo instantáneo.

Los dos eventos no quieren el mismo orden. Un registro de entrega que existe sin foto detrás es un pasivo pequeño, recuperable si alguna vez se cuestiona. Un conductor atascado en la puerta porque la aplicación se niega a marcar una parada como completada hasta que termine de subirse una imagen con una sola raya de cobertura es un problema mayor y más inmediato — la parada queda bloqueada, el conductor espera o busca un rodeo a la aplicación, y ese rodeo es exactamente cómo un proceso en papel vuelve a crecer, en silencio, dentro de uno digital. Así que el registro no debe esperar a que viaje su prueba; pero tampoco hay que tratar la prueba como carga opcional que da igual perder. Tiene que seguir intentándolo por su cuenta, en segundo plano, hasta que llegue o realmente se pierda — y si se pierde, eso tiene que ser visible para alguien, no tragado en silencio.

Pero ese orden no es universal, y esto es lo que vale la pena notar: para algunos eventos la prioridad se invierte. Un aviso de entrega fallida es, sin duda, más útil para la oficina sin foto alguna que no notificado en el momento en que ocurre, porque una parada fallida cambia cómo va a ser el resto del día — un reintento, una llamada al cliente, una replanificación del recorrido — y eso tiene que llegar a despacho antes que las fotos, si hay que elegir. Qué va primero no es algo que deba decidirse por defecto y por accidente, según qué llamada resulte más fácil de disparar primero en el código. Es una decisión sobre qué ausencia dolería más, tomada deliberadamente, una sola vez, por cada tipo de registro.

Un reintento no es automáticamente una repetición

El caso incómodo es aquel en el que en realidad nadie sabe qué ha pasado: la aplicación envió la petición, la conexión se cortó a mitad de camino, y no hay forma de saber, solo con el teléfono, si el servidor la recibió y no pudo responder, o si nunca llegó a verla. Reintentar a ciegas está bien para algo idempotente. No está bien para una acción que crea un registro nuevo cada vez que se llama — un segundo envío de «entregado» tras un tiempo de espera ambiguo puede leerse, para todo lo que viene después, como un segundo intento de entrega en lugar de la confirmación del primero. Un sistema honesto tiene que conservar esa distinción: «ha fallado con seguridad, se puede reenviar sin problema» es un estado distinto de «no lo sabemos», y este segundo merece más cautela — que una persona lo confirme antes de volver a intentarlo, en lugar de un reintento silencioso que podría duplicar sobre el papel un hecho real.

Trata las zonas sin cobertura conocidas como conocidas, no como incidencias

La mayor parte de esto se gestiona con previsión, no con ingenio. Si una ruta pasa cada semana por el mismo túnel o por la misma zona sin cobertura de tres pueblos, ese vacío no es una novedad — es una característica conocida del recorrido, y tratar diez minutos de silencio en ese tramo como una alarma en lugar de como algo esperado entrena a despacho para perseguir a los conductores por algo que no está mal. El hábito que vale la pena construir es conocer las propias zonas sin cobertura lo bastante bien como para distinguir «silencio por el túnel» de «silencio porque algo va realmente mal», lo cual sigue siendo una decisión de criterio que tiene que tomar una persona — pero que solo puede tomar bien si el sistema que tiene delante dice la verdad sobre lo que sabe y lo que no sabe en ese momento.

Dónde se sitúa navichain

La aplicación del conductor captura en el momento el estado de una parada, la firma, las fotos y el motivo de una entrega fallida, y las paradas del día, la navegación y el manifiesto de carga por parada ya están en el teléfono antes de que empiece la jornada — un conductor que trabaja su próxima entrega está leyendo un plan que ya estaba ahí, no uno pendiente de una descarga en vivo. La página de la plataforma recoge el resto de lo que funciona junto a esto: inspecciones diarias del vehículo que abren un parte de avería en cuanto algo falla, y datos de mercancías peligrosas acotados exactamente a la parada en la que se encuentra el conductor, de modo que la información que importa en la puerta no dependa de cómo esté la señal cuando la puerta se abre.