Plantilla de SLA y OLA para soporte IT: cómo definir, negociar y medir acuerdos de servicio
Guía completa con plantillas y ejemplos prácticos para definir SLAs y OLAs en soporte IT: qué incluir, cómo negociar con el cliente, penalizaciones y cómo medir el cumplimiento.
Un SLA mal redactado es peor que no tener SLA: genera conflictos, erosiona la confianza del cliente y expone al proveedor a penalizaciones injustas. Un SLA bien construido, en cambio, alinea expectativas, facilita la medición objetiva del servicio y proporciona una base sólida para mejorar continuamente la calidad del soporte IT.
Estructura de una plantilla SLA para soporte IT
| Campo | Descripción | Ejemplo de valor |
|---|---|---|
| Alcance del servicio | Qué sistemas, aplicaciones y usuarios están cubiertos | Soporte L1/L2 para 150 usuarios, sistemas ERP y Microsoft 365 |
| Niveles de prioridad | Criterios de clasificación P1-P4 con ejemplos | P1: sistema crítico caído para todos los usuarios |
| Tiempo de primera respuesta | Plazo desde apertura del ticket hasta acuse de recibo con técnico asignado | P1: 15 min | P2: 1 hora | P3: 4 horas | P4: 1 día hábil |
| Tiempo de resolución | Plazo objetivo para cierre o workaround aceptado | P1: 4 horas | P2: 8 horas | P3: 3 días hábiles | P4: 10 días hábiles |
| Horario de cobertura | Días y horas en que aplica el SLA; qué ocurre fuera de horario | L-V 8:00-20:00 hora peninsular; P1 con guardia 24/7 |
| Exclusiones | Situaciones en que el tiempo de SLA no computa | Mantenimientos programados, caídas del proveedor cloud, incidentes causados por el cliente |
| Método de medición | Herramienta y proceso para calcular el cumplimiento | Datos extraídos de ServiceNow; informe mensual enviado antes del día 5 |
| Penalizaciones | Mecanismo de compensación por incumplimiento | Crédito del 5% de la cuota mensual por cada punto porcentual bajo el 95% de cumplimiento |
SLA vs OLA: cómo alinear los acuerdos internos con los compromisos externos
El OLA debe diseñarse antes que el SLA, no después. Si el equipo de L1 tiene 4 horas para resolver un P2, el OLA debe dejar 2 horas para L1 y 2 horas para L2 si necesita escalado. Si el equipo de sistemas tarda habitualmente 3 horas en resolver un problema de red, no puedes comprometer 4 horas al cliente incluyendo el tiempo de diagnóstico de L1.
La regla práctica: el SLA externo debe ser entre un 20% y un 30% más holgado que la suma de los OLAs internos. Ese margen absorbe la coordinación, los handoffs y los casos imprevistos. Si los OLAs internos ya están ajustados, el SLA externo será incumplible en cuanto aparezca un pico de demanda o un incidente complejo.
Cómo negociar un SLA con el cliente
La negociación de SLA no es una competición: el cliente quiere certeza, no números imposibles. Un cliente sofisticado preferirá un SLA alcanzable con historial de cumplimiento del 99% a uno aspiracional que se incumple el 20% de los meses. Los argumentos más efectivos en la negociación son los datos históricos propios y la transparencia sobre los factores que afectan los tiempos de resolución.
Aspectos a negociar: horario de cobertura (cada hora de extensión tiene coste), alcance de sistemas cubiertos, definición exacta de prioridades (el cliente tiende a clasificar todo como P1), y mecanismo de penalizaciones (preferible créditos de servicio a penalizaciones económicas directas).
Mejora de cumplimiento SLA con proceso estructurado
Métricas típicas tras implementar SLAs bien definidos con medición automatizada
Checklist de implementación SLA/OLA — Plan 90 días
Primeros 30 días — Definir la matriz de prioridades
- Analizar los últimos 6 meses de tickets: volumen por categoría, tiempos reales de resolución, distribución horaria.
- Definir la matriz de prioridades P1-P4 con criterios objetivos y ejemplos reales del cliente.
- Calcular los percentiles 85 y 90 de tiempos de resolución actuales por prioridad.
- Identificar los OLAs internos necesarios: qué equipos participan en la cadena de resolución y cuánto tiempo cada uno.
- Validar la viabilidad de los SLOs propuestos con el equipo técnico antes de presentarlos al cliente.
- Redactar el borrador de SLA y OLA usando la plantilla estándar con todos los campos obligatorios.
Días 31-60 — Firma y puesta en marcha de la medición
- Negociar y firmar el SLA con el cliente y los OLAs con los equipos internos involucrados.
- Configurar la herramienta de ticketing (ServiceNow, Jira Service Management, Freshservice) con las prioridades y SLAs definidos.
- Crear el dashboard de cumplimiento de SLA accesible en tiempo real para el equipo y el cliente.
- Configurar alertas automáticas cuando un ticket está al 75% del tiempo de SLA sin resolución.
- Establecer el proceso de reporte mensual: quién genera el informe, qué incluye, cuándo se envía al cliente.
- Formar al equipo en la clasificación de prioridades con casos prácticos y ejemplos.
Días 61-90 — Medición, reporting y revisión periódica
- Generar el primer informe mensual de cumplimiento SLA con datos reales y enviarlo al cliente.
- Realizar la primera reunión de revisión de servicio (QBR mensual o trimestral) con el cliente.
- Analizar los tickets incumplidos: causa raíz, patrón, acción correctiva documentada.
- Actualizar los runbooks de resolución para las categorías con mayor tasa de incumplimiento.
- Establecer el calendario de revisión anual del SLA con el cliente.
- Crear un proceso de mejora continua: cada incumplimiento SLA genera una acción de mejora rastreable.
Guías relacionadas
¿Necesitas ayuda para definir SLAs de soporte IT?
Nuestro equipo te ayuda a diseñar SLAs y OLAs realistas, negociarlos con tus clientes y configurar la medición automatizada del cumplimiento. Partimos de tus datos históricos para proponer compromisos alcanzables que refuercen la confianza de tus clientes.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Prueba de backup y restore con recuperación completa verificada.
- Revisión de parches críticos y cumplimiento de ventanas de mantenimiento.
- Ensayo de escalado L1/L2/L3 con tiempos reales.
- Validación de capacidad y salud de infraestructura bajo carga.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Conocer estabilidad y carga operativa actual | Analizar tickets, SLA y capacidad por sistema | Mapa de servicios críticos y deuda operativa |
| Hipótesis | Reducir incidencias repetitivas y tiempos de respuesta | Identificar top causas raíz y tareas manuales | Plan de automatización y mantenimiento preventivo |
| Validación | Mejorar soporte sin comprometer continuidad | Ejecutar pilotos con runbooks y guardias | SLA mejora y tickets reabiertos descienden |
| Escalado | Estabilizar operación de forma sostenible | Calendario operativo, KPIs y revisión semanal | Proceso repetible y auditado |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Cumplimiento SLA | Service desk | Semanal | >= 90% |
| Backups restaurables | Backup reports | Semanal | 100% pruebas críticas |
| Incidencias reabiertas | Ticketing | Semanal | < 20% |
| Disponibilidad de servicio | Monitoring | Diario | >= objetivo acordado |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Cumplimiento SLA | Service desk | Diario | >= 90% |
| Salud de backups | Backup platform | Diario | 100% jobs críticos con restore probado |
| Incidencia por causa raíz | Ticketing + postmortem | Semanal | Top causas en descenso mensual |
| Capacidad e infraestructura | Monitoring | Horario | Sin saturación en recursos críticos |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
Servicios críticos y deuda operativa identificados.
Runbooks y mantenimiento preventivo en marcha.
Mejora de SLA y reducción de reaperturas.
Operación estable y controlada por KPIs.
Riesgos que invalidan resultados
- Operar solo en modo reactivo y posponer mantenimiento preventivo.
- Medir SLA sin evaluar satisfacción y recurrencia de incidencias.
- No probar restauración real de backups pese a éxito del job.
- Escalados sin runbook y con dependencia de personas concretas.
Recomendaciones de implementación real
- Documentar runbooks por tipo de incidente y revisarlos mensualmente.
- Evitar mantenimiento reactivo: planificar tareas preventivas recurrentes.
- Definir ownership por sistema para reducir tiempos de diagnóstico.
- Alinear prioridades de soporte con impacto de negocio real.
Preguntas frecuentes que suele hacer un equipo técnico
¿Cómo reducir incidencias repetitivas en soporte IT?
Con análisis de causa raíz, automatización de tareas recurrentes y revisión mensual de los tickets más frecuentes.
¿Qué KPI de soporte conviene vigilar además del SLA?
Reaperturas, tiempo a diagnóstico, ratio de escalado y porcentaje de incidentes evitados por mantenimiento preventivo.
¿Cada cuánto probar restauración de backup?
Como mínimo mensual para sistemas críticos, y siempre tras cambios relevantes de arquitectura o política de respaldo.
Preguntas frecuentes
¿Cuál es la diferencia entre un SLA y un OLA?
El SLA (Service Level Agreement) es un acuerdo externo entre el proveedor de servicios IT y el cliente final, que define los niveles de servicio comprometidos públicamente: tiempos de respuesta, disponibilidad, tiempos de resolución. El OLA (Operational Level Agreement) es un acuerdo interno entre equipos dentro de la misma organización que soportan la entrega del SLA. Por ejemplo: el SLA con el cliente puede comprometer resolución en 4 horas, y el OLA interno define que el equipo de sistemas tiene 2 horas para escalar a nivel 2 si no ha resuelto. Los OLAs son los engranajes que hacen posible cumplir los SLAs.
¿Qué métricas debe incluir obligatoriamente un SLA de soporte IT?
Un SLA de soporte IT bien construido debe incluir: 1) Tiempo de primera respuesta por nivel de prioridad (P1/P2/P3/P4). 2) Tiempo de resolución objetivo por prioridad. 3) Disponibilidad del servicio de soporte (horario de atención, cobertura 24/7 si aplica). 4) Canales de soporte disponibles (teléfono, email, portal, chat). 5) Métricas de calidad: CSAT mínimo, tasa de resolución en primer contacto (FCR). 6) Método de medición y reporte. 7) Exclusiones explícitas (mantenimientos programados, fuerza mayor, problemas de terceros).
¿Cómo establecer valores de SLA realistas sin comprometer demasiado?
El error más común es comprometer tiempos de resolución aspiracionales sin datos reales. El proceso correcto es: 1) Analizar datos históricos de tickets de los últimos 6-12 meses por prioridad. 2) Calcular el percentil 85 del tiempo de resolución actual — ese es tu punto de partida. 3) Establecer el SLA en el percentil 90 de tu capacidad actual. 4) Planifica mejoras incrementales: comprometer en el contrato revisiones anuales al alza. 5) Distinguir entre tiempo de respuesta (fácil de cumplir siempre) y tiempo de resolución (depende de la complejidad). Nunca comprometas tiempo de resolución fijo para incidentes P1 sin cláusulas de fuerza mayor.
¿Qué ocurre cuando se incumple un SLA y cómo gestionar las penalizaciones?
El incumplimiento de SLA activa los mecanismos de remediación definidos en el contrato, que típicamente incluyen: créditos de servicio (descuentos proporcionales en la siguiente factura), escalado obligatorio a dirección, y en casos graves, derecho de resolución de contrato. La clave es que las penalizaciones sean proporcionales y calculables de forma automática, no discrecionales. Un SLA bien redactado incluye: umbral de incumplimiento (ej: cumplimiento mensual por debajo del 95%), fórmula de cálculo del crédito, proceso de reclamación y plazo de respuesta. Evita penalizaciones que no puedas pagar si las circunstancias te son adversas.
¿Con qué frecuencia se deben revisar los SLAs?
Los SLAs deben revisarse formalmente al menos una vez al año, y adicionalmente cuando: el volumen de tickets cambia significativamente (más del 30%), se incorporan nuevos servicios al alcance, cambia el equipo de soporte o la herramienta de gestión, o el cliente experimenta cambios en su negocio que afectan la criticidad del servicio. La revisión debe incluir análisis de cumplimiento histórico, encuesta de satisfacción del cliente, y propuesta de ajustes tanto en SLOs como en alcance. Documentar formalmente los cambios con enmienda al contrato o nuevo addendum.
Checklist FinOps AWS: 40 puntos para recortar tu factura
El mismo checklist que usamos en cada diagnóstico. Márcalo sobre tu cuenta AWS y sabrás dónde se te va el dinero.
- 40 puntos de revisión en 5 áreas
- Quick wins aplicables en 2–4 semanas
- El mismo checklist que usamos en los diagnósticos
¿Quieres aplicarlo con ayuda en IT Corporativo?
Si quieres priorizar quick wins y un plan ejecutable para tu equipo, podemos ayudarte con una sesión técnica de 30 minutos. Sin comerciales y sin compromiso.
¿Prefieres hacerlo por tu cuenta? Atlas Insight automatiza este análisis sobre tus cuentas AWS.