SLA de soporte TI: qué exigir y cómo comprobar que se cumple

«Soporte 24/7» y «atención inmediata» son frases que no comprometen a nada. Un SLA sí compromete, siempre que esté escrito de una forma que permita comprobar cada mes si se cumplió. Este artículo explica qué debe contener, qué trampas tiene la redacción habitual y cómo verificarlo sin depender de la buena voluntad del proveedor.

Lo primero: respuesta no es solución

Un SLA de soporte define cuánto puede demorar la respuesta a un caso: el tiempo en que alguien toma el problema y empieza a trabajarlo. No cuánto demora la solución, porque eso depende de qué se rompió — un disco que falla y una consulta sobre un permiso no se arreglan en el mismo tiempo.

Confundir ambas cosas es el origen de la mayoría de las discusiones entre cliente y proveedor. Un contrato que promete «solución en 4 horas» sin distinguir el tipo de problema, o está mal escrito o no se va a cumplir.

Lo que sí puede comprometerse sobre la solución es el tiempo de actualización: cada cuánto le informan del avance mientras el caso sigue abierto. Esa sí es una promesa que un proveedor controla.

Los tiempos deben variar según el impacto

Un SLA con un solo plazo para todo es un SLA mal diseñado. La clasificación mínima razonable distingue tres niveles:

• Crítico — la operación está detenida. Nadie puede trabajar, el sistema de ventas no responde, el servidor no arranca.
• Alto — hay degradación seria pero se puede seguir trabajando con dificultad.
• Normal — consultas, solicitudes y problemas que no detienen a nadie.

Y la clasificación debe estar definida en el contrato, no quedar al criterio de quien recibe el ticket. De lo contrario todo se vuelve «normal» cuando conviene.

Qué es razonable exigir

Para dar una referencia concreta: en nuestros contratos, una incidencia crítica tiene respuesta comprometida en menos de 1 hora, 24/7, todos los días del año. En la práctica suele estar entre 20 y 40 minutos. Una incidencia normal, en menos de 2 horas dentro del horario contratado.

Publicamos el techo, no el mejor caso. Un SLA existe para que el cliente pueda verificar cada mes si se cumplió, no para quedar bien en una propuesta comercial.

Las cinco trampas de la redacción habitual

1. «Horario hábil» sin definir

¿Empieza a contar el viernes a las 18:00 o el lunes a las 9:00? Si el contrato no lo dice, siempre se interpretará a favor de quien lo redactó. Exija el horario exacto y qué pasa con los festivos.

2. El reloj que arranca cuando el proveedor quiere

¿Desde cuándo se cuenta: desde que usted reporta, o desde que el proveedor «acepta» el ticket? Esa diferencia puede ser de horas. Debe contar desde el reporte.

3. 24/7 que en realidad es un buzón

Muchos «24/7» significan que puede escribir a cualquier hora, no que alguien conteste. Pregunte quién responde a las 3 de la madrugada, cómo se le contacta y qué pasa si no contesta.

4. Sin consecuencia por incumplir

Un SLA sin penalización es una declaración de intenciones. No hace falta que la penalización sea enorme — basta con que exista y sea automática, por ejemplo un descuento proporcional en la factura del mes.

5. Medido por el propio proveedor, sin acceso

Si el único que ve los tiempos es quien debe cumplirlos, no hay verificación posible.

Cómo verificarlo de verdad

Este es el punto que separa un SLA real de uno decorativo. Exija tres cosas:

1. Un sistema de tickets con fecha y hora de cada evento: reporte, primera respuesta, cambios de estado, cierre. Correos sueltos no sirven: no son auditables.
2. Acceso suyo a esos datos, no solo un informe que le llega ya resumido. Si puede exportar sus propios tickets, puede comprobar el cumplimiento sin pedir permiso.
3. Un reporte mensual con casos atendidos, cuántos dentro de plazo y cuántos fuera. Con el número, no con un «cumplimos».

La pregunta que lo resuelve en una frase: «¿puedo ver yo mismo los tiempos de mis tickets, o dependo de su informe?». La respuesta dice bastante.

Lo que un SLA no cubre y conviene saber

Un SLA de respuesta no garantiza disponibilidad del sistema. Son cosas distintas: el primero compromete al proveedor de soporte, el segundo depende de la infraestructura, de la conexión y a veces de terceros.

Si necesita compromiso de disponibilidad —el típico 99,x %— eso es otro acuerdo, se mide distinto y normalmente cuesta más. Mezclarlos en la conversación lleva a expectativas que nadie va a cumplir.

Tampoco cubre lo que está fuera del alcance contratado. De ahí que la pregunta «¿qué NO está incluido?» sea tan útil como la lista de lo que sí.

Una lista corta para revisar antes de firmar

• ¿Están definidos los niveles de gravedad, con ejemplos?
• ¿Hay un tiempo de respuesta por cada nivel, por escrito?
• ¿Desde qué momento corre el reloj?
• ¿Qué significa exactamente el horario de cobertura?
• ¿Hay tiempo de actualización mientras el caso sigue abierto?
• ¿Qué pasa si no se cumple?
• ¿Puedo ver los tiempos por mí mismo?
• ¿Qué queda fuera del alcance?

Ocho preguntas. Un proveedor que las responde sin rodeos probablemente cumpla; uno que se incomoda con la tercera o la séptima, probablemente no.

Puede ver cómo estructuramos estos compromisos en soporte TI externalizado, y cómo encajan dentro de un servicio completo de outsourcing informático. Si está armando el contrato desde cero, la guía de outsourcing informático cubre el resto de las cláusulas que conviene fijar.