El informe mensual del proveedor dice "cumplimiento SLA: 98%". Ese mismo mes el ERP estuvo caído medio día, la bodega despachó con guías hechas a mano y nadie del proveedor apareció hasta la tarde. Las dos cosas son ciertas a la vez. El contrato medía si alguien contestaba el ticket a tiempo, no si el problema se resolvía.
Cuando contratas servicios administrados TI, el SLA (acuerdo de nivel de servicio) es lo que convierte una promesa comercial en una obligación que se puede medir. Muchos SLA, sin embargo, están escritos para verse bien en la propuesta y no para proteger tu operación. Abajo va cómo leer uno y qué pedir antes de firmar: severidades, tiempos, penalidades, reportes, gobierno TI y salida.
Si todavía estás decidiendo si te conviene un servicio gestionado, ese tema lo vimos en Servicios de TI gestionados: qué incluyen y cuándo convienen. Aquí partimos de que ya tienes una propuesta sobre la mesa.
Respuesta no es resolución
La trampa más común está en una palabra. "Tiempo de respuesta" suele significar que alguien acusó recibo del ticket: un correo automático, una llamada, una asignación en la herramienta. "Tiempo de resolución" es cuando el servicio vuelve a funcionar. Un SLA que solo compromete respuesta se puede cumplir al 100% con el sistema caído todo el día.
Al leer el contrato, revisa cómo define cada cosa. En la respuesta, si basta un mensaje automático o si tiene que haber un técnico calificado trabajando en el caso. En la resolución, si se exige solución definitiva o vale una solución temporal (workaround) que restablece el servicio; lo normal es lo segundo, con un plazo aparte para la causa de fondo. Y en el reloj, desde cuándo corre: desde que abres el ticket o desde que el proveedor lo "valida", y si se detiene mientras espera información tuya.
Que el reloj se pause cuando el proveedor depende de una respuesta tuya es razonable. Las pausas indefinidas, o a criterio exclusivo del proveedor, no lo son. Pide que cada pausa quede registrada en la herramienta de tickets y que tú puedas verla.
Severidades: la tabla que decide todo
Los tiempos solo tienen sentido si están amarrados a una clasificación de severidad clara. Si la severidad la fija el proveedor sin criterios escritos, puede bajar un incidente crítico a "medio" y cumplir el SLA en el papel.
Una tabla de severidades útil se parece a esta. Los tiempos son ilustrativos: cada empresa los define según cuánto le cuesta cada hora detenida.
| Severidad | Criterio | Ejemplo | Respuesta | Resolución o workaround |
|---|---|---|---|---|
| Crítica (P1) | Operación detenida o incidente de seguridad activo | ERP caído, ransomware, no se puede facturar | 30 min | 4 h |
| Alta (P2) | Función importante degradada, hay alternativa | Un módulo no carga, VPN intermitente | 1 h | 8 h |
| Media (P3) | Afecta a un usuario o a un proceso no crítico | Error en un reporte, impresora | 4 h | 2 días hábiles |
| Baja (P4) | Consulta o solicitud planificable | Alta de usuario, cambio de permisos | 1 día hábil | Según acuerdo |
Al revisar la tabla de tu propuesta, fíjate primero en los ejemplos. Tienen que ser de tu negocio: "se cayó la emisión de documentos electrónicos al SII" dice mucho más que "falla de sistema". Después, en quién clasifica. Lo sano es que tú propongas la severidad al abrir el ticket y que cualquier rebaja quede justificada por escrito.
El horario de cobertura también va por severidad. Con cobertura 9x5, un P1 que ocurre un viernes a las 19:00 se atiende el lunes. Puede ser aceptable para tu empresa, o no, pero tiene que estar claro antes de que pase. Un esquema frecuente es 9x5 para todo y 24x7 solo para P1.
Disponibilidad: cómo leer los porcentajes
Si el servicio incluye infraestructura o nube, el contrato probablemente promete un porcentaje de disponibilidad. Las cifras se parecen mucho entre sí. El tiempo de caída que permiten, no tanto:
| Disponibilidad mensual | Caída permitida en un mes de 30 días |
|---|---|
| 99% | ~7 h 12 min |
| 99,5% | ~3 h 36 min |
| 99,9% | ~43 min |
| 99,95% | ~22 min |
Antes de quedarte con el número, pregunta qué se mide (el servidor, la aplicación o el acceso real del usuario), con qué herramienta y si las ventanas de mantención se descuentan. Un 99,9% que excluye "mantenciones programadas" sin límite de horas vale bastante menos de lo que parece.
Penalidades y créditos de servicio
Un SLA sin consecuencias es una declaración de buenas intenciones. Lo habitual es pactar créditos de servicio, es decir, un descuento en la factura del mes cuando no se cumple un indicador.
Al negociarlos, lo primero es que se apliquen solos. Si tienes que reclamarlos por escrito dentro de un plazo corto, en la práctica nadie los cobra. Conviene también que escalen: un mes malo no es lo mismo que tres seguidos. Que el proveedor ponga un tope, por ejemplo un porcentaje de la factura mensual, es normal y aceptable, siempre que el incumplimiento reiterado te permita terminar el contrato sin multa. Esa causal de término es la penalidad que de verdad importa.
El extremo contrario también existe. Con penalidades desproporcionadas, el proveedor se dedica a discutir cada clasificación de severidad en vez de arreglar la falla. Lo que quieres es que a los dos les convenga lo mismo.
Reportes y gobierno TI
El informe mensual es donde se nota si el servicio mejora o solo se mantiene a flote. Como mínimo, debería traer:
- Tickets por severidad, con cumplimiento de respuesta y de resolución medidos por separado.
- Incidentes recurrentes y su causa raíz. Si el mismo problema aparece cuatro veces, alguien tiene que estar gestionando el problema y no solo cerrando tickets.
- Disponibilidad medida, con cada caída detallada.
- Cambios realizados y cambios que fallaron.
- Recomendaciones con responsable y fecha.
Un reporte que nadie lee no sirve de mucho. Por eso el contrato debería fijar un modelo de gobierno TI: una reunión operativa mensual, una revisión de servicio trimestral con alguien de gerencia de cada lado y una matriz de escalamiento con nombres y teléfonos, no con cargos genéricos. Pide además acceso directo a la herramienta de tickets. No deberías depender de un PDF para saber cómo va tu servicio.
Seguridad, datos personales y cláusula de salida
Hay dos leyes chilenas que cambian lo que un contrato de servicios administrados debería cubrir.
La Ley 21.719 modifica la Ley 19.628 de protección de datos personales y entra en vigencia el 1 de diciembre de 2026. Si el proveedor accede a sistemas con datos de clientes o trabajadores, actúa como encargado del tratamiento. El nuevo artículo 15 bis pide un contrato que fije objeto y duración del encargo, finalidad, tipos de datos y categorías de titulares. El encargado no puede delegar el encargo sin autorización específica y por escrito, tiene que cumplir las medidas de seguridad y reportarte las vulneraciones, y al terminar debe suprimir o devolver los datos. Eso va en el contrato de servicio, no en un anexo que nadie lee. Lo desarrollamos más en Protección de datos GDPR y Chile: qué aplica a su empresa.
La otra es la Ley Marco de Ciberseguridad (Ley 21.663). Si tu empresa presta servicios calificados como esenciales o fue calificada como operador de importancia vital, su artículo 9 la obliga a enviar una alerta temprana al CSIRT Nacional dentro de tres horas desde que conoce un incidente con posibles efectos significativos. Si el que detecta el incidente es tu proveedor, el SLA tiene que obligarlo a avisarte bastante antes de ese plazo. Aunque esa ley no te alcance, fijar un plazo corto de notificación de incidentes de seguridad es sentido común.
Queda la salida, que casi nadie negocia al principio porque todos están contentos. Antes de firmar, deja por escrito:
- Que las credenciales administrativas, las suscripciones y la documentación están a nombre de tu empresa.
- Un período de traspaso con plazo, entregables y horas incluidas.
- La entrega del inventario, la base de conocimiento y el historial de tickets en un formato que puedas usar.
- El precio del traspaso, definido hoy y no cuando ya decidiste irte.
Preguntas frecuentes
¿Qué diferencia hay entre tiempo de respuesta y tiempo de resolución?
La respuesta es cuando el proveedor toma el ticket y empieza a trabajar. La resolución es cuando el servicio vuelve a funcionar, aunque sea con una solución temporal. El SLA debería comprometer ambos y medirlos por separado.
¿Qué penalidad es razonable en un SLA de servicios administrados TI?
Lo usual son créditos de servicio sobre la factura mensual, que aumentan con la gravedad o la repetición del incumplimiento y tienen un tope. Más que el monto, importa que se apliquen automáticamente y que el incumplimiento reiterado permita terminar el contrato.
¿Cada cuánto debería revisar el SLA con el proveedor?
Todos los meses a nivel operativo y cada trimestre con la gerencia. Una vez al año conviene revisar si las severidades, los horarios y los indicadores siguen calzando con cómo opera hoy tu empresa.
Revisemos tu SLA
En Disrupsoft ofrecemos servicios gestionados con SLA y catálogo, además de staff augmentation y squads. Si tienes una propuesta de servicios administrados TI sobre la mesa, o un contrato vigente que no te convence, lo revisamos contigo y te proponemos severidades, tiempos y reportes que calcen con tu operación.
