Elegir entre soporte 24×7 y 13×5 no es un debate “técnico”. Es una decisión de negocio: afecta a tu continuidad operativa, a tus riesgos (ciberseguridad incluida) y al coste real de cada incidencia.
El problema es que muchas empresas compran “horas de soporte” o firman un SLA genérico… y descubren demasiado tarde que ese SLA no cubre lo que su operativa necesita. Resultado: paradas más largas, improvisación, equipos tensionados y pérdidas que no aparecen en la factura del proveedor, pero sí en tu cuenta de resultados.
En este artículo aterrizamos cómo definir un SLA realista (sin pagar de más), cuándo tiene sentido 24×7 y cómo cuantificar el coste de no tenerlo, con un enfoque práctico para PYMES y empresas de +50 empleados.
24×7 vs 13×5: qué significa realmente (y qué no)
Cuando se habla de 24×7 (24 horas, 7 días) y 13×5 (habitualmente 13 horas al día, 5 días laborables), se suele pensar en “hay alguien disponible”. Pero un SLA serio no va solo de disponibilidad: define tiempos, prioridades, canales y responsabilidades.
En la práctica:
- 13×5: cobertura ampliada en horario laboral (por ejemplo, 08:00–21:00 de lunes a viernes). Es ideal cuando el impacto fuera de ese horario es bajo o asumible.
- 24×7: cobertura continua (incluye noches, fines de semana y festivos). Tiene sentido cuando hay sistemas críticos o negocio que no se detiene.
Importante: un SLA no garantiza que “se arregle todo en X horas”. Normalmente compromete tiempos de respuesta y tiempos objetivo de resolución por severidad, y establece el marco de colaboración (escalados, acceso, aprobaciones, etc.). Esto es coherente con cómo se describen los SLAs en buenas prácticas de service desk y acuerdos de nivel de servicio.
SLA “real” vs SLA “de papel”: los 6 puntos que debes exigir
Un SLA útil es el que reduce el tiempo total de incidencia y evita discusiones cuando todo va mal. Para lograrlo, el acuerdo debe concretar al menos estos puntos.
1) Alcance: qué entra y qué no entra
Aquí se decide si el soporte cubre solo usuarios y PCs, o también servidores, red, WiFi, firewall, Microsoft 365, copias, cloud, etc. Sin esto, el proveedor y el cliente pueden tener interpretaciones distintas.
Ejemplos de alcance bien definido:
- Puestos de trabajo, impresión, aplicaciones corporativas
- Infraestructura (virtualización, almacenamiento, redes, WiFi)
- Seguridad (EDR/XDR, firewall, VPN, filtrado, MFA)
- Servicios cloud (M365, Azure/AWS, SaaS críticos)
- Copias de seguridad y restauraciones
2) Severidades claras (P1–P4) con ejemplos
Si todo es “urgente”, nada lo es. Debes pactar severidades con ejemplos que todo el mundo entienda:
- P1 Crítica: negocio parado (ERP no funciona, caída total de red, ciberincidente activo).
- P2 Alta: negocio degradado (rendimiento muy bajo, caída parcial, muchos usuarios afectados).
- P3 Media: incidencia funcional con alternativa temporal.
- P4 Baja / petición: consultas, altas, cambios planificados.
Esto evita que un “no puedo imprimir” compita con “no puedo facturar”.
3) Tiempos medibles: respuesta, restauración y resolución
Un SLA serio distingue:
- Tiempo de respuesta: cuándo el equipo se hace cargo y empieza el diagnóstico.
- Tiempo de restauración (workaround): cuándo vuelves a operar aunque sea parcialmente.
- Tiempo de resolución: cuándo se corrige la causa raíz o se deja estable.
En muchas empresas, el “tiempo de restauración” es el que más valor aporta. De cara a continuidad, es clave.
4) Ventanas y exclusiones: mantenimiento, festivos y cambios
Si tu negocio trabaja sábados, o cierra a las 18:00, el SLA debe reflejarlo. También debe aclarar:
- Mantenimientos planificados (y su aviso)
- Festivos y puentes (si aplican)
- Cambios críticos (quién autoriza, cómo se coordina)
5) Canales y escalado: cómo se activa “lo urgente”
No es lo mismo “abre un ticket” que “hay un P1”. El SLA debería indicar:
- Teléfono de emergencia / canal prioritario para P1
- Reglas de escalado si no hay respuesta
- Contactos del cliente (responsables, autorizadores)
6) Responsabilidades compartidas (esto evita el 80% de bloqueos)
Un SLA falla cuando el proveedor no puede actuar por falta de acceso, permisos o decisiones. Pacta:
- Accesos remotos, credenciales y MFA
- Inventario y documentación mínima
- Tiempo de respuesta del cliente en P1/P2
- Aprobaciones para cambios urgentes
Esto está alineado con el enfoque de SLA como documento que fija objetivos y obligaciones de ambas partes.
Cuándo tiene sentido 13×5 y cuándo 24×7 (sin dogmas)
Aquí no hay una “respuesta correcta” universal. La clave es mapear tus procesos y dependencias.
13×5 suele ser suficiente si…
- Tu negocio opera principalmente en horario laboral.
- Si hay una caída por la noche, el impacto es bajo o asumible hasta la mañana.
- Tienes planes de contingencia claros (p. ej., operar con procesos manuales unas horas).
- Tus sistemas críticos no procesan pedidos, producción o atención fuera de horario.
24×7 suele ser necesario si…
- Vendes online o atiendes clientes fuera de horario.
- Tienes producción, logística o servicios “always-on”.
- Dependes de integraciones entre sistemas (ERP–WMS–ecommerce–transportistas).
- Un incidente de seguridad no puede esperar (ransomware, intrusión, compromiso de cuentas).
- Tu ventana de recuperación (RTO) es corta y te penaliza parar.
A menudo, la mejor decisión es un modelo híbrido: 13×5 para la mayoría de solicitudes, y 24×7 solo para P1/P2 sobre sistemas definidos como críticos.
“Cuánto cuesta no tenerlo”: cómo calcular el coste real de una parada
Hablar de coste de parada sin números hace que la decisión se tome “por sensación”. Si lo cuantificas, el SLA se convierte en una inversión fácil de justificar.
En estudios de referencia, se citan costes medios por hora muy elevados (especialmente en empresas grandes), y se insiste en que muchas organizaciones no miden bien el impacto. Úsalo como señal: si no lo mides, lo estás infraestimando.
La fórmula práctica (para PYMES) que sí funciona
Define primero el escenario: “caída de ERP + correo + acceso remoto” durante X horas.
Luego calcula:
- Coste por hora de personal parado
- (nº personas afectadas) × (coste/hora medio) × (factor de ineficiencia)
- Coste por hora de ventas/pedidos no procesados
- margen perdido o ventas diferidas (si se recuperan, no siempre es 0)
- Costes operativos
- horas extra para recuperar, logística reprogramada, penalizaciones
- Coste reputacional / atención al cliente
- difícil de medir, pero se puede estimar por tickets/quejas
- Riesgo y coste de seguridad (si aplica)
- respuesta a incidentes, forense, restauración, notificaciones, etc.
Ejemplo rápido (conservador):
- 25 personas afectadas, coste 25 €/h, factor 0,7 (no es 100% improductivo)
→ 25 × 25 × 0,7 = 437,5 €/h - Margen por pedidos no procesados: 300 €/h
- Recuperación y horas extra: 150 €/h
Total estimado: ~887 €/h
Una incidencia de 6 horas: ~5.322 €.
Si esto pasa 2 veces al año, ya estás en ~10.000 € de impacto “suave”. Y en sectores con dependencia total (industria, logística, sanidad), el coste real puede dispararse.
Esto conecta con la lógica de continuidad: identificar consecuencias de paradas y definir objetivos de recuperación realistas.
Por qué “tener soporte” no equivale a tener SLA
Aquí es donde muchas empresas se confunden:
- Un contrato por horas te da capacidad, pero no compromiso de tiempos.
- Un SLA te da prioridad, marco de actuación y objetivos por severidad.
- Un servicio gestionado (bien definido) además incluye prevención: monitorización, mantenimiento, parches, revisiones.
En otras palabras: el SLA reduce el riesgo de que el incidente “se te alargue” justo cuando más duele.
Si lo que buscas es continuidad, el camino lógico suele ser:
- Definir criticidad y dependencias
- Pactar SLAs por severidad (no “todo 24×7”)
- Añadir prevención (monitorización, parches, seguridad)
Cómo diseñar un SLA a medida: checklist en 30 minutos
Si necesitas una forma rápida de aterrizarlo internamente, usa este checklist.
Inventario mínimo de criticidad
- Sistemas críticos (ERP, correo, red, VPN, telefonía, ecommerce, backup)
- Horarios reales de operación (incluye picos: cierres, campañas, fin de mes)
- Dependencias externas (operadores, cloud, proveedores SaaS)
- Personas de guardia internas (si existen) y responsables de decisión
Objetivos de servicio (lo que vas a firmar)
- Severidades P1–P4 con ejemplos
- Respuesta, restauración y resolución por severidad
- Cobertura 13×5 / 24×7 por severidad y por sistema
- Canales y escalado
- Qué se mide y cómo se reporta (mensual/trimestral)
Condiciones para que funcione
- Accesos, documentación, inventario
- Ventanas de mantenimiento
- Plan de contingencia (aunque sea básico)
Esto te evita pagar 24×7 para “todo”, pero te permite garantizarlo donde importa.
El precio: por qué 24×7 cuesta más (y cómo optimizarlo)
Es normal que 24×7 sea más caro: implica guardias, rotaciones, capacidad de respuesta fuera de horario y, a menudo, una operación más madura.
Sin embargo, se puede optimizar mucho si:
- Delimitas claramente qué entra en 24×7 (solo P1/P2 y sistemas críticos).
- Mantienes 13×5 para P3/P4 y peticiones.
- Aseguras prevención (menos P1 = menos guardias “quemadas”).
- Acordáis responsabilidades del cliente para no bloquear diagnósticos.
En la práctica, el mayor desperdicio es contratar 24×7 “para todo” y usarlo como helpdesk nocturno. El mayor riesgo es lo contrario: contratar 13×5 sin plan de contingencia para sistemas que no pueden parar.
Recomendación para PYMES: el modelo que suele encajar mejor
Si buscas un punto equilibrado entre coste y continuidad, este esquema funciona muy bien en empresas de 50–200 empleados:
- 13×5 para soporte general y peticiones (P3/P4).
- 24×7 solo para:
- Incidencias P1/P2
- Sistemas críticos previamente definidos
- Monitorización y mantenimiento preventivo para reducir P1 reales.
Este enfoque está alineado con una estrategia de mantenimiento y soporte orientada a continuidad y operativa real, no solo a “resolver tickets”.
CTA: si quieres definir tu SLA sin pagar de más
Si estás replanteando tu soporte (o has sufrido paradas y quieres acotarlas), lo más rentable es revisar tu criticidad y pactar un SLA realista por severidad.
Puedes empezar por nuestros servicios de mantenimiento y soporte:
Mantenimiento 24/7 para empresas
Monitorización 24/7 para prevención de fallos
Mantenimiento informático: cómo garantizar la operatividad
Si necesitas que lo aterricemos a tu caso (horarios, sistemas críticos y objetivos de respuesta), podemos ayudarte a definirlo y dejarlo por escrito para que el SLA sea una herramienta de continuidad, no un documento decorativo.
Preguntas frecuentes sobre soporte 24×7 y 13×5
¿13×5 equivale a 8×5?
No necesariamente. 8×5 suele referirse a horario laboral estándar (8 horas, 5 días). 13×5 suele ser una franja más amplia dentro de días laborables. Lo importante es que el SLA indique horas exactas, zona horaria y festivos.
¿Un SLA garantiza que todo se resuelva dentro del tiempo pactado?
Normalmente garantiza tiempos de respuesta y objetivos de restauración/resolución según severidad, pero puede depender de terceros, de acceso, de aprobaciones o de piezas. Por eso es clave incluir responsabilidades compartidas y escalados.
¿Puedo contratar 24×7 solo para incidencias críticas?
Sí, y suele ser lo más eficiente. Se define qué sistemas entran, qué severidades activan 24×7 y qué canal se usa para P1/P2. Así no pagas guardia para peticiones que pueden esperar al día siguiente.
¿Cómo sé si el coste de 24×7 me compensa?
Calcula tu coste de parada con una fórmula simple (personal parado + margen perdido + recuperación + penalizaciones) y multiplícalo por el número de incidentes probables al año. Si una sola parada “seria” supera la diferencia de coste entre 13×5 y 24×7, ya tienes respuesta.
