¿Qué es un acuerdo de nivel de servicio (SLA)?
Cuando un cliente pregunta por qué su ticket tardó tres días en resolverse y tu equipo insiste en que eso es «rápido», tienes un problema de SLA. Para los responsables de operaciones y de soporte, la brecha entre promesas de servicio vagas y compromisos exigibles es donde suelen originarse las disputas, el riesgo de churn y las renovaciones perdidas. Tener claro qué es realmente un SLA y qué debe incluir es el primer paso para incorporar responsabilidad a tus relaciones de soporte o con proveedores.
Actualizado el
Un acuerdo de nivel de servicio (SLA) es un contrato entre un proveedor de servicios y un cliente que establece estándares de rendimiento específicos y medibles, como el tiempo de respuesta, el tiempo de resolución o la disponibilidad, junto con las consecuencias si no se cumplen. Los SLA eliminan la ambigüedad sobre lo que significa realmente «buen servicio» al convertir expectativas vagas en cifras que ambas partes aceptan. Para los equipos de SaaS y de soporte, un SLA es el mecanismo que hace que la responsabilidad sea exigible y no solo una aspiración.
Qué es un acuerdo de nivel de servicio en la práctica
Un SLA formaliza una promesa. En lugar de que un proveedor diga que el soporte será «rápido», el SLA establece el compromiso exacto: los SLA son acuerdos formales que definen los estándares de servicio esperados, incluidas métricas como el tiempo de respuesta y el tiempo de resolución, de modo que tanto el proveedor como el cliente tengan claros los parámetros de rendimiento que deben cumplirse.
Esto importa porque «rápido» significa algo distinto para cada persona en la sala. Para un responsable de soporte, una respuesta el mismo día es rápida. Un comprador enterprise que renueva un contrato de seis cifras espera una respuesta en menos de una hora. El SLA resuelve ese desacuerdo antes de que se convierta en una disputa. Un acuerdo de nivel de servicio es un compromiso formal con tiempos de respuesta y resolución concretos, y genera responsabilidad al establecer expectativas claras tanto para el equipo como para el cliente.
Los SLA no son exclusivos del soporte al cliente. Los servicios de TI, la infraestructura en la nube, los traspasos de marketing a ventas y los proveedores de servicios gestionados los usan para definir qué significa «entregado». Lo que se mantiene constante en todos los contextos es la estructura: un objetivo medible, una forma de hacerle seguimiento y una consecuencia cuando no se cumple.
Los componentes clave de un buen SLA
La mayoría de los SLA, sea cual sea el sector, se construyen con los mismos elementos básicos. Omitir cualquiera de ellos suele ser lo que convierte un acuerdo claro en una fuente de disputas más adelante.
- Tiempo de respuesta: la rapidez con la que el proveedor confirma la recepción de una solicitud.
- Tiempo de resolución: cuánto se tarda en resolver por completo el problema, no solo en acusar recibo.
- Disponibilidad o uptime: el porcentaje de tiempo en que se espera que un servicio esté operativo, a menudo expresado como 99,9 % o similar.
- Ruta de escalado: qué ocurre, y quién interviene, cuando hay riesgo de no cumplir un objetivo.
- Penalizaciones o créditos de servicio: la compensación que se debe al cliente si se incumplen los compromisos.
- Frecuencia de revisión: cada cuánto se revisa y se ajusta el propio SLA.
El tiempo de respuesta mide la rapidez con la que se atiende una solicitud, mientras que el tiempo de resolución es el que se tarda en resolver la consulta o el problema del cliente. Es importante tratarlos como dos métricas distintas. Un equipo puede cumplir su objetivo de tiempo de respuesta enviando un acuse de recibo rápido mientras el problema de fondo sigue sin resolverse durante días. Los buenos SLA miden ambos, no solo el más fácil de cumplir.
¿Cuáles son los principales tipos de SLA?
No todos los SLA son iguales, y la estructura adecuada depende de cuántos clientes atiendes y de lo diferentes que sean sus necesidades.
Los SLA basados en el cliente se negocian con una única cuenta, algo habitual en acuerdos enterprise donde el valor del contrato justifica condiciones a medida, como una ventana de respuesta dedicada o un account manager asignado.
Los SLA basados en el servicio aplican un único estándar a todos los clientes que usan un servicio concreto, independientemente del tamaño de la cuenta. Funciona bien cuando el servicio no varía mucho entre clientes.
Los SLA multinivel combinan estos enfoques. Los equipos suelen adoptar una estructura multinivel para evitar duplicidades y reducir la frecuencia de las actualizaciones, normalmente dividida en un nivel corporativo que cubre a todos los clientes, un nivel de cliente que cubre una cuenta concreta y un nivel de servicio que cubre servicios específicos. La mayoría de las empresas SaaS en crecimiento acaban aquí, porque un único SLA plano rara vez se ajusta a la vez a un cliente self-serve y a una cuenta enterprise bajo el mismo contrato.
¿En qué se diferencia un SLA de un OLA?
Este es uno de los puntos que más confusión genera, y conviene aclararlo porque ambos documentos tienen destinatarios muy distintos. Los acuerdos de nivel operativo (OLA) son acuerdos internos que describen cómo colaboran los equipos y departamentos para cumplir los compromisos asumidos en los SLA, mientras que los SLA fijan las expectativas de cara al cliente y aportan responsabilidad.
En pocas palabras, el SLA es la promesa que se hace al cliente. El OLA es la maquinaria interna que hace posible cumplir esa promesa. El SLA define el «qué», es decir, qué servicio se prestará y con qué nivel de calidad, mientras que el OLA define el «cómo», es decir, cómo trabajan juntos los equipos internos para prestar ese servicio. Uno es la promesa externa; el otro es la hoja de ruta operativa interna que permite cumplirla.
Un equipo que se salta el OLA suele acabar con un SLA que no puede cumplir de forma fiable. Si soporte promete una respuesta en dos horas pero ingeniería no tiene ningún acuerdo interno sobre la rapidez con que se priorizan los bugs escalados, el compromiso con el cliente es tan sólido como el traspaso interno más débil. Esta es la carencia que la mayoría de las explicaciones superficiales de los SLA pasan por alto: el contrato externo y el acuerdo operativo interno deben construirse juntos, no tratarse como ejercicios separados.
¿Por qué importan los SLA para los equipos de SaaS y de soporte?
Para los negocios de suscripción, un SLA está directamente ligado a la retención de ingresos, no solo a la satisfacción del cliente. La resolución en el primer contacto ilustra con claridad lo que está en juego. La resolución en el primer contacto es el mejor predictor individual de la satisfacción del cliente en los datos de benchmarking longitudinales, y la brecha de 44 puntos de satisfacción entre los primeros contactos resueltos y los no resueltos es la cifra que más se cita en las propuestas de presupuesto de los contact centers, porque conecta directamente con la economía de la retención.
Esa es la razón de fondo por la que los SLA tienen más peso en B2B SaaS que en la mayoría de los sectores. Incumplir el plazo de respuesta en una cuenta de alto valor cercana a la renovación no es solo una respuesta tardía; se interpreta como una señal de que la relación está en riesgo. Los equipos de soporte, customer success y gestión de cuentas siguen cada vez más el cumplimiento de los SLA junto con los datos de salud de la cuenta, y no de forma aislada, porque un incumplimiento en una cuenta estratégica no tiene las mismas consecuencias que en una de bajo contacto.
Precisamente por eso el enfoque de los SLA importa a los equipos que construyen sus operaciones con Seedling: definirlo bien no es un ejercicio académico, es la base para decidir qué métricas predicen realmente el churn y cuáles solo miden actividad. Un equipo que solo comprueba si los tickets se respondieron «a tiempo» se está perdiendo la pregunta más útil: ¿protegió realmente el marco de SLA a las cuentas que más importaban?
El fallo más común de un SLA no es un contrato mal redactado. Es un contrato estático. Los equipos fijan los objetivos una vez en el lanzamiento y nunca los revisan a medida que cambian el producto, el tamaño del equipo o la base de clientes. Una revisión trimestral de los objetivos del SLA frente a los datos de rendimiento reales detecta las desviaciones antes de que se conviertan en un patrón de promesas incumplidas.
Un cambio relacionado que conviene vigilar
Los SLA miden actividad: si la respuesta llegó a tiempo, si el sistema estuvo operativo, si el ticket se cerró dentro del plazo. No miden si el cliente sintió realmente que lo atendieron bien. Esa distinción está llevando a algunas organizaciones hacia lo que se conoce como acuerdos de nivel de experiencia (XLA), que miden la percepción y el valor percibido junto con las métricas operativas tradicionales.
Esto no deja obsoleto al SLA. Lo convierte en el mínimo, no en el techo. Un equipo puede cumplir todos los objetivos del SLA sobre el papel y aun así perder una cuenta si la experiencia detrás de esas cifras resultó puramente transaccional. La conclusión práctica para quien monte operaciones de soporte o de customer success es tratar el SLA como la base innegociable y construir encima el seguimiento de la salud de la cuenta y de la experiencia, en lugar de asumir que un dashboard de SLA en verde cuenta toda la historia.
Fuentes
- Acuerdo de nivel de servicio (SLA), ITIL.org.uk
- Checklist de SLA y OLA, IT Process Maps
- ¿Qué son los acuerdos de nivel de experiencia (XLA)?, APMG International
- Filosofía operativa de la métrica FCR, SQM Group