Uptime en software de restaurante: qué exigir al proveedor

Un viernes a las 8:47 p. m. deja de funcionar la pantalla donde tu equipo captura pedidos. ¿Se cayó el proveedor, la red del local, una integración o solo una terminal? ¿Las comandas ya enviadas llegaron a cocina? ¿Se puede cobrar? ¿Qué deberá conciliarse cuando vuelva el servicio?

Esas preguntas importan más que una promesa aislada de uptime del software para restaurante. La disponibilidad útil no consiste en que un servidor responda: consiste en que una persona pueda completar un flujo crítico con datos correctos y dentro de un tiempo aceptable.

Esta guía, revisada el 19 de julio de 2026, explica cómo auditar esa disponibilidad, leer un SLA y preparar continuidad. No propone un porcentaje mínimo universal ni atribuye a Kavasoft una garantía, arquitectura o política de respaldo no documentada en tu contrato.

Respuesta corta

Dibuja el recorrido completo de pedido, cocina, cobro, reservación e inventario.
Define qué resultado medirás, desde qué punto y durante qué periodo.
Separa disponibilidad, atención del incidente, recuperación y pérdida de datos.
Revisa mantenimiento, exclusiones, dependencias, créditos y procedimiento de reclamo.
Exige historial y reportes de incidentes, no solo una cifra comercial.
Prueba el modo degradado y la reconciliación antes de necesitarlo.

Empieza por el flujo, no por la nube

La experiencia del restaurante atraviesa varios componentes. Un pedido puede depender de la terminal, la red local, internet, autenticación, aplicación, base de datos, integración con cocina e impresora. El proveedor podría considerar disponible su API mientras tu mesero no puede enviar una comanda.

La metodología de Google SRE para implementar SLO recomienda partir de las actividades críticas del usuario y dibujar componentes, solicitudes, datos y dependencias. También distingue la especificación del indicador de su implementación: medir desde registros del servidor no captura exactamente lo mismo que medir desde el dispositivo del usuario.

Adapta ese enfoque al restaurante con un mapa sencillo:

Flujo	Resultado correcto	Dependencias que debes probar	Alternativa temporal
Pedido en mesa	Cocina recibe una comanda íntegra una sola vez	Terminal, red, sesión, POS, KDS o impresora	Folio manual y mensajero designado
Cobro	Se autoriza o rechaza sin duplicar el cargo	POS, terminal, adquirente, red y conciliación	Política de cobro de contingencia autorizada
Reservación	Recepción ve disponibilidad y registra al cliente	Canal, motor, inventario de mesas y sincronización	Lista local mínima con sello de hora
Retiro de inventario	El movimiento queda ligado al artículo y responsable	Aplicación, catálogo, permisos y evidencia	Registro controlado para captura posterior
Cierre	Ventas, propinas, formas de pago y caja cuadran	POS, pagos, exportación y contabilidad	Corte provisional y conciliación al restaurar

Asigna a cada flujo un propietario operativo. No todo requiere la misma tolerancia: dejar de ver un tablero analítico durante treinta minutos no equivale a perder la capacidad de cobrar o de comunicar alergias a cocina. El nivel objetivo debe salir del impacto y de una alternativa viable, no de una regla genérica como “todo debe tener 99.9%”.

SLI, SLO, SLA, RTO y RPO no son sinónimos

Estas cinco siglas responden preguntas distintas:

SLI, indicador de nivel de servicio: qué observas. Por ejemplo, pedidos confirmados por cocina dentro del umbral acordado dividido entre intentos válidos.
SLO, objetivo de nivel de servicio: qué resultado busca el proveedor o tu operación durante una ventana definida.
SLA, acuerdo de nivel de servicio: qué compromiso contractual existe, cómo se calcula y qué remedio aplica si no se cumple.
RTO, objetivo de tiempo de recuperación: cuánto puede tardar en restablecerse un flujo después de una interrupción.
RPO, objetivo de punto de recuperación: cuánta información reciente podría ser necesario reconstruir tras recuperar datos.

El tiempo de primera respuesta de soporte tampoco es RTO. Un agente puede contestar en quince minutos y el flujo permanecer detenido durante horas. Pide por separado acuse, actualización, mitigación, restauración y cierre con causa o informe.

Para una medición útil, documenta numerador, denominador, umbral, ventana y fuente. Un SLI de pedidos podría ser: intentos válidos que llegaron completos a cocina en menos del umbral acordado, dividido entre todos los intentos válidos, medido desde la terminal del restaurante durante servicio. Aclara cómo se tratan reintentos, pedidos duplicados, lentitud y modo degradado.

Google SRE sugiere indicadores expresados como eventos buenos entre eventos totales y advierte que 100% no suele ser un objetivo razonable. También señala que disponibilidad, latencia, frescura, corrección, cobertura y durabilidad capturan problemas diferentes. Para el restaurante, un sistema que abre pero muestra una mesa o saldo desactualizado puede estar “arriba” y aun así producir una decisión incorrecta.

Qué significan realmente los “nueves”

La tabla siguiente es solo una conversión matemática. Supone medición continua, un mes de 30 días y un año de 365 días. El contrato puede excluir mantenimiento, servicios de terceros o incidentes fuera del control del proveedor; esas exclusiones cambian el tiempo que cuenta para el SLA.

Disponibilidad	Indisponibilidad en 30 días	Indisponibilidad en 365 días
99%	7 h 12 min	3 d 15 h 36 min
99.9%	43 min 12 s	8 h 45 min 36 s
99.99%	4 min 19 s	52 min 34 s
99.999%	26 s	5 min 15 s

No elijas el porcentaje más alto por reflejo. Pregunta qué evento se considera exitoso, quién mide, desde dónde, en qué zona horaria y con qué ventana. Una cifra mensual puede ocultar que todos los fallos ocurrieron en el servicio de cena. Un indicador basado en solicitudes puede ponderar más los periodos de alta actividad, pero debe acordarse de forma explícita.

Una disponibilidad compuesta también puede ser menor que la de cada componente. Que una plataforma opere en varias regiones no demuestra por sí solo que el recorrido terminal-red-aplicación-integración-pago funcione de extremo a extremo. La redundancia debe probarse en el flujo, incluido el cambio al componente alterno.

Cómo leer la cláusula de SLA

Subraya cada término definido. Si una propuesta solo dice “99.9% de uptime”, todavía faltan decisiones importantes.

1. Servicio y alcance

Identifica módulos, API, aplicación móvil, portal, sincronización y soporte incluidos. Pregunta si una degradación severa cuenta como indisponibilidad. Ver una pantalla no es suficiente si no se pueden guardar movimientos o si la cola tarda demasiado para operar.

2. Punto y método de medición

Aclara si el proveedor mide desde su balanceador, un monitor externo o el dispositivo del cliente. Define frecuencia de prueba, eventos excluidos y tratamiento de errores parciales. Conserva acceso al reporte que sustenta la cifra.

3. Ventana de cálculo

Confirma si es mes calendario, treinta días móviles, trimestre u otra ventana. Revisa zona horaria y horario cubierto. No conviertas horas de mantenimiento con una diferencia fija entre ciudades: el horario estacional puede modificarla. Exige horas locales y aviso previo.

4. Mantenimiento y exclusiones

Lista mantenimiento programado y urgente, fuerza mayor, configuración del cliente, conectividad local y servicios de terceros. Una exclusión demasiado amplia puede vaciar el compromiso. Pregunta además si una dependencia subcontratada tiene un compromiso compatible con el que te ofrecen.

5. Incidente y recuperación

Separa severidades, canal de apertura, disponibilidad del soporte, acuse, frecuencia de actualización, mitigación y restauración. Asegura un mecanismo de escalamiento. El horario debe corresponder a tu operación real; “24/7” no es un requisito universal si existe una alternativa aceptable, pero sí debe quedar claro qué sucede fuera del horario atendido.

6. Datos y sincronización

Pide saber qué se conserva localmente, qué queda en cola, cómo se evita duplicidad y cómo se resuelven conflictos al volver. Documenta RPO y RTO aplicables, exportación, restauración y evidencia de pruebas. Un respaldo protege frente a ciertos escenarios de pérdida; no vuelve disponible el servicio ni sustituye una ruta operativa.

7. Remedios y reclamo

Revisa crédito, límite, plazos, evidencia, forma de solicitarlo y si el remedio es exclusivo. Un crédito pequeño puede no compensar el impacto operativo. Evalúa también derecho a terminar, asistencia de salida y devolución o eliminación de datos. Esta lectura contractual requiere revisar tu orden, anexos y jurisdicción con asesoría competente.

Audita el historial antes de firmar o renovar

Una página de estado sirve si muestra los componentes que utilizas, historial suficiente, horas, actualizaciones y resolución. No la confundas con prueba completa: puede medir desde infraestructura del proveedor y omitir incidentes que solo afectaron a una región, versión o integración.

Solicita para un periodo comparable:

disponibilidad por componente y método de cálculo;
incidentes críticos y degradaciones relevantes;
hora de detección, comunicación, mitigación y restauración;
causa, impacto, acciones correctivas y seguimiento;
mantenimientos excluidos y dependencias responsables;
evidencia de que las acciones prometidas se cerraron.

La publicación NIST SP 800-61 Rev. 3, publicada en abril de 2025, integra preparación, detección, respuesta y recuperación dentro de la gestión de riesgo. Aunque no fue escrita específicamente para restaurantes, resulta útil para pedir un proceso continuo, no una reacción improvisada cada vez que aparece una alerta.

Compara ese historial con tus propios registros. Conserva hora local, dispositivo, flujo afectado, capturas sin datos personales innecesarios, folio de soporte y momento de recuperación. Si el proveedor declara disponibilidad pero tus terminales fallaron, la diferencia puede revelar un problema de medición, versión, red o integración.

Calcula impacto con tus datos, no con cifras virales

No existe una pérdida universal por hora. Un corte durante cierre, desayuno o viernes de cena produce efectos distintos; también importa si hay operación manual.

Modela al menos tres escenarios:

Impacto directo estimado = contribución de operaciones no recuperadas + horas adicionales + devoluciones o correcciones + costo de conciliación e incidente.

Usa margen de contribución cuando evalúes pérdida económica, no confundas ventas brutas con pérdida neta. Separa operaciones retrasadas de las canceladas: si una mesa paga después, el ingreso no se perdió aunque sí exista costo de espera. Añade errores de inventario, cargos duplicados, compensaciones y riesgo reputacional solo cuando puedas sustentarlos.

Luego compara ese impacto con prevención y recuperación: conectividad secundaria, batería, formularios, capacitación, monitor externo, soporte o un compromiso superior. No copies precios genéricos de internet o UPS; cotiza capacidad, autonomía, cobertura y mantenimiento para cada local.

Diseña un modo degradado verificable

“Funciona offline” puede significar desde consultar una caché hasta capturar pedidos y cobrarlos. Pide una matriz de funciones:

Pregunta de prueba	Evidencia esperada
¿Quién puede iniciar sesión sin red?	Roles y vigencia de la sesión documentados
¿Qué datos permanecen disponibles?	Catálogo, mesas, precios y última actualización visibles
¿Qué acciones se guardan localmente?	Pedidos o movimientos con folio y hora
¿Qué límites existen?	Funciones, dispositivos, tiempo y volumen especificados
¿Cómo vuelve la información?	Cola, reintentos, detección de duplicados y conflictos
¿Quién autoriza excepciones?	Responsable y umbral de escalamiento
¿Cómo se reconcilia?	Reporte de pendientes, errores y resultado final

Los pagos requieren una revisión específica con el adquirente. No asumas que una terminal offline autoriza realmente el cargo o elimina riesgo de rechazo, duplicidad y fraude. Documenta límites, almacenamiento, captura posterior, responsabilidad y procedimiento de conciliación conforme a tu contrato de pagos y a las reglas aplicables.

El simulacro debe comprobar roles, folios, comunicación, recuperación y conciliación; no solo que exista una carpeta de emergencia.

Crea un runbook de una página

El plan debe poder usarse bajo presión. La guía de contingencia NIST SP 800-34 Rev. 1 propone evaluar sistemas y operaciones para determinar requisitos y prioridades de continuidad. Traduce esa idea a una hoja por flujo:

Detectar: qué señal confirma el problema y quién descarta una falla local.
Declarar: quién activa contingencia y desde qué hora.
Comunicar: qué se dice a sala, cocina, caja, dirección y proveedor.
Operar: formulario, folio, responsable y límites del modo manual.
Proteger: qué datos personales o de pago nunca deben copiarse sin control.
Restaurar: quién valida que el flujo, no solo la pantalla, volvió.
Conciliar: cómo se capturan pendientes, detectan duplicados y cuadran caja e inventario.
Cerrar: evidencia, causa, aprendizaje, tarea y fecha responsable.

Guarda copias accesibles sin depender del sistema afectado. Mantén contactos, escalamiento y dispositivos actualizados. Para datos personales, usa cuentas autorizadas, control de acceso, cifrado y retención definida; no vuelques listas de clientes a una cuenta personal de almacenamiento “por si acaso”. En México, la LFPDPPP vigente, reformada por última vez el 14 de noviembre de 2025, exige un tratamiento legítimo, controlado e informado. La aplicación concreta depende de tus finalidades, avisos, contratos y medidas de seguridad.

Consulta también la guía de control de acceso por roles para limitar quién ejecuta, exporta y reconcilia durante la contingencia.

Respaldo, recuperación y disponibilidad cumplen trabajos distintos

Un respaldo no evita una caída. Puede reducir la información que debe reconstruirse después de corrupción, borrado o desastre, siempre que sea recuperable. Pregunta:

qué información entra al respaldo y qué queda fuera;
con qué frecuencia se crea y cuál es el RPO asociado;
cuánto tarda una restauración y cuál es el RTO aplicable;
quién controla llaves, accesos y ubicación;
cómo se verifican integridad y restauración;
qué evidencia reciente existe de una prueba;
qué ocurre al terminar el contrato.

No fijes “diario”, “semanal” o “cada seis meses” sin un análisis de impacto. La frecuencia correcta depende de cuánto dato puedes reconstruir y cuánto tarda la operación. La guía de backup de datos para restaurantes profundiza en copias, exportación y prueba de recuperación; la comparación SaaS frente a on-premise ayuda a ubicar responsabilidades compartidas.

Ejecuta un simulacro antes de la hora pico

Hazlo en un entorno seguro y acordado; no desconectes producción ni captures cargos reales sin autorización. Define alcance, criterio de aborto y observadores. Prueba una dependencia a la vez:

pérdida de internet principal y conmutación a la alternativa;
terminal que conserva sesión pero no sincroniza;
caída de impresión o KDS con pedidos en curso;
integración de pagos disponible pero POS degradado;
restauración con una cola que contiene reintentos;
conflicto entre una edición manual y otra remota.

Mide tiempo para detectar, declarar, continuar, restaurar y conciliar. Cuenta pedidos pendientes, duplicados, campos faltantes y acciones fuera del rol. Registra si el equipo entendió quién decidía. El objetivo no es “aprobar” al proveedor en una sola tarde, sino encontrar una falla controlada antes de encontrarla con el comedor lleno.

Después del ejercicio, asigna cada hallazgo: restaurante, proveedor, internet, pagos o integración. Repite solo cuando se corrija. Adjunta resultados a la revisión de renovación.

Checklist de renovación basado en evidencia

Qué pedir específicamente al evaluar Kavasoft

Kavasoft permite registrar inventario por miembro, movimientos, fotografías y trazabilidad dentro de su alcance confirmado. Eso no demuestra por sí mismo una integración nativa con tu POS, reservas o pagos, ni una garantía de disponibilidad, frecuencia de respaldo o tiempo de recuperación.

Antes de contratar o renovar, revisa la orden, plan, términos y anexos que realmente te apliquen. Pide por escrito alcance, medición, mantenimiento, soporte, incidentes, exportación, RTO, RPO y responsabilidades compartidas. Si tu operación necesita que otro sistema alimente o consuma información de Kavasoft, documenta esa integración y su comportamiento ante reintentos, duplicados y caída parcial.

La decisión madura no es comprar el número más alto. Es poder demostrar qué flujo se protege, cómo se mide, qué ocurre cuando falla y cómo vuelves a una operación íntegra.

Conoce Kavasoft y solicita la evidencia aplicable a tu operación