La primera vez que aparece un SLA en un proyecto, normalmente es como anexo de un contrato que nadie va a volver a abrir. Una cláusula de '99,9% de disponibilidad', algunos párrafos genéricos sobre tiempo de respuesta, y listo, todos firman. Seis meses después, cuando el sistema se cae un feriado, resulta que nadie midió nada, nadie sabe si están dentro o fuera de la meta, y el cliente quiere respuestas que el contrato nunca obligó a tener.

Un buen SLA no es solo una cláusula. Es un sistema vivo de medición que orienta decisiones. Te muestro qué separa a los dos.

Qué hace que un SLA sea real

Un SLA que vale la pena tiene cuatro elementos que conversan entre sí. Un indicador medible de verdad, tipo 'tiempo hasta la primera respuesta' o 'uptime de la API', con fuente de datos confiable. Una meta clara junto con la ventana de medición: '99,5% de disponibilidad al mes'. El alcance: qué servicios están cubiertos y qué situaciones invalidan el acuerdo (mantenimiento programado, problemas en el proveedor de nube, etc.). Y qué pasa cuando la meta no se cumple: quién monitorea, quién actúa, cómo se le comunica al cliente. Si falta cualquiera de esos, el SLA vuelve a ser papel.

SLA, SLO y SLI: tres siglas, papeles distintos

Tres conceptos que confunden a todo el mundo al principio. SLI (Service Level Indicator) es el número bruto: 'porcentaje de solicitudes con éxito en los últimos 30 días'. SLO (Service Level Objective) es la meta interna que el equipo persigue, normalmente más exigente que el contrato: '99,9% interno'. SLA (Service Level Agreement) es el compromiso formal con el cliente, normalmente más conservador: '99,5% en el contrato'. La distancia entre SLO y SLA es el colchón que protege al equipo cuando algo sale mal.

Cómo construir un SLA que sostenga la operación

Empieza mirando la jornada del cliente, no el catálogo de servicios. Lo que le importa a él es el camino que lleva al valor. Si la página de producto carga pero el checkout se cae, el uptime del servidor no importa. Identifica los puntos donde una falla rompe la experiencia percibida y mide eso. Elige indicadores que se puedan recolectar automáticamente, en un dashboard compartido. Un indicador medido a mano se vuelve una discusión eterna sobre el número.

Define alertas que se disparan antes de que se rompa la meta, no después. Si la meta es 99,5% mensual, una alerta en 99,7% te da tiempo de reaccionar. Revisa el SLA con cadencia fija (trimestral funciona para la mayoría) ajustando a medida que el sistema crece. Y conéctalo al presupuesto: cuando se golpea el umbral inferior, ya existe una mejora priorizada en el backlog. Sin eso, un SLA roto se convierte en tema de reunión sin dueño.

“Un SLA que nadie mide en el día a día es solo una promesa que se va a volver excusa en el momento en que el sistema se caiga.”

Las formas más comunes de matar un SLA

Tratarlo como documento jurídico, sin nadie en la operación responsable por él, es el error número uno. Después viene negociar una meta agresiva para cerrar el contrato sin validar si la infraestructura aguanta. Después, medir el indicador a mano, generando retrasos y discusiones. Y por último, dejar al cliente sin visibilidad cuando algo se rompe. Un cliente que se entera de la violación por las noticias, y no por el equipo que le vende, pierde una confianza que difícilmente vuelve.

SLAs transparentes, medidos automáticamente y revisados con cadencia transforman la ansiedad contractual en ventaja competitiva. Quien mide todos los días entrega una confianza que se ve en el churn, en el NPS y en la conversación de renovación.