Cómo probar el modo offline

Offline debe describir funciones, no tranquilidad

Un TPV puede abrir artículos sin conexión y, al mismo tiempo, bloquear pagos, cambios de turno o facturas completas. Otro guarda pedidos localmente, pero requiere red para enviarlos a cocina. Decir «funciona offline» sin detallar acciones, duración y sincronización no permite decidir.

La continuidad también depende de arquitectura local, dispositivos y servicios externos. Delivery, reservas, adquirencia y copias pueden fallar de manera independiente. Los proveedores de hostelería como Last.app o Revo deben evaluarse con el montaje propuesto; su web no sustituye un protocolo de contingencia adaptado al local.

Un viernes sin fibra en un restaurante

A las 21:15 cae el acceso a internet con doce mesas abiertas. Camareros siguen tomando comandas, cocina necesita recibir modificaciones y varios clientes quieren pagar. El router vuelve cuarenta minutos después. El sistema debe evitar pedidos perdidos o duplicados y mostrar qué cobros quedaron pendientes.

El responsable decide de antemano qué operaciones permite durante la caída, cómo comunica al equipo y quién autoriza excepciones. También conserva medios alternativos legales para documentar la venta cuando una función no esté disponible. No se pretende prometer servicio perfecto, sino limitar decisiones improvisadas.

Simulación controlada de la incidencia

Realiza el ejercicio fuera del horario de apertura y con transacciones de prueba. Abre mesas, envía platos, anula uno, divide una cuenta y corta la conexión. Intenta continuar cada acción prevista. Restablece la red y revisa orden, marcas temporales, identificadores, duplicados, cierres y mensajes de error. No proceses tarjetas reales sin autorización del proveedor de pagos.

Valora alcance local, duración admitida, señal visual, cola de sincronización, resolución de conflictos, copia y soporte. Documenta qué dispositivo guarda la verdad durante el corte. Repite con caída del servidor local si esa arquitectura forma parte del sistema.

Caso límite: dos cajas modifican la misma mesa

Una caja sin red añade bebidas mientras otra, todavía conectada, cierra la mesa. Al sincronizar, aparecen dos estados incompatibles. La solución puede bloquear, fusionar o pedir decisión; cualquiera de ellos necesita ser comprensible y trazable. La resolución automática silenciosa es el peor resultado si elimina una venta.

En retail, el equivalente es vender la última unidad desde dos tiendas desconectadas. El sistema no puede impedir siempre el conflicto, pero debe identificarlo y ofrecer un procedimiento de corrección. Esa transparencia pesa más que una afirmación amplia de disponibilidad.

La simulación debe abarcar la vuelta gradual, no solo apagar y encender el router. Primero recupera una caja, después cocina y por último los conectores externos. Observa si el orden altera las colas. Guarda la hora de cada acción y compara con el registro del sistema. Un conflicto que aparece diez minutos después también pertenece al incidente.

Resultado exigible antes de abrir

El modo sin conexión es aceptable cuando las operaciones esenciales del negocio están enumeradas, el personal sabe los límites y la vuelta a red conserva trazabilidad. Descarta una propuesta que no permita simular la cola o que oculte qué servicios externos quedan fuera. Deja impreso un plan breve con responsables, acciones permitidas y reconciliación posterior. La resiliencia nace de una prueba conocida, no de un icono verde.

Repite el ejercicio tras una actualización importante y con cada nuevo dispositivo. La contingencia envejece cuando cambia la arquitectura, aunque el proveedor conserve el mismo mensaje comercial.