Cuando una empresa contrata un servicio de mantenimiento informático, suele fijarse en el precio, en si incluye soporte remoto o presencial y en cuánto tarda el proveedor en contestar. Pero hay una pieza que determina si todo eso se convierte en un servicio serio o en una promesa difícil de reclamar: el SLA.

El problema es que muchas empresas creen tener un buen acuerdo porque ven siglas técnicas, tiempos orientativos y frases como “respuesta prioritaria”. Pero un SLA útil no se reconoce por cómo suena, sino por cómo está escrito. Si no define con precisión qué cubre, en cuánto tiempo debe actuar el proveedor y qué pasa si no cumple, no protege de verdad a la empresa.

1. Tiempos de respuesta que no dejen lugar a interpretación

El primer punto que debe incluir un SLA serio es el tiempo de respuesta garantizado. Es decir, cuánto tiempo máximo puede pasar desde que la empresa comunica una incidencia hasta que el proveedor la registra, la valida y asigna a un técnico.

Aquí es donde muchos acuerdos empiezan a fallar. Poner “respuesta rápida” o “atención prioritaria” no significa nada si no se traduce en horas concretas. Un servidor caído, una brecha de seguridad o una pérdida de acceso a un sistema crítico no pueden depender de una formulación ambigua. El SLA debe dejar por escrito un tiempo máximo medible y, además, diferenciarlo según la gravedad de la incidencia.

En algunos servicios de soporte, los tiempos comprometidos cambian incluso según el día o el tipo de servicio contratado, lo que demuestra que no basta con decir que existe asistencia: hay que especificar exactamente en qué plazo se actúa.

2. Tiempos de resolución, no solo de reacción

Responder no es resolver. Y esta es una de las trampas más habituales en los contratos de mantenimiento informático. Un proveedor puede contestar en pocos minutos, abrir un ticket y, aun así, dejar el problema sin solucionar durante demasiado tiempo.

Por eso, un SLA útil debe incluir también el tiempo de resolución garantizado. Este dato marca cuánto puede tardar el proveedor en devolver el servicio a un estado operativo, no simplemente en confirmar que ha recibido el aviso.

Si el acuerdo solo habla de tiempo de respuesta, pero no de resolución, la empresa se queda sin una referencia real para medir si el servicio funciona. En una incidencia crítica, lo importante no es solo que alguien conteste, sino que el negocio vuelva a operar dentro de un plazo razonable.

3. Niveles de criticidad bien definidos

No todas las incidencias tienen el mismo impacto, y un SLA serio debe reflejarlo. No puede tratar igual una impresora que falla puntualmente que una caída del servidor, un problema de acceso generalizado o una infección por malware.

Por eso, el acuerdo debe incluir una clasificación clara de incidencias, normalmente dividida en niveles como crítico, alto, medio y bajo. Lo importante no es solo el nombre de cada nivel, sino los criterios que lo definen. Si no queda claro qué se considera una incidencia crítica, el proveedor y el cliente pueden interpretar cosas distintas justo cuando más importa.

Esta clasificación no es un detalle técnico menor. Es la base sobre la que se calculan los tiempos de respuesta, las prioridades de intervención y el tipo de recursos que deben movilizarse.

4. Horarios y canales de atención claramente delimitados

Otro error común es asumir que el soporte está disponible siempre, cuando en realidad el contrato puede limitarlo a ciertos horarios o canales. Un SLA que sirva de verdad debe indicar por qué vías se reportan las incidencias y en qué franjas horarias opera el servicio.

Esto incluye aspectos como si el aviso debe hacerse por correo, teléfono, portal de tickets o aplicación específica, y si existe cobertura para emergencias fuera del horario habitual. En una empresa que depende de sus sistemas para trabajar, esta diferencia no es secundaria: determina si un problema se atiende en minutos o si tiene que esperar hasta el día siguiente.

También conviene que el acuerdo aclare si ciertos canales tienen prioridad sobre otros. No es lo mismo abrir un ticket por email que activar una incidencia crítica por teléfono con escalado inmediato.

5. Disponibilidad del servicio medida de forma real

Muchos SLA incluyen porcentajes de disponibilidad, pero pocas empresas se paran a revisar qué significan exactamente. Sobre el papel, 99%, 99,5% o 99,9% parecen valores muy parecidos. En la práctica, la diferencia puede representar muchas horas de inactividad a lo largo del año.

Por eso, el acuerdo debe indicar qué disponibilidad se garantiza y cómo se calcula. También debe dejar claro si esa disponibilidad se mide sobre todo el servicio, sobre sistemas concretos o solo dentro del horario contratado.

Si este punto no está bien definido, el porcentaje pierde valor. Un dato aislado puede parecer sólido en una presentación comercial, pero resultar poco útil cuando llega el momento de exigir responsabilidades.

6. Penalizaciones si el proveedor no cumple

Un SLA sin consecuencias por incumplimiento tiene poca fuerza real. Si el proveedor falla en los tiempos comprometidos y no ocurre nada, el acuerdo deja de ser una garantía y se convierte en una formalidad.

Por eso, el documento debería incluir penalizaciones o mecanismos correctivos. Pueden traducirse en descuentos, créditos de servicio o revisiones contractuales cuando los incumplimientos se repiten. Lo importante no es solo castigar el fallo, sino convertir el compromiso en algo exigible.

Este punto es el que separa una promesa comercial de una obligación operativa. Si no hay una consecuencia definida, el cliente asume todo el impacto y el proveedor apenas asume riesgo.

7. Exclusiones redactadas con precisión

Todo SLA tiene exclusiones, y eso es normal. Hay incidencias que no dependen del proveedor, como una caída de un tercero, un problema provocado por una manipulación incorrecta del cliente o una situación de fuerza mayor.

El problema aparece cuando esas exclusiones están redactadas de forma demasiado abierta. Frases genéricas como “causas externas” o “factores ajenos al servicio” pueden dejar espacio para discutir casi cualquier incidencia.

Un acuerdo útil debe definir estas exclusiones con detalle. No para proteger solo al proveedor, sino para evitar conflictos cuando ya hay una incidencia en marcha. Cuanto más claro esté este apartado, menos margen habrá para las interpretaciones oportunistas.

8. Qué debe poder demostrar el proveedor

Un SLA útil no solo fija compromisos: también obliga a poder demostrarlos. De nada sirve hablar de tiempos garantizados si luego no existe una forma clara de medir cuándo se notificó una incidencia, cuándo se respondió y cuándo se resolvió.

Por eso, el acuerdo debería apoyarse en un sistema de registro verificable, como tickets, trazabilidad de intervenciones o reportes periódicos. Si no hay medición, no hay forma real de auditar el servicio. Y si no se puede auditar, el SLA queda reducido a una declaración difícil de reclamar.

Este punto es especialmente importante en empresas que dependen de la continuidad operativa. Cuando hay una parada crítica, lo último que conviene es discutir si el proveedor llegó a tiempo o no.

9. Qué preguntar antes de firmar

Antes de aceptar cualquier contrato de mantenimiento informático, conviene revisar si el SLA responde a unas cuantas preguntas muy concretas. Si no puede responderlas con claridad, el acuerdo probablemente no está bien cerrado.

• ¿Está el SLA incluido por escrito dentro del contrato?
• ¿Diferencia entre tiempo de respuesta y tiempo de resolución?
• ¿Define niveles de criticidad con criterios objetivos?
• ¿Indica horarios, canales y cobertura fuera de horario?
• ¿Explica cómo se mide la disponibilidad?
• ¿Incluye penalizaciones reales por incumplimiento?
• ¿Detalla exclusiones sin ambigüedades?
• ¿Permite verificar con registros cuándo se atendió y resolvió cada incidencia?

Estas preguntas no son un formalismo. Son la forma más rápida de saber si la empresa está contratando un servicio controlable o simplemente una expectativa comercial bien redactada.

Preguntas Frecuentes

¿Un SLA y un contrato de mantenimiento informático son lo mismo?

No exactamente. El contrato regula la relación general entre cliente y proveedor, mientras que el SLA concreta los niveles de servicio medibles: tiempos, disponibilidad, prioridades, canales y consecuencias por incumplimiento.

¿Qué diferencia hay entre tiempo de respuesta y tiempo de resolución?

El tiempo de respuesta mide cuánto tarda el proveedor en atender formalmente la incidencia. El tiempo de resolución mide cuánto tarda en dejar el problema resuelto y el servicio restaurado.

¿Es obligatorio que haya penalizaciones en un SLA?

No siempre desde el punto de vista contractual, pero sí son muy recomendables si se quiere que el compromiso tenga fuerza real. Sin una consecuencia asociada al incumplimiento, el SLA pierde capacidad de protección para el cliente.

¿Un SLA sirve también para soporte remoto?

Sí. De hecho, en servicios remotos es todavía más importante, porque el cliente necesita saber con exactitud en qué plazo será atendido, por qué canal y bajo qué prioridad.

Un SLA de mantenimiento informático no debería existir para decorar una propuesta comercial. Debería servir para que la empresa sepa, por escrito y sin ambigüedades, qué puede exigir cuando algo falla.

Si el acuerdo no concreta tiempos, niveles de criticidad, canales, disponibilidad, penalizaciones, exclusiones y mecanismos de medición, no está protegiendo a la empresa: solo está generando una falsa sensación de control. Y en tecnología, esa falsa sensación suele salir cara.

Habla con Epic y revisa si tu contrato de mantenimiento incluye un SLA que realmente proteja a tu empresa