Un SLA (acuerdo de nivel de servicio) en desarrollo de software es la parte del contrato que fija, con números, qué calidad de servicio te debe el proveedor una vez el software está en marcha: cuánto tiempo debe estar disponible, en cuánto tiempo reacciona ante un fallo y en cuánto lo resuelve. Si encargas una web, una app o un software a medida, el SLA es lo que convierte un «cuenta con nosotros» en un compromiso que puedes medir y reclamar.
Esta guía está pensada para pymes y emprendedores que van a contratar (o ya han contratado) desarrollo a medida y quieren saber qué pedir, qué es razonable y qué trampas evitar.
En resumen
- Un SLA define compromisos medibles: disponibilidad (uptime), tiempo de respuesta y tiempo de resolución, con consecuencias si no se cumplen.
- El SLA clásico nació para soporte e infraestructura, no para medir si el desarrollo resuelve tu problema de negocio. Complétalo con objetivos y entregables claros.
- Pide informes y registros que te permitan comprobar el cumplimiento, y revisa el acuerdo de forma periódica.
- Clasifica las incidencias por gravedad: no es lo mismo un sistema caído que un botón mal alineado.
- En un proyecto a medida, SLA, propiedad del código y mantenimiento deben pactarse juntos, antes de firmar.
Tabla de contenidos
- Qué es un SLA y qué no es
- Las métricas que de verdad importan
- Niveles de gravedad: la tabla que evita discusiones
- Qué debe incluir un SLA de software a medida
- El error más común: medir la rapidez, no el resultado
- SLA, garantía y mantenimiento: no son lo mismo
- Marco legal en España: lo que conviene saber
- Cómo negociar un SLA realista con tu proveedor
- Nuestra perspectiva
- Si estás pensando en encargar un software a medida
- Preguntas frecuentes
- Fuentes
Qué es un SLA y qué no es
Un SLA es, según el Gobierno Vasco, un contrato escrito entre un proveedor y su cliente en el que se establecen los requisitos que el servicio debe cumplir. En software, esos requisitos se refieren a la calidad, la capacidad de respuesta y la disponibilidad del servicio.
Conviene separar tres cosas que se confunden a menudo:
- El contrato de desarrollo: qué se construye, en qué plazo, por qué precio, quién es el titular del código.
- El SLA: cómo se comporta el servicio una vez entregado y cómo se atienden los problemas.
- Los KPI de negocio: si el software logra lo que querías (menos horas administrativas, más pedidos, menos errores).
Un SLA no sustituye a los otros dos. Puedes tener un servicio disponible al 99,9% que no resuelva nada de lo que necesitas.
Las métricas que de verdad importan
Las métricas habituales, como recoge la norma ISO/IEC 20000-1 en su marco de gestión de servicios de TI, giran en torno a tres ideas.
Disponibilidad (uptime)
Es el porcentaje de tiempo en que el servicio funciona. Se mide normalmente por mes. Para que te hagas una idea, un 99,9% equivale a unas 8,7 horas de caída permitida al año. Cada decimal adicional encarece mucho el servicio, porque exige redundancia, monitorización y guardias.
Para una pyme, la pregunta útil no es «cuántos nueves», sino «cuánto me cuesta una hora parada». Una tienda online en campaña de rebajas y una herramienta interna de planificación usada de lunes a viernes no necesitan lo mismo.
Define también:
- Qué cuenta como caída (¿solo si no carga nada, o también si falla el pago?).
- Las ventanas de mantenimiento programado, que normalmente se excluyen del cálculo.
- Cómo se mide: qué herramienta, con qué frecuencia y quién tiene acceso a los datos.
Tiempo de respuesta
Es cuánto tarda el proveedor en reconocer el problema y empezar a trabajar en él. No significa que esté arreglado. Es la métrica más fácil de cumplir y también la que más se usa para dar una falsa sensación de control.
Tiempo de resolución
Es cuánto tarda en solucionarse. Aquí conviene aceptar que algunos problemas dependen de terceros (un proveedor de pagos, un servicio en la nube) y que se admite una solución temporal mientras llega la definitiva. Pacta qué se entiende por «resuelto»: solución definitiva, parche o alternativa operativa.
Niveles de gravedad: la tabla que evita discusiones
Un buen SLA de software no usa un único plazo para todo. Clasifica las incidencias por severidad. Una estructura habitual, que también aparece en modelos de cláusulas para contratos de desarrollo, distingue desde el sistema caído hasta la funcionalidad crítica degradada y las incidencias menores.
Ejemplo orientativo, que debes ajustar a tu negocio y a lo que el proveedor pueda asumir:
| Gravedad | Ejemplo | Qué pactar |
|---|---|---|
| Crítica | La aplicación no funciona o no se puede cobrar | Respuesta inmediata en horario acordado, atención hasta restablecer el servicio |
| Alta | Una función clave falla pero hay alternativa | Respuesta en el mismo día laborable, corrección priorizada |
| Media | Error que molesta pero no bloquea | Corrección en la siguiente versión planificada |
| Baja | Mejora estética o petición menor | Se acumula en el backlog y se revisa periódicamente |
Los plazos concretos son tuyos y del proveedor: no hay cifras universales. Lo importante es que estén escritos y que ambos entiendan lo mismo por «crítica».
Qué debe incluir un SLA de software a medida
Una lista de comprobación práctica antes de firmar:
- Alcance del servicio: qué sistemas, módulos e integraciones cubre (y cuáles no, como un servicio externo que no controla el proveedor).
- Horario de soporte: laborable, ampliado o 24/7, y cómo se contacta (correo, teléfono, gestor de incidencias).
- Métricas y forma de medirlas: uptime, respuesta, resolución, con fórmula de cálculo.
- Niveles de gravedad y plazos por nivel.
- Exclusiones: fallos causados por un uso indebido, cambios hechos por terceros sin avisar o causas de fuerza mayor.
- Consecuencias del incumplimiento: créditos de servicio, descuentos en la cuota o derecho a rescindir si se incumple de forma reiterada.
- Informes y auditoría: qué datos recibirás y con qué periodicidad.
- Copias de seguridad y recuperación: frecuencia de las copias y tiempo máximo para restaurar.
- Revisión periódica: cuándo se renegocian los valores.
- Duración y salida: plazo, renovación, preaviso y entrega de datos y documentación si cambias de proveedor.
Informes y mecanismos de control
El INCIBE insiste en que, cuando externalizas un servicio, el SLA no debe limitarse a fijar tiempos: debe incluir mecanismos de control como informes, paneles de monitorización o registros que permitan al cliente auditar el rendimiento de forma objetiva. Sin ellos, el acuerdo se queda en una declaración de intenciones y es difícil detectar mejoras o deterioros.
En la práctica, pide al menos un informe mensual con disponibilidad real, incidencias abiertas y cerradas, tiempos de respuesta y resolución, y las acciones previstas.
El error más común: medir la rapidez, no el resultado
El SLA tradicional se diseñó para soporte técnico e infraestructura, como el hosting o la mesa de ayuda. Aplicarlo sin más a un proyecto de software tiene un riesgo: que todos los indicadores estén en verde y, aun así, el producto no ayude a tu equipo.
El propio comité de ISO que trabaja estos temas explica en su documento sobre XLAs e ISO/IEC 20000-1 que los acuerdos de nivel de experiencia (XLA) miden la experiencia directamente en el punto de interacción, además de las métricas técnicas. La idea para una pyme es sencilla: junto al SLA, define dos o tres objetivos de resultado.
Ejemplos:
- Tiempo medio que tarda un empleado en completar una tarea clave en la herramienta.
- Porcentaje de pedidos que se procesan sin intervención manual.
- Número de errores de datos al mes tras la automatización.
- Satisfacción de los usuarios internos con una pregunta corta tras cada incidencia.
Así el SLA garantiza que el servicio funciona y los objetivos de negocio comprueban que sirve.
SLA, garantía y mantenimiento: no son lo mismo
En proyectos a medida se mezclan tres conceptos:
- Garantía: el proveedor corrige sin coste los defectos del trabajo entregado durante un periodo pactado. Cubre errores de lo ya construido, no cambios nuevos.
- Mantenimiento correctivo y evolutivo: corregir fallos después de la garantía y añadir mejoras. Suele ser una cuota o una bolsa de horas.
- SLA: los plazos y niveles con que se presta ese soporte y esa disponibilidad.
Deja por escrito cuándo termina la garantía y cuándo empieza el servicio de mantenimiento, para que no haya un hueco en el que nadie se responsabilice.
Marco legal en España: lo que conviene saber
En el ámbito de empresa a empresa, la libertad de pacto es amplia y el SLA es lo que tú y tu proveedor acordéis. Aun así, hay referencias útiles.
La Directiva (UE) 2019/770, sobre contratos de suministro de contenidos y servicios digitales, establece que los servicios digitales deben cumplir lo pactado en cuanto a descripción, calidad, funcionalidad, seguridad y compatibilidad. Está pensada para proteger al consumidor frente al empresario, por lo que no se aplica de forma directa a un contrato entre dos empresas. Pero marca una buena pauta: lo que prometas sobre calidad y funcionalidad debe estar descrito con claridad. Si tu software lo usarán después consumidores finales (una app o una tienda online), conviene que el SLA con tu proveedor te permita cumplir con ellos.
Para la titularidad del código, las licencias y las cláusulas de confidencialidad, lo prudente es que un abogado mercantil o especialista en propiedad intelectual revise el contrato antes de firmar, sobre todo si el software es crítico para tu negocio o trata datos personales.
Cómo negociar un SLA realista con tu proveedor
Un pequeño estudio o un desarrollador independiente no tiene la misma estructura que una gran consultora, y exigirle una guardia 24/7 puede disparar el coste sin que lo necesites. Estos pasos ayudan a acordar algo que se cumpla:
- Calcula el coste de una parada. Horas de trabajo perdidas, ventas no realizadas, imagen. Eso fija cuánto vale la pena pagar.
- Identifica lo crítico. Probablemente solo dos o tres funciones justifican una respuesta rápida.
- Pide propuestas por niveles. Un nivel básico (horario laboral) y uno ampliado te permiten comparar precio y cobertura.
- Exige medición transparente. Si no se puede medir, no se puede reclamar.
- Pacta una revisión periódica. Una reunión breve y recurrente para revisar métricas mantiene vivo el acuerdo y evita que se convierta en un papel olvidado.
- Documenta la entrega. Código, accesos, documentación y manual de despliegue facilitan que el servicio se mantenga con quien sea.
Nuestra perspectiva
Desde nuestro trabajo en desarrollo a medida para pequeñas y medianas empresas, pensamos que el SLA es una herramienta de confianza, no un arma arrojadiza. Un cliente que firma un SLA con cifras imposibles se queda tranquilo hasta el primer problema; uno que firma un SLA ajustado a su realidad sabe qué esperar cada día.
Creemos que un buen SLA empieza mucho antes de la firma, en cómo se construye el producto. Si el software es mantenible y escalable, el soporte es más rápido, las incidencias son menos y los compromisos se pueden cumplir sin heroicidades. Por eso, para nosotros la conversación sobre soporte y disponibilidad forma parte del propio diseño de la solución, no un anexo de última hora.
Y pensamos que el indicador que más importa no está en la tabla de tiempos: es si la herramienta ha quitado trabajo manual al equipo. Un SLA sin objetivos de negocio mide si el motor está encendido; no si el coche llega a donde querías.
— Rollis123
Si estás pensando en encargar un software a medida
Si tu empresa necesita una web, una app o una herramienta de gestión y quieres definir desde el principio qué soporte y qué mantenimiento tendrás, puedes ver nuestros servicios de desarrollo web, apps móviles y software a medida. Trabajamos con pymes y emprendedores en digitalización y automatización, y también tenemos soluciones conectadas para negocios en Can Marimón para Negocios. Cuéntanos qué proceso quieres mejorar y el nivel de servicio que necesitas, y lo concretamos en la propuesta.
Preguntas frecuentes
¿Qué significa SLA en castellano?
SLA son las siglas en inglés de Service Level Agreement, que en español se traduce como acuerdo de nivel de servicio (ANS). Es un documento, o una parte del contrato, en el que el proveedor se compromete a unos niveles concretos de calidad y plazos. Se usa mucho en software, hosting, soporte técnico y servicios gestionados.
¿Qué diferencia hay entre SLA y KPI?
El SLA es el compromiso pactado entre proveedor y cliente, con valores mínimos y consecuencias. Un KPI es un indicador que sirve para medir el rendimiento, sin que sea necesariamente un compromiso contractual. Lo habitual es usar KPI para medir el cumplimiento del SLA y, además, para medir los resultados de negocio.
¿Necesito un SLA si mi software es pequeño?
No hace falta un documento extenso, pero sí conviene dejar por escrito lo básico: horario de soporte, plazos de respuesta según la gravedad, copias de seguridad y qué ocurre tras la garantía. Una página clara suele ser más útil que un anexo de veinte páginas que nadie lee.
¿Qué pasa si el proveedor incumple el SLA?
Depende de lo que hayáis pactado. Lo habitual son compensaciones como descuentos en la cuota o créditos de servicio, y la posibilidad de rescindir si el incumplimiento es grave o repetido. Si no se pactó nada, tendrás que acudir a las reglas generales del contrato, por lo que conviene que un abogado revise el caso concreto.
¿Un uptime del 99,9% es suficiente?
Equivale a unas 8,7 horas de caída al año según el cálculo habitual, lo que para muchas herramientas internas es más que suficiente. Para un comercio electrónico en plena campaña quizá no lo sea, y la clave es comparar el coste de la caída con el coste de la mayor cobertura.
Fuentes
- ISO/IEC 20000-1:2018, gestión de servicios de TI
- Directiva (UE) 2019/770 en el BOE
- Acuerdos de nivel de servicio (SLA), Gobierno Vasco
- Taxonomía de soluciones de ciberseguridad, INCIBE
- Using XLAs in ISO/IEC 20000-1
- Contratos de desarrollo de software: cláusulas clave y SLAs