Cuando tu ERP se cae y llamas a tu proveedor de soporte, la respuesta que recibes define la diferencia entre un proveedor con SLA y uno sin él. Sin SLA escuchas: "En cuanto tengamos a alguien disponible te contactamos". Con SLA la respuesta es: "Tenemos 30 minutos para responderte y 4 horas para resolverlo — ya estamos trabajando en ello."
Un SLA no es un documento burocrático. Es tu póliza de seguro contra la indiferencia de un proveedor cuando más lo necesitas.
¿Qué es un SLA en términos simples?
SLA (Service Level Agreement) es un acuerdo que define tres cosas:
- Qué servicio recibes — alcance, horarios, canales de atención
- Con qué calidad — tiempos de respuesta, tiempos de resolución, disponibilidad
- Qué pasa si no se cumple — penalizaciones, créditos, derecho de cancelación
Es la diferencia entre una promesa verbal ("siempre estamos para ti") y un compromiso contractual con consecuencias medibles. Las promesas se olvidan; los SLAs se miden.
Las 5 métricas que todo SLA debe incluir
1. Tiempo de respuesta
Cuánto tiempo tarda el proveedor en acusar recibo de tu solicitud y asignar a alguien para atenderla. No es cuánto tarda en resolver — es cuánto tarda en empezar.
| Criticidad | Tiempo de respuesta recomendado |
|---|---|
| Crítico (sistema caído, operación detenida) | ≤ 30 minutos |
| Alto (servicio degradado, un área afectada) | ≤ 1 hora |
| Normal (incidente sin impacto operativo) | ≤ 4 horas |
| Solicitud (cambio, configuración, consulta) | ≤ 8 horas |
Cuidado con la respuesta automática
Muchos proveedores cumplen el "tiempo de respuesta" con un correo automático que dice "Recibimos tu solicitud, ticket #12345". Eso no es una respuesta real — es un acuse de recibo. Define en tu SLA que el tiempo de respuesta se cumple cuando un técnico real ha revisado el incidente y te comunica un diagnóstico inicial o plan de acción.
2. Tiempo de resolución
Cuánto tiempo tarda en resolverse el problema. Esta es la métrica que realmente importa — no cuánto tardan en contestar sino cuánto tardan en arreglar.
| Criticidad | Tiempo de resolución recomendado |
|---|---|
| Crítico | ≤ 4 horas |
| Alto | ≤ 8 horas |
| Normal | ≤ 24 horas (siguiente día hábil) |
| Solicitud | Según complejidad (definir por tipo) |
Resolución vs. workaround
A veces el problema tiene una solución definitiva que toma días (reemplazar un componente de hardware, por ejemplo) pero tiene un workaround que restaura la operación en minutos (activar el servidor de respaldo). El SLA debe medir el tiempo hasta que la operación se restaura (workaround), no hasta la solución definitiva. Define ambos tiempos si es necesario.
3. Disponibilidad (uptime)
El porcentaje de tiempo que el servicio está operativo. Se expresa como porcentaje mensual:
| Nivel | Uptime | Downtime permitido/mes | Downtime permitido/año |
|---|---|---|---|
| 99% | Básico | 7.3 horas | 3.65 días |
| 99.5% | Estándar | 3.65 horas | 1.83 días |
| 99.9% | Alto | 43.8 minutos | 8.76 horas |
| 99.95% | Muy alto | 21.9 minutos | 4.38 horas |
| 99.99% | Crítico | 4.38 minutos | 52.56 minutos |
Para la mayoría de las PyMEs, 99.5% a 99.9% es un nivel razonable. Cada "nueve" adicional multiplica el costo de infraestructura — 99.99% requiere redundancia total y sitio alterno, algo que solo se justifica para operaciones críticas.
La disponibilidad se mide con herramientas de monitoreo como Uptime Kuma, Zabbix o Pingdom — no con la percepción de "yo creo que se cayó unas horas este mes".
4. Cumplimiento de SLA
El porcentaje de incidentes que se atendieron dentro de los tiempos comprometidos. Un proveedor puede tener SLA de 30 minutos de respuesta, pero si solo lo cumple el 60% de las veces, el SLA no vale nada.
Nivel mínimo aceptable: 95% de cumplimiento mensual. Si tu proveedor está por debajo del 90% consistentemente, no está cumpliendo su compromiso y deberías activar las cláusulas de penalización o considerar un cambio.
5. Satisfacción del usuario
Después de cada ticket cerrado, una encuesta breve (1-5 estrellas o NPS) que mide si el usuario quedó satisfecho con la atención. Los tiempos pueden estar dentro de SLA pero si la solución no resolvió el problema o la atención fue mala, el servicio no está funcionando.
Cómo se estructura un SLA
Un SLA bien redactado tiene estas secciones:
Definición de niveles de criticidad
No dejes que el proveedor decida subjetivamente qué es "crítico". Define criterios objetivos:
- Crítico: El sistema es inaccesible para más del 50% de los usuarios O una función que detiene la operación (facturación, producción, despacho) no funciona.
- Alto: Un módulo o función específica no funciona pero existe un workaround temporal. Menos del 50% de los usuarios afectados.
- Normal: Incidente que no impacta la operación principal — un reporte que no carga, un permiso que falta, una impresora que no conecta.
- Solicitud: No es un incidente — es un cambio programado, una configuración, una consulta.
Horarios de cobertura
Define exactamente cuándo aplica cada nivel de SLA:
| Modalidad | Horario | Para qué |
|---|---|---|
| 8×5 | Lunes a viernes, 9:00 a 18:00 | Incidentes normales y solicitudes |
| 12×6 | Lunes a sábado, 8:00 a 20:00 | Empresas con operación extendida |
| 24×7 | Todos los días, 24 horas | Incidentes críticos y altos |
Lo más común para PyMEs: 8×5 para operación normal + 24×7 para incidentes críticos. No necesitas (ni deberías pagar) cobertura 24×7 para una solicitud de configuración — pero sí la necesitas cuando tu ERP se cae a las 11 PM antes de un cierre de mes.
Penalizaciones y créditos
El SLA sin consecuencias es una sugerencia. Define qué pasa cuando el proveedor no cumple:
Modelo de créditos (el más común):
| Cumplimiento de SLA mensual | Crédito en facturación |
|---|---|
| 95-100% | Sin crédito (cumplimiento normal) |
| 90-94.9% | 5% de descuento en la mensualidad |
| 80-89.9% | 10% de descuento |
| Menos del 80% | 20% de descuento + derecho de cancelación sin penalización |
Modelo de penalización por incidente:
- Cada incidente crítico resuelto fuera de SLA: crédito de $X MXN
- Cada incidente alto resuelto fuera de SLA: crédito de $Y MXN
- Incidentes críticos fuera de SLA 3 meses consecutivos: derecho de cancelación anticipada
Exclusiones
Define qué situaciones no cuentan como incumplimiento:
- Mantenimientos programados con aviso previo de 72+ horas
- Fallas del proveedor de internet del cliente (no del proveedor de soporte)
- Desastres naturales o eventos de fuerza mayor
- Cambios solicitados por el cliente que causan el problema
- Problemas en sistemas no cubiertos por el contrato
Las exclusiones deben ser razonables y acotadas — si las exclusiones son tan amplias que cubren todo, el SLA no protege nada.
SLAs que deberías tener (y probablemente no tienes)
SLA con tu proveedor de internet
- Disponibilidad mensual: 99.5% mínimo
- Tiempo de reparación: 4 horas para falla total
- Ancho de banda garantizado: 80% del contratado como mínimo
SLA con tu proveedor cloud (AWS, Azure)
AWS y Azure ofrecen SLAs publicados — EC2 garantiza 99.99%, RDS garantiza 99.95%, S3 garantiza 99.999999999% de durabilidad. Conócelos y verifica que tu arquitectura los aprovecha (instancias en múltiples zonas de disponibilidad).
SLA con tu proveedor de ERP
- Soporte: tiempos de respuesta y resolución para incidentes del sistema
- Actualizaciones: frecuencia de actualizaciones de seguridad y funcionales
- Disponibilidad (si es SaaS): uptime garantizado mensual
SLA interno de TI
Si tu empresa tiene un área de TI interna, un SLA interno profesionaliza su operación:
- Tiempo de atención para solicitudes de usuarios internos
- Tiempo de creación de cuentas para nuevos empleados
- Tiempo de restauración de archivos borrados
- Disponibilidad de sistemas administrados por TI
Cómo medir y exigir el cumplimiento
Un SLA que no se mide no existe. Estas son las herramientas y prácticas para asegurar que se cumple:
Herramientas de medición
- Sistema de tickets — Cualquier herramienta (GLPI, Zammad, Freshdesk) que registre hora de creación, hora de respuesta y hora de cierre de cada ticket
- Monitoreo de uptime — Uptime Kuma, Pingdom o StatusCake para medir disponibilidad de servicios
- Dashboard de SLA — Un tablero (en Grafana o en la herramienta de tickets) que muestre cumplimiento en tiempo real
Reportes mensuales
Exige a tu proveedor un reporte mensual que incluya:
- Total de tickets por criticidad
- Tiempos de respuesta y resolución reales vs. SLA
- Porcentaje de cumplimiento por nivel de criticidad
- Incidentes que excedieron el SLA con justificación
- Disponibilidad del mes con detalle de caídas
- Tendencias (¿el cumplimiento mejora o empeora?)
Reunión mensual de revisión
Una reunión de 30-60 minutos al mes donde revisas los reportes con tu proveedor, discutes incidentes relevantes, validas las acciones correctivas de los incumplimientos y ajustas prioridades para el siguiente período. Esta reunión es donde el SLA cobra vida — sin ella, el reporte se archiva y nadie actúa sobre los datos.
Cuándo renegociar el SLA
- Cuando tu operación cambia — Abriste una nueva sucursal, implementaste un nuevo sistema crítico, pasaste de 20 a 50 usuarios. El SLA debe reflejar la nueva realidad.
- Cuando el proveedor incumple repetidamente — Si el cumplimiento está por debajo del 90% tres meses seguidos, no es un problema puntual — es un problema estructural que requiere renegociación o cambio de proveedor.
- Cuando renuevas el contrato — La renovación es el momento natural para ajustar tiempos, coberturas y penalizaciones basado en la experiencia del período anterior.
- Cuando cambian tus prioridades de negocio — Quizás tu e-commerce creció y ahora necesita SLA de 2 horas en lugar de 8. O migraste a cloud y ya no necesitas soporte on-premise.
Un SLA es una inversión, no un gasto
El costo de un servicio con SLA es mayor que uno sin SLA — porque el proveedor está asumiendo un compromiso medible y debe tener la infraestructura (equipo, herramientas, procesos) para cumplirlo. Pero ese costo adicional es la diferencia entre "esperamos que alguien nos atienda" y "tenemos la garantía de que nos atienden en 30 minutos".
Cuando tu ERP se cae y cada hora de inactividad te cuesta $15,000 MXN, la diferencia entre un proveedor con SLA de 4 horas y uno que resuelve "cuando puede" son decenas de miles de pesos — mucho más que lo que cuesta el SLA.
Servicio con garantía
¿Tu proveedor de TI cumple lo que promete?
Te ofrecemos soporte con SLAs claros, monitoreo proactivo y reportes mensuales — para que tengas la certeza de que tu operación está protegida.
