Ejemplos y plantillas de SLA

La mayoría de las personas que buscan una plantilla de SLA no intentan aprender qué es un SLA. Tienen una renovación en tres semanas, una mesa de servicio que incumple plazos que nadie acordó jamás, o un contrato con un proveedor con una hermosa cifra de disponibilidad y ninguna definición de cómo se mide la disponibilidad. Necesitan un documento para el viernes.

Por eso esta página es una biblioteca de artefactos: plantillas y ejemplos resueltos para cinco casos comunes, cada uno con las reglas de medición que deciden si el compromiso significa algo. Una meta sin una regla de medición es un deseo con un número pegado.

Datos clave: referencias de SLA que vale la pena tomar prestadas

• Amazon se compromete a un uptime mensual del 99.99% para EC2 a nivel de región y del 99.5% para una sola instancia, con créditos del 10%, 30% o 100% de los cargos afectados (AWS Compute SLA, 25 de mayo de 2022).
• Google Cloud se compromete al 99.99% para instancias de Compute Engine en múltiples zonas y al 99.9% para una sola instancia, pero el cliente debe presentar su reclamación en un plazo de 60 días para cobrar cualquier crédito (Google Compute Engine SLA).
• Microsoft establece los compromisos de soporte de Azure por severidad, no por uptime: menos de 1 hora, 24x7, para la Severidad A en un plan Standard, frente a menos de 8 horas hábiles para la Severidad C (Azure support).
• El 57% de los encuestados dijo que su interrupción mayor más reciente costó más de $100,000, y uno de cada cinco la situó por encima de $1 millón (Uptime Institute, 2026).
• Un SLA es un contrato "que incluye consecuencias por cumplir (o incumplir) los SLO que contiene" (Google SRE Book).

La anatomía de un SLA, cláusula por cláusula

Todo SLA utilizable responde las mismas doce preguntas. Las plantillas que omiten cuatro o cinco de ellas se firman rápido y se discuten después.

Dónde traza su línea esta página

La página complementaria, qué es un SLA y cómo establecer SLA internos, se ocupa del concepto: la definición, los tres tipos clásicos y un método de cinco pasos para acordarlos. Esta página le entrega, en cambio, las cláusulas y los números. Un caso deliberadamente no se repite: el acuerdo bilateral entre marketing y ventas ya existe como la plantilla de SLA entre marketing y ventas.

La lista de verificación de cláusulas

Las tres que más se omiten son el método de medición, los reportes y las causales de terminación, y son las que deciden si el acuerdo tiene dientes. Una sección posterior enumera en qué se convierte cada cláusula vaga.

SLA, SLO, SLI, OLA y el contrato de respaldo

Cinco términos se usan de manera intercambiable en las reuniones y significan cosas distintas en el papel.

La práctica SRE de Google ofrece la prueba que vale la pena robar: pregunte qué ocurre si no se cumple la meta, y "si no hay una consecuencia explícita, casi con certeza se trata de un SLO". También advierte contra el número perfecto, ya que "es tanto poco realista como indeseable insistir en que los SLO se cumplirán el 100% del tiempo" (Google SRE Book).

El vocabulario de los OLA viene de ITIL, ahora publicado por PeopleCert, cuyo esquema actual ya pasó de ITIL 4 a ITIL Versión 5. La idea sobrevive a cualquier edición: prometa una solución en cuatro horas cuando el equipo de bases de datos del que depende nunca ha acordado nada más rápido que un día, y habrá comprometido el calendario de otra persona.

Las definiciones de medición que deciden si un SLA es honesto

Dos organizaciones pueden operar metas idénticas y reportar un cumplimiento enormemente distinto, solo por las reglas del reloj. Resuelva esto por escrito antes de que alguien firme.

Pregunta	Redacción débil	Redacción defendible
¿Cuándo empieza el reloj?	"Al recibir la solicitud"	"En la marca de tiempo en que se crea el ticket en , incluidos los tickets que el proveedor abre en nombre del cliente"
¿Cuándo se pausa?	Se omite, o "mientras se espera al cliente"	"Solo mientras el ticket está en Pendiente del Cliente, con el tiempo pausado reportado por separado"
¿Horas hábiles u horas naturales?	"En 4 horas"	"En 4 horas hábiles, definidas como de 09:00 a 18:00 , de lunes a viernes, excluyendo "
¿Qué es una resolución?	"Ticket cerrado"	"Servicio restablecido y confirmado por el solicitante; una solución provisional cuenta solo para P3 y P4"
¿Cómo cuentan las reaperturas?	Se omite	"Un ticket reabierto dentro de días vuelve a su reloj original; el cierre anterior no se considera una meta cumplida"
¿Qué proporción debe cumplir?	"Todos los tickets"	"El 95% de los P1 y el 90% de los P2 por mes calendario, sobre todos los tickets creados ese mes"

Tres de ellas deciden la mayoría de las discusiones. Las reglas de pausa son la mayor palanca sobre una cifra de cumplimiento, porque un equipo que puede estacionar un ticket en Pendiente del Cliente y detener su propio reloj cumplirá cualquier meta que usted fije. Las horas hábiles cambian cada número de la tabla: cuatro horas hábiles en un calendario de 09:00 a 18:00 son casi 24 horas reales si la solicitud llega a las 17:30 de un viernes. Y las reaperturas halagan la cifra de resolución, ya que un cierre que el cliente reabre una hora después cuenta como una meta cumplida más un ticket nuevo. Dé seguimiento a la tasa de reaperturas como su propio KPI de proceso.

La disponibilidad requiere el mismo cuidado. El SLA de Compute Engine de Google cuenta solo "un período de uno o más minutos consecutivos de Tiempo de inactividad", de modo que "los minutos parciales o el Tiempo de inactividad intermitente durante un período de menos de un minuto no se contarán" (Google Compute Engine SLA). Un servicio puede oscilar durante cincuenta segundos a la vez, todo el mes, y reportar una disponibilidad perfecta.

La aritmética del uptime: lo que cuesta realmente cada nueve

Los porcentajes de disponibilidad son difíciles de sentir. Los minutos no. Cada cifra siguiente es (1 menos el porcentaje de disponibilidad) por la duración del período, usando un mes de 30 días y un año de 365 días.

Dos brechas importan al negociar. Entre el 99.5% y el 99.9% hay 2h 52m 48s al mes, la diferencia entre una interrupción que un equipo atiende con calma y una que consume una tarde. Entre el 99.9% y el 99.99% hay solo 38m 53s, pero ese salto suele obligar a un despliegue multizona y a un verdadero rol de guardias, así que es el costoso.

Como la mayoría de los SLA miden un mes calendario, la tolerancia también cambia con el mes: al 99.9%, febrero permite 40m 19s frente a 44m 38s en un mes de 31 días, con un compromiso idéntico.

Plantilla 1: SLA de incidentes de la mesa de servicio de TI

Esta es la plantilla que la mayoría de las organizaciones necesita primero, y la que más a menudo se copia sin su matriz de prioridades, que es la parte que hace el trabajo. La prioridad no es un campo que elige el solicitante. Se deriva del impacto y la urgencia, de modo que dos personas no puedan calificar la misma interrupción de forma distinta.

La respuesta y la resolución son compromisos separados y nunca deberían fundirse en un solo número. La respuesta es el momento en que una persona se hace responsable del ticket y lo dice; la resolución es el servicio restablecido. Un equipo puede ser excelente en una y desastroso en la otra, y un número combinado lo oculta.

Esos números son un punto de partida, no una referencia que deba copiarse a ciegas. Microsoft se compromete a menos de 1 hora para la Severidad A ("pérdida o degradación significativa de los servicios") 24x7 en un plan Standard o superior, y a menos de 8 horas hábiles para la Severidad C (capacidad de respuesta del soporte de Azure). Note qué es eso: una respuesta inicial, no una resolución.

SLA de gestión de incidentes, a 1. Alcance. Atención de incidentes para . Las solicitudes, los cambios y el trabajo de proyectos se rigen por . 2. Horario del servicio. Los P1 y P2 se atienden 24x7. Los P3 y P4 operan de 09:00 a 18:00 , de lunes a viernes, excluyendo . 3. Prioridad. Asignada a partir de la matriz anterior por en el triaje. Una recalificación no reinicia el reloj. 4. Metas. Conforme a la tabla de respuesta y resolución anterior. 5. Medición. Los tiempos se toman en desde la creación del ticket. El reloj se pausa solo mientras el ticket está en Pendiente del Cliente, y el tiempo pausado se reporta por separado. 6. Resolución. Servicio restablecido y confirmado por el solicitante, o 2 días hábiles sin objeción. Para P1 y P2, una solución provisional no es una resolución. 7. Reaperturas. Un ticket reabierto dentro de 5 días hábiles retoma su reloj original. 8. Exclusiones. Mantenimiento planificado notificado con días hábiles de anticipación, incidentes causados por sistemas controlados por el cliente o por los terceros designados en el Apéndice A, y eventos fuera del control razonable de . 9. Reportes. Cumplimiento por prioridad, la tasa de reaperturas y las tres principales causas recurrentes, publicados a más tardar el quinto día hábil de cada mes. 10. Escalamiento. Un P1 sin resolver al 50% de su meta de resolución escala a ; al 100%, a , quien se hace cargo de la comunicación con el cliente hasta el cierre. 11. Revisión. Trimestral, con la asistencia de . Las metas cambian solo por acuerdo escrito. 12. Falla repetida. No alcanzar el umbral de P1 durante tres meses consecutivos activa un plan de mejora del servicio.

La cláusula 8 contiene una regla: toda exclusión debe ser nombrada y verificable. "Fuerza mayor" es estándar; "problemas derivados de la complejidad del entorno del cliente" es una puerta de escape.

Plantilla 2: SLA de soporte al cliente

Un SLA de soporte se comporta de forma distinta. El número que más impulsa la satisfacción no es el tiempo de resolución sino el tiempo de siguiente respuesta, la espera entre respuestas una vez que la conversación está en marcha. Muchos equipos cumplen las metas de primera respuesta y aun así frustran a los clientes porque la segunda respuesta tardó dos días. Los canales también difieren, así que una sola meta combinada para chat y correo promete de más en uno de ellos.

SLA de soporte al cliente, a 1. Canales cubiertos. {Chat, correo, teléfono, in-app}. Las redes sociales y los foros de la comunidad se atienden en la medida de lo posible, sin compromiso. 2. Primera respuesta significa una respuesta humana sustantiva que aborde el problema específico. Un acuse de recibo automático no satisface esta cláusula. 3. Siguiente respuesta significa cada respuesta posterior mientras la conversación está abierta y a la espera de . 4. Reglas del reloj. El tiempo empieza cuando el mensaje llega a y se pausa solo mientras la conversación está en Esperando al Cliente. Una conversación que espera al cliente durante días se cierra automáticamente y se reabre con cualquier respuesta, retomando el reloj original. 5. Cumplimiento. Se mide mensualmente en el percentil {90}, no en la media. 6. Escalamiento y reportes. Toda conversación abierta más de veces su meta de resolución pasa a y a la revisión semanal. El cumplimiento por canal, la tasa de reaperturas y las conversaciones que incumplen por más de horas se publican mensualmente. 7. Exclusiones. Las integraciones de terceros designadas en el Apéndice A, las solicitudes de desarrollo a medida y el mantenimiento anunciado.

Dos decisiones ahí son deliberadas. Un percentil en lugar de una media evita que un promedio oculte las conversaciones de una semana de antigüedad que generan cada queja, y prohibir las respuestas automáticas como primera respuesta cierra la forma más común en que se manipula un SLA de soporte.

Ejemplo 3: un SLA de servicios compartidos internos y el OLA que lo respalda

Los SLA internos se redactan con la menor ceremonia y se incumplen con más frecuencia. Finanzas, RR. HH., legal y TI atienden a clientes sin contrato, sin créditos y sin proveedor alternativo, así que la única forma de hacerlos cumplir es la visibilidad y una reunión de revisión.

Cada meta de la columna de la derecha depende de alguien ajeno al equipo que se comprometió con ella, que es exactamente lo que cubre un acuerdo de nivel operativo. Sin el OLA, el equipo que sostiene el SLA visible absorbe cada retraso previo y deja de creer en la meta.

La segunda solución es definir una solicitud completa. La mayoría de los incumplimientos internos no se deben a trabajo lento, sino a trabajo que empezó tarde porque la solicitud llegó sin un código presupuestal. Ponga esa definición en un procedimiento operativo estándar, detenga el reloj hasta que la solicitud la cumpla y reporte los envíos incompletos junto al número de cumplimiento.

Cuando el flujo cruza departamentos, mapéelo primero: un mapa de procesos de negocio muestra los traspasos y las colas, y la brecha entre el tiempo de ciclo y el lead time le dice si la meta mide trabajo o espera. Conserve el acuerdo firmado junto con su documentación de procesos, no en una presentación.

Ejemplo 4: un SLA de proveedor, redactado desde el lado del comprador

Los SLA de proveedores llegan ya redactados, optimizados para el proveedor: exclusiones generosas, créditos que nadie reclama y una definición de medición escrita por la parte que hace la medición.

Qué exigir	Qué le ofrecerán	Por qué importa
Un sistema de registro designado y un método de medición	"Disponibilidad medida por "	Quien es dueño de la medición es dueño del resultado
Reportes mensuales publicados en una fecha fija	Reportes "a solicitud"	Un reporte no publicado es uno que nadie lee
Créditos aplicados automáticamente con los datos del propio proveedor	Créditos mediante reclamación escrita dentro de una ventana corta	Las ventanas de reclamación vencen, y el proveedor lo sabe
Análisis de causa raíz por escrito para cada severidad 1	Una explicación verbal en la siguiente llamada	Sin él, la misma interrupción se repite
Un tope mensual al tiempo de mantenimiento excluido	Mantenimiento ilimitado con aviso	El mantenimiento consume el compromiso
Aviso antes de que el proveedor modifique el propio SLA	"El Proveedor puede modificarlo publicando una actualización"	Su protección puede degradarse en silencio
Un derecho de terminación por falla crónica, definido numéricamente	Terminación por conveniencia, con aviso largo	Sin una salida, los recursos son decorativos

Dos cláusulas merecen capital de negociación. La primera es el disparador de falla crónica: "tres incumplimientos del compromiso de disponibilidad en cualquier período móvil de seis meses, o cualquier mes individual por debajo del 95%, facultan a para terminar sin penalización". Un proveedor que incumple cada trimestre y paga un crédito cada vez ha incorporado su tolerancia al precio del trato. La segunda es el tope de exclusiones, ya que el mantenimiento planificado solo es legítimo si está acotado, notificado y fuera de su horario laboral y no del del proveedor.

Ejemplo 5: un SLA de uptime en la nube, leído como debería leerlo un comprador

Los SLA en la nube son el mejor ejemplo resuelto, porque los principales proveedores publican los suyos completos. El compromiso de EC2 de Amazon, actualizado por última vez el 25 de mayo de 2022, es de un uptime mensual del 99.99% a nivel de región, es decir, instancias en múltiples zonas de disponibilidad, y del 99.5% para una sola instancia. La escalera de créditos es idéntica para ambos.

Someta esos compromisos a la aritmética anterior. El 99.99% a nivel de región permite 4m 19s en un mes de 30 días; el 99.5% a nivel de instancia permite 3h 36m. Es una diferencia de cincuenta veces entre dos números en la misma página, y se debe por completo a la arquitectura: si opera en una sola zona, habrá comprado la promesa más débil.

AWS también hace algo que vale la pena usar como referencia en otros contextos: "no le cobrará por ninguna Instancia EC2 Individual que esté No Disponible durante más de seis minutos de una hora de reloj", y esto "se aplica automáticamente y no necesita solicitar el crédito". El SLA de Compute Engine de Google se compromete al 99.99% para instancias en múltiples zonas en el nivel Premium y al 99.9% para una sola instancia de la mayoría de las familias de máquinas, con una banda intermedia más generosa del 25%. El inconveniente es la reclamación: "El Cliente debe notificar al soporte técnico de Google dentro de los 60 días desde que el Cliente pasa a ser elegible para recibir un Crédito Financiero".

Por eso compare las definiciones de medición antes que las cifras destacadas, verifique si el recurso es automático o se reclama, y traduzca cada porcentaje a minutos.

Créditos de servicio y por qué rara vez cubren la pérdida

Los créditos parecen una compensación y funcionan como una señal de gobernanza. Bajo el SLA de AWS "pueden aplicarse únicamente contra pagos futuros de Amazon EC2" y "no le darán derecho a ningún reembolso ni otro pago de AWS". Los de Google van a facturas futuras. Ambos acuerdos son explícitos en que este es todo el recurso: AWS "establece sus recursos únicos y exclusivos", el de Google "establece el recurso único y exclusivo del Cliente".

Ahora contrástelo con la pérdida. El análisis de interrupciones 2026 de Uptime Institute informa que "el 57% de los encuestados dijo que su interrupción mayor más reciente costó más de $100,000" y que "por segundo año consecutivo, 1 de cada 5 reportó costos superiores a $1 millón" (Uptime Institute). Un crédito del 10% sobre los cargos del mes afectado es un descuento modesto en la siguiente factura. La aritmética no está pensada para cuadrar.

Por eso trate los créditos como una señal, no como un seguro. Un proveedor que no respalda un número con un porcentaje significativo no cree en él. La protección real está en otra parte: la redundancia, los acuerdos de continuidad y un derecho de terminación por falla crónica.

Cómo hacer un SLA que sobreviva al contacto con la realidad

Un SLA firmado no cambia nada por sí solo. Los acuerdos que se sostienen tienen cuatro hábitos detrás.

Designe un responsable por acuerdo. No un comité, sino una persona cuyo trabajo incluya publicar el reporte y presidir la revisión. Un SLA sin responsable se degrada en silencio, porque incumplirlo no le cuesta nada a nadie hasta una renovación.

Ponga los números donde ocurre el trabajo. Una meta enterrada en una unidad compartida es invisible en el momento en que importa, que es cuando alguien toma el siguiente ticket. Las pantallas de cola y los tableros de equipo son gestión visual corriente, y un SLA que nadie puede ver es un SLA que nadie cumple.

Escale por un disparador, no por un estado de ánimo. Tome prestada la lógica del andon: cuando se cruza un umbral, se dispara una señal y responde una persona designada. Un P1 al 50% de su meta de resolución debería avisar al gerente de turno, piense o no el ingeniero que va mal.

Revise los incumplimientos buscando causas, no culpables. Aplique un análisis de causa raíz a los recurrentes y pruebe cada solución mediante un ciclo PDCA. El monitoreo continuo del proceso lo hace posible, ya que no se puede revisar lo que nadie instrumentó. Cuando el mismo paso manual causa el mismo retraso cada mes, la automatización de workflows en la recepción o el enrutamiento se amortiza más rápido que renegociar la meta, y estandarizar el proceso evita que un SLA signifique tres cosas en tres regiones.

Cómo se vuelven decorativos los SLA

La mayoría de los SLA muertos murieron de las mismas pocas maneras.

• Una meta que nadie mide. Si ningún sistema produce el número de forma automática, el número no existe.
• Exclusiones que se tragan el compromiso. El mantenimiento ilimitado, el "retraso causado por el cliente" sin acotar y un estado de pausa sin reglas vacían una promesa del 99.9% sin tocar la cifra destacada.
• Sin responsable y sin fecha de revisión. Ambos pertenecen al bloque de firmas, no al apéndice.
• Promedios en lugar de percentiles. Una media oculta la cola, y la cola genera las quejas.
• Metas copiadas de una empresa más grande. Una respuesta de P1 en 15 minutos no significa nada sin un rol de guardias.
• Un compromiso sin acuerdo encadenado. Una promesa que depende de un equipo que nunca acordó nada es un cheque contra la cuenta de otra persona.

Tome la plantilla que mejor encaje, complete los valores entre llaves y luego dedique el esfuerzo real al método de medición y a las exclusiones. Esas dos cláusulas deciden qué significa el acuerdo en el mes en que se ponga a prueba por primera vez.