Contrato de soporte IT: siete cláusulas que hay que leer antes de firmar

Un SLA que nadie mide es una promesa

Casi todos los contratos de soporte dicen tener SLA. La mayoría trae un cuadro con horas y porcentajes, y ahí termina el asunto: nadie vuelve a mirarlo hasta que algo se rompe y la conversación se vuelve incómoda.

Este artículo es la lista de lo que conviene revisar antes de firmar. Escrito por alguien que vende estos contratos, así que léelo con esa pinza puesta —y úsalo también con nosotros. Un proveedor que se incomoda con estas preguntas ya te dio información.

1. Qué es “respuesta” y qué es “resolución”

Es la confusión más rentable del sector. Un contrato promete respuesta en 2 horas y suena excelente. Pero responder puede significar simplemente que alguien acusa recibo del ticket.

El número que te importa es el de resolución, y muchos contratos no lo comprometen: hablan solo del primer contacto. Si el tuyo no dice cuánto tarda en quedar resuelto —o al menos en tener un diagnóstico y una vía de solución—, no tienes un compromiso de servicio, tienes un compromiso de cortesía.

Pregunta directa: ¿cuál es el tiempo de resolución comprometido, por severidad, y qué pasa si no se cumple?

2. Quién clasifica la severidad

Los tiempos casi siempre dependen de la severidad del caso: crítico, alto, medio, bajo. La letra chica está en quién decide en qué casilla cae tu problema.

Si lo decide unilateralmente el proveedor, el SLA se cumple siempre: basta con clasificar como “medio” lo que para ti era crítico. Busca una definición escrita de cada nivel, con ejemplos, y un mecanismo para escalar cuando no estén de acuerdo.

Una definición útil no habla de tecnología, habla de negocio: “crítico” no es que se cayó un servidor, es que hay un proceso que no puede operar.

3. La cobertura horaria, y qué pasa a las seis de la tarde

“24/7” en la portada y “horario laboral” en el anexo es una combinación más común de lo que parece. Revisa:

Qué horas están cubiertas para cada tipo de caso.
Si fuera de horario hay atención o solo hay buzón.
Si la atención nocturna y de feriados tiene costo adicional, y cuál.
Qué cuenta como feriado: los nacionales, los locales, ¿los puentes?

No hay una respuesta correcta —una empresa que opera de 8 a 6 no necesita cobertura nocturna— pero sí hay una respuesta clara, y debería estar escrita.

4. El alcance: qué equipos y qué software

El punto donde más discusiones nacen. Un contrato serio dice exactamente qué entra:

Cuántos usuarios y cuántos equipos, y qué pasa cuando creces.
Qué servidores, qué red, qué dispositivos.
Qué software: el sistema operativo y la ofimática casi siempre; tu sistema contable o tu ERP, casi nunca. Si tu problema más frecuente es el ERP, un contrato que lo excluye no te va a servir de nada.
Si el soporte es solo remoto o incluye visitas, cuántas, y si las de emergencia se cobran aparte.

5. Las exclusiones (léelas primero)

Consejo práctico: empieza el contrato por la lista de exclusiones. Es la parte más informativa y la que menos gente lee. Ahí vas a encontrar si quedan fuera los equipos de más de cierta antigüedad, el hardware que ya venía dañado, el software sin licencia, o los sistemas que el proveedor no instaló.

Algunas exclusiones son perfectamente razonables. Lo que no es razonable es enterarte de ellas el día que las necesitas.

6. El reporte mensual

Sin medición no hay SLA. Debería llegarte, cada mes y sin pedirlo, un reporte con: cuántos casos entraron, cómo se clasificaron, cuánto tardó cada uno, cuáles se salieron del compromiso y por qué, y qué está en riesgo de romperse pronto.

Ese último punto separa a un proveedor de soporte de una mesa de reclamos. Si tu proveedor solo aparece cuando lo llamas, no está monitoreando nada; está esperando.

7. La cláusula de salida

Léela antes que la de entrada. El día que decidas cambiar de proveedor —o llevar el soporte adentro— vas a necesitar:

Tus credenciales. Las contraseñas de administrador de tus sistemas son tuyas, no del proveedor. Que estén documentadas y entregables.
Tus datos y tus respaldos, en un formato que puedas usar sin su plataforma.
La documentación: diagrama de red, inventario, licencias, particularidades.
Un plazo de transición definido, con la obligación de acompañar el traspaso.

Un contrato que dificulta la salida no está protegiendo un servicio, está protegiendo una renta.

Sobre las penalidades

Casi todos los contratos con SLA traen penalidades y casi ninguna duele: un descuento del 5% sobre la mensualidad no compensa un día de operación detenida, y ambas partes lo saben.

No pierdas la negociación ahí. Una penalidad simbólica igual sirve para algo: obliga a reconocer por escrito que el compromiso se incumplió, y tres reconocimientos seguidos son un argumento para terminar el contrato sin discusión. Eso vale más que el descuento.

Cuándo NO necesitas un contrato con SLA

Si son cinco personas, una impresora y un grupo de WhatsApp, un contrato formal con severidades y reportes mensuales es burocracia que vas a pagar y no vas a usar. Un acuerdo de horas de soporte por demanda, claro y sin letra chica, te sirve mejor.

El SLA empieza a valer cuando hay algo que no puede detenerse: una operación con turnos, un sistema del que depende la facturación, o un equipo lo bastante grande como para que “quién estaba viendo esto” ya no tenga respuesta obvia.

Nuestro lado del mostrador

Nosotros trabajamos con tiempos de respuesta y de resolución comprometidos por contrato, reporte mensual, y soporte remoto y presencial en Quito. Si vas a evaluarnos, evalúanos con esta lista —y pregunta por la cláusula de salida en la primera reunión, no en la última.

Soporte técnico y servicios administrados — mesa de ayuda con SLA, monitoreo proactivo y mantenimiento preventivo.
¿Contratar un técnico de sistemas o tercerizar el soporte? — la decisión anterior a elegir proveedor.
Características clave de la infraestructura IT como servicio — el modelo del que forman parte estos contratos.

O escríbenos con el contrato que tienes hoy sobre la mesa; te decimos qué le falta, aunque sea de otro proveedor.