Cuando un cliente enterprise reporta una caída crítica de producción a las 3 de la mañana, el contador empieza a correr. Los tipos de SLA son los que determinan exactamente qué tan rápido debe responder tu equipo, qué plazo tiene para resolver el problema y qué consecuencias tiene no cumplir ese compromiso. Sin ese marco claro, todos los tickets compiten por la misma atención, y los más urgentes pierden.
La mayoría de los equipos de soporte aplican un único temporizador a todo su backlog y lo llaman “el SLA de la empresa”. El problema es estructural: cuando ese temporizador vence, el compromiso ya se rompió. El sistema avisa tarde y el equipo reacciona en lugar de prevenir.
En este artículo vas a ver todos los tipos de SLA que existen, qué distingue a cada uno, cómo se calculan correctamente tomando en cuenta horarios reales de operación y cómo elegir el modelo adecuado para tu organización.
¿Qué es un SLA y por qué existen diferentes tipos?
Un SLA, o acuerdo de nivel de servicio (Service Level Agreement), es un compromiso formal y medible entre un proveedor de servicios y sus clientes. Define qué tipo de servicio se ofrecerá, cómo se medirá y qué ocurre cuando no se cumplen los objetivos pactados. No es un documento burocrático: es el contrato operativo que convierte las expectativas del cliente en metas concretas para el equipo de soporte.
¿Y sabes qué? El problema no está en no tener un SLA. El problema está en aplicar el mismo SLA a todo, como si un ticket de emergencia crítica y una pregunta general de facturación merecieran el mismo nivel de urgencia. Ahí es donde entran los diferentes tipos de SLA: cada uno responde a una necesidad distinta de la operación.
Según la industria de gestión de nivel de servicio, un SLA bien construido debe especificar el alcance del servicio, la delineación de roles y responsabilidades, los parámetros de medición, la frecuencia de los reportes, los canales de escalación y las consecuencias por incumplimiento. Aplicar eso a toda la operación con un solo modelo es, en la práctica, inoperante.
“Un SLA no solo protege al cliente: también protege al equipo de soporte. Sin compromisos explícitos, los agentes trabajan bajo una presión indefinida que genera desgaste, rotación y errores operativos.”
— QuestionPro Customer Experience Team
En las organizaciones que ya superaron la etapa de “todos atendemos todo”, los tipos de SLA son la primera herramienta de diferenciación operativa. Permiten que el sistema decida automáticamente qué urgencia tiene cada ticket, cuánto tiempo tiene el equipo para responderlo y quién es responsable de escalarlo si el plazo se acerca.
Descubre cómo mejorar la productividad del equipo de soporte.
Los 3 tipos clásicos de SLA
La clasificación más extendida en la industria agrupa los tipos de SLA en tres categorías principales, según a quién o qué está dirigido el acuerdo. Cada modelo tiene ventajas claras y trade-offs igualmente claros.
SLA basado en el cliente
En este modelo, se establece un acuerdo independiente para cada cliente o cuenta. Todos los servicios que recibe ese cliente quedan cubiertos dentro de un único SLA personalizado que refleja sus necesidades específicas: tiempos de respuesta, niveles de disponibilidad, condiciones de escalación y consecuencias por incumplimiento.
Es el tipo de SLA más flexible. Si una cuenta enterprise necesita tiempos de respuesta de 15 minutos para incidentes críticos y soporte disponible las 24 horas, ese cliente tiene su propio SLA que refleja exactamente eso. Otro cliente del segmento PYME podría tener un SLA con tiempos de respuesta de cuatro horas en horario laboral, y eso es igualmente válido.
La contrapartida es la complejidad de gestión. A medida que crece la cartera de clientes, mantener SLAs individualizados eleva la carga administrativa, complica el reporte consolidado y puede generar inconsistencias en la forma en que se miden los indicadores clave de cada cuenta.
SLA basado en el servicio
Aquí el acuerdo se construye alrededor de un servicio específico, no de un cliente en particular. Todos los usuarios que consumen ese servicio quedan sujetos a las mismas condiciones y los mismos plazos, independientemente de quiénes sean o del tamaño de su cuenta.
El principal atractivo de este modelo es la simplicidad: un SLA, una forma de medirlo, un reporte consistente para todos. Funciona especialmente bien cuando el servicio es estandarizado y repetible, como soporte técnico de primer nivel, aprovisionamiento de accesos o gestión de dispositivos.
Su limitación más evidente: no distingue entre clientes. Un usuario de plan básico y un cliente enterprise con contrato premium reciben el mismo nivel de compromiso, lo que puede generar fricciones cuando hay diferencias reales en el valor estratégico de cada cuenta.
SLA multinivel
Este es el modelo más sofisticado, y también el más adecuado para organizaciones de soporte maduras. Combina elementos de los dos anteriores en una estructura jerárquica de tres capas que elimina redundancias y permite personalización sin sacrificar la consistencia operativa:
- Nivel corporativo: condiciones generales que aplican a toda la organización, independientemente del cliente o del servicio.
- Nivel de servicio: condiciones específicas para cada tipo de servicio ofrecido, que refinan las condiciones corporativas donde aplica.
- Nivel de cliente: ajustes particulares para cuentas individuales según sus necesidades contractuales o su nivel de prioridad estratégica.
El SLA multinivel elimina la redundancia: en lugar de repetir las condiciones generales en cada acuerdo individual, esas condiciones se definen una sola vez a nivel corporativo y se heredan hacia los niveles inferiores. Los niveles más específicos solo agregan o ajustan lo que es distinto para esa cuenta o servicio en particular.
Aquí está el detalle: este modelo requiere una plataforma de gestión que pueda aplicar las reglas de cada capa automáticamente. Sin esa automatización, la complejidad lo convierte en un dolor operativo mayor que los problemas que pretende resolver.
Los 3 tipos clásicos de SLA: comparativa
SLA basado en el cliente
Acuerdo único por cliente que cubre todos sus servicios. Máxima flexibilidad y personalización; mayor carga administrativa conforme crece la cartera.
SLA basado en el servicio
Un acuerdo por tipo de servicio, igual para todos los clientes. Simplicidad y consistencia en la medición, sin posibilidad de diferenciación por cuenta.
SLA multinivel
Estructura jerárquica de tres capas que combina condiciones corporativas, por servicio y por cliente. Elimina redundancias y requiere automatización para funcionar.
Tipos de SLA según el compromiso de respuesta
Más allá de cómo se segmenta el acuerdo, existe otra dimensión igual de importante: qué momento del ciclo de soporte cubre el SLA. No todos los compromisos terminan con la primera respuesta, y mezclarlos en un solo contador es uno de los errores más comunes en la gestión de soporte.
SLA de primera acción
El SLA de primera acción, también conocido como First Action SLA o SLA de primera respuesta, mide el tiempo que transcurre desde que se crea un ticket hasta que el equipo de soporte emite su primera respuesta o acuse de recibo al cliente.
Es el tipo de SLA más visible para quien reporta un problema. Cuando alguien abre un ticket, lo primero que quiere saber es que alguien lo leyó. Un SLA de primera acción incumplido genera la sensación de haber sido ignorado, incluso si el problema se resuelve en tiempo récord horas después.
Pero hay algo que los datos de soporte revelan constantemente: un equipo puede cumplir su SLA de primera acción de forma impecable y aun así fallar en la resolución. Eso ocurre todo el tiempo en operaciones que miden solo el primer contacto sin rastrear qué pasa después.
SLA de resolución
El SLA de resolución define el tiempo máximo desde la apertura del ticket hasta su cierre definitivo, con el problema solucionado. Es el compromiso más exigente porque requiere que toda la cadena de soporte funcione coordinadamente: triaje, diagnóstico, escalación si aplica y cierre confirmado con el cliente.
Lo más útil de rastrear ambos de forma separada es el diagnóstico operativo que habilita. Rastrear el ciclo de vida de un ticket en ambas dimensiones revela el cuello de botella real. Un ticket puede recibir respuesta en diez minutos y tardar cuatro días en resolverse. Otro puede demorar en la primera respuesta pero cerrarse en pocas horas. Sin la distinción, no sabes dónde está el cuello de botella real.
“Separar el SLA de primera acción del SLA de resolución es lo que permite a los equipos de soporte identificar si el problema está en la velocidad de respuesta o en la capacidad de diagnóstico y resolución. Son métricas distintas que revelan cuellos de botella distintos.”
— QuestionPro Research Team
En la práctica, la mayoría de las organizaciones que gestionan soporte B2B configuran ambos tipos en paralelo: el SLA de primera acción para manejar la experiencia percibida del cliente en las primeras horas del ticket, y el SLA de resolución para garantizar que el problema realmente se cierre dentro del plazo comprometido.
Tipos de SLA según la prioridad del ticket
Una vez definida la estructura del SLA y el tipo de compromiso, entra en juego la prioridad del ticket. Esta dimensión es la que convierte los SLAs en herramientas de triaje automático, eliminando la necesidad de que cada agente decida manualmente qué tan urgente es cada solicitud.
El modelo más extendido en soporte B2B categoriza los tickets en cuatro niveles de prioridad, cada uno con plazos diferenciados tanto para primera respuesta como para resolución:
Crítico
Afecta a múltiples usuarios o a funciones centrales del producto o servicio. Tiene impacto directo en producción, ingresos o seguridad. El SLA de primera acción para tickets críticos suele medirse en minutos, no en horas, y el SLA de resolución implica escalación inmediata a los niveles de soporte más especializados disponibles.
Alto
Problema que afecta a un usuario o a un flujo de trabajo importante, pero con impacto contenido. El cliente puede seguir operando con dificultad, pero el problema necesita atención antes del fin del día hábil. Plazos típicos: dos a cuatro horas para la primera respuesta, 24 horas para la resolución.
Medio
Incidencia que afecta la experiencia pero no bloquea la operación principal. El cliente puede continuar trabajando con limitaciones o con un workaround disponible. Plazos comunes: respuesta en cuatro a ocho horas, resolución en 48 a 72 horas hábiles.
Bajo
Consultas generales, solicitudes de información, mejoras no urgentes o preguntas de configuración que no generan impacto operativo inmediato. Plazos de respuesta y resolución más amplios, típicamente de varios días hábiles.
| Prioridad | Primera respuesta | Resolución | Ejemplo típico |
|---|---|---|---|
| Crítico | 15–30 min | 4 horas | Caída de producción que afecta a todos los usuarios |
| Alto | 2–4 horas | 24 horas | Funcionalidad importante afectada para un usuario |
| Medio | 4–8 horas | 48–72 horas | Error con workaround disponible |
| Bajo | 1–2 días hábiles | 5–7 días hábiles | Consulta general o solicitud de mejora |
La clave de este esquema no está solo en definir los plazos, sino en la asignación automática. Si cada agente tiene que decidir manualmente la prioridad de cada ticket, la clasificación va a ser inconsistente. Los sistemas modernos de gestión de SLA aplican reglas de calificación que asignan la prioridad, y con ella el SLA correspondiente, desde el momento exacto en que se crea el ticket, sin intervención humana.
El papel de los horarios de atención en el cálculo del SLA
Aquí está el punto que casi ningún artículo sobre SLAs menciona con claridad: el tiempo de un SLA no es tiempo de reloj. Es tiempo operativo.
Imagina que un ticket se crea el viernes a las 6 de la tarde. ¿El contador del SLA empieza en ese momento? Si tu equipo opera de lunes a viernes de 9 a 18 horas, no debería. El contador debería iniciar el lunes a las 9 de la mañana, cuando el equipo retoma operaciones. Si ese lunes es día festivo, el SLA debería excluir ese día del conteo.
Ahora bien, considera una organización global con equipos de soporte en múltiples zonas horarias o con semanas laborales no estándar (por ejemplo, domingo a jueves en ciertas regiones). Cada variante cambia completamente el cálculo. Lo que esto significa en la práctica:
- Un SLA de “respuesta en cuatro horas” en una operación de horario corrido no es igual que en una operación de horario hábil estándar de oficina.
- Los calendarios de festivos deben estar integrados al motor de SLA para que el conteo sea preciso y auténtico.
- Las semanas laborales regionales deben reflejarse en la configuración; de lo contrario, los reportes de cumplimiento serán engañosos.
- Si un cambio de política ocurre, los tickets históricos deberían conservar el SLA que estaba vigente cuando fueron creados, no recalcularse con la configuración nueva.
Sin esa capa de configuración, el reporte de cumplimiento de SLA se vuelve una métrica mentirosa. Un equipo puede parecer que incumple sus compromisos cuando en realidad está respondiendo correctamente dentro de su horario operativo real.
Cómo elegir el tipo de SLA correcto para tu operación
No hay un tipo de SLA universalmente superior. La elección depende de tres variables principales que determinan cuál modelo va a funcionar en tu operación específica.
El tamaño y heterogeneidad de tu cartera de clientes. Si atiendes a pocas cuentas enterprise con contratos diferenciados, el SLA basado en el cliente tiene sentido. Si atiendes a cientos de clientes con necesidades similares, el SLA basado en el servicio es más manejable. Si la variabilidad es alta y la escala también, el modelo multinivel es el camino natural.
La complejidad de los servicios que gestionas. Un único servicio estandarizado no necesita un SLA multinivel. Varios servicios con distintos niveles de criticidad y bases de clientes diversas sí lo necesitan, porque un solo acuerdo no puede capturar esa variabilidad sin volverse inmanejable.
La madurez de tu plataforma de gestión. El SLA multinivel solo funciona bien si la herramienta que usas puede aplicar automáticamente las reglas de cada capa y asignar el SLA correcto sin intervención manual. Sin esa automatización, la complejidad del modelo supera con creces sus beneficios.
Un momento antes de decidir: asegúrate de que tu equipo pueda responder esta pregunta con datos reales. ¿En qué porcentaje de tickets estás cumpliendo los compromisos actuales? Si no tienes esa visibilidad, cualquier modelo de SLA que implementes va a tener puntos ciegos importantes desde el primer día.
Métricas clave para medir el cumplimiento de cada tipo de SLA
Definir los tipos de SLA es solo la mitad del trabajo. La otra mitad es saber si los estás cumpliendo, y eso requiere métricas específicas que van más allá del conteo de tickets vencidos.
Las métricas más relevantes para un sistema de SLA bien configurado son:
- Tasa de cumplimiento del SLA de primera respuesta: porcentaje de tickets que reciben respuesta dentro del plazo pactado según su prioridad.
- Tasa de cumplimiento del SLA de resolución: porcentaje de tickets cerrados dentro del tiempo de resolución comprometido.
- Tasa de resolución en primer contacto (FCR): porcentaje de tickets resueltos sin necesidad de escalación o seguimiento adicional. Una FCR alta reduce la carga sobre el SLA de resolución.
- Tiempo promedio de primera respuesta (FRT): promedio real del tiempo que tarda el equipo en dar la primera respuesta. Permite comparar el rendimiento frente al objetivo del SLA.
- Tiempo promedio de resolución (ART): promedio real del tiempo de cierre de tickets. El contrapunto del SLA de resolución.
- Tasa de incumplimiento por prioridad: qué nivel de prioridad concentra la mayor cantidad de breaches. Revela dónde está el problema real.
- Tickets en riesgo de incumplimiento: número de tickets activos que están próximos a vencer su SLA. Esta es la métrica predictiva más valiosa porque permite actuar antes de que ocurra el breach.
Lo que separa a los equipos de soporte proactivos de los reactivos no es cuántos SLAs cumplen, sino cuántos breaches evitan antes de que ocurran. Y para eso necesitas visibilidad en tiempo real, no solo reportes post-mortem.
Conclusión
Los tipos de SLA no son categorías teóricas para documentos contractuales. Son las reglas del juego que determinan si tu operación de soporte es reactiva o proactiva, si los clientes sienten que los compromisos se cumplen o si se enteran de que algo salió mal después de que ya ocurrió.
Elegir bien entre un SLA basado en el cliente, uno basado en el servicio o un modelo multinivel, combinarlo con la distinción entre SLA de primera acción y SLA de resolución, aplicar prioridades diferenciadas por ticket y calcular los tiempos correctamente sobre horarios de operación reales: eso es lo que separa una gestión de SLA que funciona de una que solo parece funcionar en el papel.
¿Quieres saber cómo QuestionPro puede ayudarte a medir y mejorar la experiencia de tus clientes a partir del cumplimiento real de tus compromisos de servicio? Habla con nuestro equipo hoy.
Los tres tipos principales de SLA son: el SLA basado en el cliente (un acuerdo personalizado para cada cliente que cubre todos los servicios que consume), el SLA basado en el servicio (un acuerdo único para un tipo de servicio que aplica igual a todos los clientes) y el SLA multinivel (una estructura jerárquica de tres capas que combina condiciones corporativas generales, condiciones por servicio y ajustes individuales por cliente). La elección del modelo depende del tamaño de la operación, la variabilidad de los clientes y la complejidad de los servicios.
El SLA de primera respuesta mide el tiempo desde que se crea un ticket hasta que el equipo de soporte emite su primer acuse de recibo o respuesta al cliente. El SLA de resolución mide el tiempo total desde la apertura del ticket hasta su cierre definitivo con el problema resuelto. Rastrear ambos por separado permite identificar con precisión si los problemas de cumplimiento están en la velocidad de respuesta inicial o en la capacidad de diagnóstico y resolución del equipo.
Los horarios de atención afectan directamente el conteo de tiempo del SLA porque el tiempo de SLA es tiempo operativo, no tiempo de reloj corrido. Si un ticket llega fuera del horario laboral, el contador del SLA debe iniciar cuando el equipo retoma operaciones. Los calendarios de festivos, las zonas horarias y las semanas laborales no estándar deben estar integrados al motor de SLA para que el cálculo refleje el tiempo real disponible del equipo y evite reportes que sobreestiman los incumplimientos.
Un SLA multinivel es una estructura jerárquica de tres capas que combina estandarización y personalización en la gestión de niveles de servicio. La primera capa define condiciones generales para toda la organización; la segunda establece condiciones específicas para cada tipo de servicio; la tercera permite ajustes individuales para cuentas o clientes concretos. Este modelo elimina la redundancia de los acuerdos individuales y es especialmente útil para organizaciones con carteras de clientes diversas y múltiples líneas de servicio.
Diferenciar los SLA según la prioridad del ticket (crítico, alto, medio y bajo) es fundamental porque no todos los problemas tienen el mismo impacto operativo. Una caída de producción que afecta a todos los usuarios no puede tener el mismo plazo de respuesta que una consulta general. La clasificación por prioridad permite que el sistema asigne automáticamente el SLA correcto desde que se crea el ticket, sin depender de la decisión manual del agente, lo que reduce inconsistencias y garantiza que los compromisos más críticos reciban atención prioritaria.
