SLA para agencias web: qué prometer a los clientes (y qué no)

Tarde o temprano llega el cliente que pregunta: "¿y vosotros qué SLA ofrecéis?". La reacción más habitual —buscar una plantilla en internet y adaptarla— es también la que más daño hace, porque las plantillas que se encuentran están escritas para proveedores de hosting y empresas de servicios enterprise, y contienen promesas que una agencia pequeña no puede cumplir.

Aquí hablamos de lo que puede prometer de verdad una agencia de tres, cinco o diez personas, y de cómo escribirlo para que aguante cuando llegue el incidente de verdad.

Qué es un SLA, en dos líneas

Un Service Level Agreement (acuerdo de nivel de servicio) es la parte del contrato que declara, de forma medible, el nivel de servicio prometido y qué ocurre si no se cumple. No es una promesa de calidad genérica ("atención rápida"): es un conjunto de cifras y plazos que, a final de mes, o se han cumplido o no se han cumplido. Si una línea no se puede comprobar con un dato, no es un SLA, es una tranquilización — y conviene tener clara la diferencia, porque el cliente las lee igual.

Por qué no copiar el SLA de un hosting enterprise

La plantilla que se encuentra online casi siempre promete un porcentaje de uptime. Merece la pena traducir esos porcentajes a minutos reales, en un mes de 30 días, es decir, 43.200 minutos:

Fíjate en la última fila. Prometer el 99,99 % significa comprometerse a que la web de un cliente esté inaccesible menos de cinco minutos al mes: un solo reinicio del servidor del hosting, un mantenimiento programado algo largo o una renovación de certificado que sale mal, y el mes está arruinado.

Y aquí está el punto que hace que todo el asunto carezca de sentido para una agencia: esa cifra no depende de ti. El uptime de la web depende del hosting, que en la mayoría de los casos elige y paga el cliente, y sobre el que no tienes ni control ni visibilidad. Estás prometiendo el comportamiento de la infraestructura de otro.

Además, un cliente pequeño no espera de verdad un 99,99 %: espera no ser el último en enterarse de que su web está caída. Es algo completamente distinto, y es algo que sí puedes prometer en serio.

Qué prometer en lugar del porcentaje: tres plazos

En lugar de una cifra que no controlas, declara tres que controlas por completo.

1. Tiempo de detección. En cuánto tiempo te das cuenta de que la web está caída. Es el compromiso más importante de los tres, porque es el único que cubre el periodo en el que el cliente todavía no sabe nada.

2. Tiempo de primera respuesta. En cuánto tiempo recibe el cliente un mensaje tuyo que le dice que ha pasado algo y que estás trabajando en ello. Primera respuesta, no resolución: depende solo de ti, y por eso se puede cumplir siempre.

3. Tiempo de intervención. En cuánto tiempo empiezas a trabajar en ello de forma concreta, con el horario de cobertura declarado al lado. Un tiempo de intervención sin franja horaria es ambiguo, y la ambigüedad en un SLA siempre juega en contra de quien lo ha escrito.

Los tres plazos conviene mantenerlos separados incluso cuando están próximos, porque fallan por motivos distintos: la detección falla si nadie estaba mirando, la primera respuesta si estás en una reunión, la intervención si el problema es de otro.

La detección es la promesa más fácil — pero solo con una herramienta

De las tres promesas, la detección es la más difícil de mantener a mano y la más fácil de mantener con una herramienta.

A mano, "detectamos una incidencia en un máximo de 15 minutos" exige que alguien abra esa web cada cuarto de hora, para todos los clientes, sábados incluidos. Ninguna agencia lo hace, y prometerlo por escrito es poner algo falso en un contrato. Con una monitorización automática, la misma frase pasa a ser la promesa más trivial del paquete: la comprobación se hace igualmente, ya sea de noche o el 15 de agosto.

La cifra que hay que escribir se calcula, no se inventa:

tiempo de detección declarado
  = intervalo de comprobación + tiempo de confirmación + margen

Con comprobaciones cada 5 minutos y una confirmación desde una segunda ubicación que tarda pocos segundos, la detección real se queda normalmente por debajo de los 6-7 minutos. Pero la cifra que va al contrato no es esa: es esa más el margen, es decir, 15 minutos. En un SLA se declara siempre el peor caso razonable, nunca el caso medio: un compromiso que se cumple todos los meses vale más que uno ambicioso que se cumple casi siempre.

Un párrafo de SLA que se puede escribir y es verdad

Un ejemplo completo, para una agencia de 3-5 personas sin guardia nocturna. Hay que adaptarlo, no copiarlo al pie de la letra:

Niveles de servicio — Monitorización y asistencia

Cobertura: de lunes a viernes, de 9:00 a 19:00, excepto festivos.

Detección: la web se comprueba automáticamente las 24 horas del día desde varias ubicaciones independientes. Una interrupción confirmada se detecta en un máximo de 15 minutos desde su inicio, a cualquier hora, también fuera del horario de cobertura.

Primera respuesta: dentro del horario de cobertura, el Cliente recibe una comunicación en un máximo de 60 minutos desde la detección, con lo que se sepa en ese momento y la hora de la siguiente actualización. Fuera de horario, en un máximo de 60 minutos desde el inicio de la primera franja de cobertura disponible.

Intervención: la labor de diagnóstico comienza en un máximo de 2 horas laborables desde la detección. Los tiempos de resolución dependen de la naturaleza del problema y no son objeto de compromiso cuando la causa es externa (hosting, registrador, proveedor de DNS, servicios de terceros).

Medición: los tiempos son verificables en el historial de incidentes, que recoge el inicio y el fin de cada interrupción y que el Cliente puede consultar en cualquier momento en la página de estado pública; bajo petición se facilita también en formato exportable.

Exclusiones: mantenimientos programados comunicados con al menos 48 horas de antelación; interrupciones causadas por modificaciones hechas por el Cliente o por terceros no encargados por la Agencia; incidencias del hosting o del proveedor de DNS, para las cuales la Agencia se compromete a la detección, la comunicación y la gestión del ticket, no a la resolución directa.

En caso de incumplimiento: si no se cumplen los plazos de primera respuesta o de intervención, el Cliente tiene derecho a un descuento del [10] % de la cuota mensual del mes afectado.

Cuatro cosas lo distinguen de una plantilla descargada: promete solo plazos que dependen de la agencia, declara el horario de cobertura en lugar de dejarlo sobreentendido, dice dónde se consulta el dato para poder verificarlo, y termina con una consecuencia pequeña pero real en lugar de una penalización aparatosa y teórica. Sobre este último punto: un descuento limitado y definido sobre la cuota es sostenible y, precisamente porque es creíble, se lee como seriedad. Una indemnización proporcional a la facturación que el cliente deja de ingresar no lo es para ninguna agencia pequeña, y prometerla sobre una web que genera pedidos es un riesgo sin ninguna proporción con la cuota que estás cobrando.

Los errores que se pagan

Prometer porcentajes de uptime. Es el más extendido: depende del hosting, no de ti. Si el cliente lo quiere por escrito, la formulación honesta es "el uptime de la web depende de la infraestructura de hosting; la Agencia detecta y documenta sus interrupciones".

Escribir 24/7 si no sois 24/7. Un cliente que a las dos de la madrugada descubre que "asistencia continua" quería decir "te llamamos mañana" pierde la confianza más deprisa que uno al que no le habías prometido nada para la noche. Eso sí, ten en cuenta que detección y cobertura pueden tener horarios distintos: el ejemplo de arriba promete detección 24/7 y respuesta de 9 a 19, y es una combinación honesta y sostenible.

No definir qué cuenta como "caída". Web inaccesible, web lenta, una sola página con error, checkout roto pero portada funcionando: son situaciones distintas. Si el contrato no lo dice, lo decidirá el cliente en el peor momento para discutirlo.

No decir quién mide. Sin una fuente de datos declarada, cualquier discusión sobre un plazo se convierte en tu palabra contra la suya.

Un SLA vale lo que valga el dato que lo demuestra

Las dos líneas más difíciles de todo el párrafo de ejemplo son la de la detección y la de la medición, y son difíciles por el mismo motivo: requieren un sistema que vigile las webs cuando en la agencia no hay nadie y que guarde registro de lo que ha visto.

Es lo que hace Statuo: comprobaciones continuas desde varias ubicaciones independientes, y una caída solo se declara cuando al menos dos ubicaciones la confirman — así el aviso que envías al cliente es un hecho, no una sospecha. Cada interrupción confirmada abre un incidente con hora de inicio y de cierre, que pasa al historial y a la página de estado pública con la marca de tu agencia (90 días de uptime diario, incidencias recientes con su duración); los datos se pueden exportar en CSV o JSON si necesitas adjuntarlos a una revisión de fin de año.

Es la diferencia entre un SLA que el cliente tiene que creerse por confianza y uno que puede comprobar por sí mismo — el único tipo que conviene escribir. La prueba gratuita dura 14 días, sin tarjeta de crédito: lo suficiente para activar la monitorización en las webs que llevas y fijar los tres plazos de tu SLA viendo lo que pasa de verdad, en lugar de estimarlos.

El resto del contrato —actualizaciones, copias de seguridad, seguridad, y cómo separarlos en partidas que el cliente sepa valorar— es el tema del artículo sobre qué incluir en un contrato de mantenimiento: el SLA es una de las cuatro familias, no todo el contrato.