SLA en Soporte Técnico: Cómo Definir Niveles de Servicio Efectivos

Cada vez que una empresa contrata soporte técnico —interno o externo— firma un acuerdo de niveles de servicio, o SLA (Service Level Agreement). En muchas ocasiones, ese documento termina en un cajón: lo firmaron, pero nadie lo revisa ni lo hace cumplir. En otras, el SLA es tan genérico que no sirve para gestionar ni evaluar al proveedor.

Un buen SLA de soporte técnico es una herramienta de gobernanza, no un formalismo contractual. En este artículo explicamos cómo diseñar uno que funcione, cómo medirlo y qué errores evitar.

¿Qué es realmente un SLA?

Un SLA es un compromiso medible sobre el nivel de servicio que el proveedor de soporte va a entregar. Debe responder, como mínimo, a estas preguntas:

• ¿Qué tipos de incidentes están cubiertos?
• ¿Cómo se priorizan?
• ¿En cuánto tiempo se responderá cada uno?
• ¿En cuánto tiempo se resolverá cada uno?
• ¿Qué pasa si no se cumple?
• ¿Cómo se mide todo esto y con qué frecuencia se reporta?

Si tu SLA actual no responde alguna de estas preguntas con claridad, está incompleto.

Métricas fundamentales

Tiempo de respuesta (Response Time)

Es el tiempo entre que se registra el incidente y el equipo de soporte acusa recibo y empieza a trabajarlo. No incluye resolución. Un buen SLA define tiempos de respuesta distintos por prioridad:

• Crítico (caída total del sistema): 15-30 minutos.
• Alto (funcionalidad mayor afectada): 1-2 horas.
• Medio (funcionalidad menor afectada): 4-8 horas.
• Bajo (consulta, mejora): 24 horas.

Tiempo de resolución (Resolution Time)

Es el tiempo total hasta cerrar el incidente. También varía por prioridad:

• Crítico: 2-4 horas.
• Alto: 8-24 horas.
• Medio: 2-5 días hábiles.
• Bajo: 10 días hábiles.

Estos son rangos típicos. Cada empresa debe ajustarlos a su operación y capacidad.

Disponibilidad (Uptime)

Para servicios críticos, el SLA debería definir un porcentaje de disponibilidad garantizada. Los niveles estándar son:

• 99% = hasta 87.6 horas de caída al año (3.6 días).
• 99.9% = hasta 8.76 horas al año.
• 99.99% = hasta 52 minutos al año.

Cada "nueve" adicional multiplica el costo del servicio. Una empresa mediana rara vez necesita 99.99%, salvo sistemas transaccionales críticos.

Tiempo medio entre fallos (MTBF)

Mide la estabilidad del sistema. Si tu soporte está "apagando incendios" todos los días, este indicador es crítico. Un proveedor maduro propone acciones de prevención que mejoren el MTBF mes a mes.

Tiempo medio de resolución (MTTR)

Es el promedio del tiempo que tomó resolver los incidentes en un período. No es lo mismo que el tiempo de resolución comprometido: es la realidad observada. Un proveedor que siempre resuelve en el límite de su SLA probablemente tiene un problema de capacidad.

Cómo categorizar incidentes

La categorización es el talón de Aquiles de muchos SLA. Si no está bien definida, se discute en cada incidente y los tiempos de respuesta se vuelven un debate.

Una categorización útil usa dos dimensiones:

Impacto

• Crítico: afecta a todos los usuarios o a un proceso crítico de negocio (facturación, ventas, producción).
• Alto: afecta a un grupo grande de usuarios o a un proceso importante.
• Medio: afecta a algunos usuarios o a un proceso secundario.
• Bajo: afecta a uno o pocos usuarios, sin bloquear.

Urgencia

• Inmediata: no puede esperar, hay pérdida activa.
• Alta: debe resolverse en el día.
• Media: tiene workaround, pero debe resolverse.
• Baja: no hay urgencia de tiempo.

Cruzando ambas dimensiones se obtiene la prioridad (crítico/alto/medio/bajo) que dispara los tiempos del SLA.

Lo que debe reportar el proveedor cada mes

Un SLA sin reporte es papel mojado. El proveedor debería entregar, como mínimo, un reporte mensual con:

1. Cantidad total de incidentes, por categoría.
2. Cumplimiento del tiempo de respuesta, por prioridad.
3. Cumplimiento del tiempo de resolución, por prioridad.
4. MTTR y MTBF del mes.
5. Uptime real de los sistemas monitoreados.
6. Top 5 de incidentes recurrentes con análisis de causa raíz.
7. Acciones de prevención propuestas o ejecutadas.
8. Compensaciones aplicables si hubo incumplimiento.

Si tu proveedor no entrega esta información, pídela. Si no puede generarla, probablemente no esté midiendo lo que debería.

Errores comunes al definir un SLA

Error 1: SLAs genéricos copiados de una plantilla

Un SLA válido para una empresa de manufactura no sirve igual para un fintech. La criticidad de los sistemas es distinta, los procesos de negocio también.

Error 2: Sin consecuencias por incumplimiento

Un SLA sin penalización es solo una aspiración. Las cláusulas más usadas incluyen descuentos automáticos sobre la mensualidad, créditos de soporte adicionales o, en casos graves, salida anticipada del contrato sin penalización.

Error 3: Tiempos irreales que generan fricción

Pedir que todo sea "crítico" con respuesta de 5 minutos lleva a un proveedor o bien a incumplir todo el tiempo, o bien a cobrar tarifas fuera de mercado. Los SLA funcionan cuando los tiempos están calibrados con la capacidad y el costo que la empresa está dispuesta a pagar.

Error 4: No incluir exclusiones explícitas

Incidentes causados por infraestructura de terceros (internet caído, fallas del proveedor de nube), ventanas de mantenimiento programadas o cambios iniciados por el cliente deben estar claramente excluidos del cómputo del SLA.

Error 5: Ignorar el ciclo de revisión

Un SLA debe revisarse al menos anualmente. Lo que era crítico hace dos años puede no serlo hoy, y viceversa.

SLA interno vs externo

Muchas empresas creen que el SLA es solo para proveedores externos. No es así. Un buen departamento de TI interno también debe tener un SLA con el negocio, o al menos un acuerdo de niveles operativos (OLA). Esto profesionaliza la relación, clarifica expectativas y da al equipo de TI una métrica objetiva de su desempeño.

Conclusión

Un SLA bien diseñado profesionaliza la relación entre el negocio y el soporte técnico. Hace visible lo invisible, convierte opiniones en números y permite tomar decisiones informadas sobre inversión, proveedores y capacidad. Sin SLA, el soporte técnico es una caja negra. Con un SLA bien hecho, es una palanca de gestión.

Si tu empresa opera con soporte técnico sin SLA, o con uno que nadie revisa, conversemos. En IT Efectivos ayudamos a diseñar, implementar y gestionar niveles de servicio efectivos que balancean cobertura, costo y realidad operativa.