Un SLA mal planteado no falla en el papel. Falla el lunes a las 8:17, cuando se cae el correo, nadie sabe si el proveedor debe responder en 15 minutos o en 4 horas, y el equipo interno empieza a escalar por intuición. Por eso, entender cómo definir SLA de soporte TI no es un trámite contractual, sino una decisión operativa que afecta continuidad, costes y confianza.
Para una pyme, el problema suele empezar por dos extremos igual de peligrosos. El primero es firmar un SLA genérico, con promesas amplias y métricas poco útiles. El segundo es exigir tiempos imposibles sin revisar presupuesto, cobertura, herramientas y criticidad real del negocio. En ambos casos, el resultado suele ser el mismo: expectativas desalineadas y conflictos cuando más hace falta responder bien.
Qué significa realmente un SLA de soporte TI
Un SLA, o acuerdo de nivel de servicio, define qué servicio se presta, con qué alcance, en cuánto tiempo y bajo qué condiciones se considera cumplido. En soporte TI, eso incluye desde tiempos de respuesta e intervención hasta horarios de cobertura, canales de atención, niveles de prioridad y exclusiones.
La clave está en no confundir actividad con resultado. Decir que un proveedor “atenderá incidencias rápidamente” no sirve si no se concreta qué significa “rápidamente”, en qué tipo de incidencias aplica y cómo se mide. Un buen SLA elimina ambigüedades. No busca sonar bien, busca evitar discusiones futuras.
También conviene distinguir entre tiempo de respuesta y tiempo de resolución. Muchas empresas creen tener cobertura suficiente porque el proveedor responde pronto al ticket, pero la operación se resiente si la resolución real tarda demasiado. Ambos indicadores importan, pero no pesan igual en todos los casos.
Cómo definir SLA de soporte TI según el impacto del negocio
El punto de partida no es la tecnología. Es el negocio. Antes de fijar tiempos, hay que responder una pregunta simple: ¿qué pasa si este servicio falla durante una hora, cuatro horas o un día completo? La respuesta cambia por completo el diseño del SLA.
No todas las incidencias merecen el mismo tratamiento. Una impresora sin conexión en un área administrativa no tiene el mismo impacto que la caída del ERP, una brecha de seguridad o la interrupción del acceso remoto del equipo comercial. Si se mete todo en la misma bolsa, el SLA pierde valor.
Lo más sensato es clasificar incidencias por prioridad. Normalmente se trabaja con niveles como crítico, alto, medio y bajo, pero el nombre importa menos que la definición. Una incidencia crítica debería estar asociada a una interrupción total de un proceso clave del negocio, afectación generalizada o riesgo de seguridad severo. Una media o baja puede tolerar más tiempo sin afectar de forma grave la operación.
Aquí aparece uno de los errores más comunes: definir prioridades desde TI y no desde operación. El resultado es que el proveedor considera “media” una incidencia que para el negocio es urgente. Para evitarlo, conviene que dirección, responsables de área y equipo técnico participen en la clasificación.
El contexto operativo cambia el SLA
Una empresa que vende en horario laboral de lunes a viernes no necesita necesariamente el mismo SLA que una organización con sucursales, personal móvil o atención continua. Si hay procesos fuera de horario, cierre contable nocturno o dependencia alta de sistemas remotos, el acuerdo debe reflejarlo.
Por eso, la cobertura 8×5 puede ser suficiente en algunos casos y claramente insuficiente en otros. Pedir 24×7 por defecto encarece el servicio. No pedirlo cuando sí se necesita sale todavía más caro.
Los elementos que no deben faltar en un SLA
Cuando una empresa revisa cómo definir SLA de soporte TI, suele centrarse solo en los tiempos. Es un error. El valor del acuerdo está en el conjunto.
Primero, debe quedar claro el alcance del servicio. Qué sistemas cubre, qué sedes o usuarios incluye, qué tipo de incidencias atiende y qué actividades quedan fuera. Si esto no se delimita, cualquier ticket no previsto acaba en una negociación.
Segundo, hay que fijar tiempos por etapa. El tiempo de primera respuesta indica cuándo el proveedor acusa recibo y empieza a trabajar. El tiempo de atención o intervención marca cuándo realmente entra en acción. El tiempo de resolución o restauración define cuándo el servicio vuelve a operar. En incidentes críticos, estas diferencias son decisivas.
Tercero, hace falta una matriz de prioridades con criterios objetivos. No basta con decir P1, P2 o P3. Hay que describir qué impacto representa cada nivel, cuántos usuarios afecta, si existe parada total o parcial y qué riesgos de negocio implica.
Cuarto, el SLA debe indicar horarios, canales y responsables. Si un incidente crítico solo puede abrirse por correo y el correo está caído, el proceso ya nació roto. Teléfono, portal, correo o mensajería deben estar definidos según el tipo de urgencia.
Quinto, conviene incluir escalado. Si no se resuelve en el tiempo esperado, ¿quién interviene después?, ¿cuándo pasa a un nivel superior?, ¿quién autoriza medidas extraordinarias? Esta parte evita cuellos de botella y silencios incómodos.
Por último, deben establecerse métricas y método de medición. El proveedor puede decir que cumple el 95% del SLA, pero esa cifra solo sirve si ambas partes calculan igual la base, las excepciones y el periodo de reporte.
Tiempos realistas: ni optimistas ni defensivos
Un SLA útil no se construye desde el deseo, sino desde la capacidad real. Si se prometen resoluciones en 30 minutos para cualquier incidente crítico, pero no hay monitorización, inventario actualizado, acceso remoto fiable ni personal suficiente, el acuerdo nace incumplible.
En sentido contrario, algunas empresas aceptan tiempos demasiado amplios por desconocimiento o por priorizar únicamente el precio. Ahí el coste oculto aparece después, en horas perdidas, clientes mal atendidos o personal improductivo.
Lo razonable es alinear el nivel de servicio con tres variables: criticidad, presupuesto y madurez operativa. Una pyme puede tener un SLA exigente en los sistemas que sostienen ventas, facturación o seguridad, y uno más flexible en incidencias menores. No todo tiene que tener la máxima cobertura para que el modelo funcione.
Un ejemplo práctico para pymes
Pensemos en una empresa de 60 empleados con ERP, correo, red interna y herramientas colaborativas. Si el ERP cae para toda la compañía, el SLA podría exigir respuesta en 15 minutos e inicio de intervención inmediato dentro de horario ampliado. Si falla el correo de un único usuario, quizá sea razonable una respuesta en una hora y resolución en el mismo día. Si se trata de una solicitud de alta de usuario, tal vez entre en otro acuerdo distinto, más cercano a la gestión de servicio que al soporte de incidencias.
Ese matiz importa. Mezclar incidencias, requerimientos y proyectos dentro del mismo SLA casi siempre genera ruido.
Errores frecuentes al definir un SLA de soporte TI
El primero es copiar un modelo estándar sin adaptar procesos ni riesgos. Lo que funciona para una empresa con equipo interno maduro no siempre sirve para una pyme que externaliza gran parte del soporte.
El segundo es no definir exclusiones. Cambios mayores, desarrollos, sustitución de hardware, soporte a software no autorizado o incidencias derivadas de terceros deben quedar regulados. No para limitar el servicio sin más, sino para que cada parte sepa qué esperar.
El tercero es olvidar la ciberseguridad. Hoy muchas incidencias de soporte tienen una dimensión de seguridad: cuentas comprometidas, accesos sospechosos, malware, pérdida de trazabilidad. Si el SLA no contempla estos escenarios con protocolos y tiempos específicos, la respuesta llega tarde.
El cuarto es no revisar el acuerdo periódicamente. El negocio cambia. También cambian las herramientas, los volúmenes de usuarios y los riesgos. Un SLA válido hace dos años puede quedarse corto hoy.
Cómo validar si el SLA está bien definido
Hay una prueba sencilla: leer cada cláusula y preguntarse si dos personas distintas la interpretarían igual durante una incidencia real. Si la respuesta es no, hay que aterrizar más.
También ayuda revisar datos históricos. Cuántas incidencias se abren al mes, cuáles son las más repetidas, cuánto tardan en resolverse y qué impacto generan. Sin ese contexto, el SLA se diseña a ciegas.
En nuestra experiencia con pymes, los mejores acuerdos son los que combinan precisión técnica con sentido operativo. No buscan impresionar con indicadores complejos. Buscan proteger el negocio, ordenar la relación de servicio y dar visibilidad a lo que de verdad importa.
Cuando conviene apoyarse en un proveedor especializado
Definir un SLA no siempre requiere documentos extensos, pero sí criterio. Si la empresa no cuenta con experiencia en gestión de soporte, externalizar esta definición con un partner especializado puede ahorrar errores costosos. Sobre todo cuando ya hay dependencia alta de sistemas, requisitos de continuidad o necesidad de coordinar soporte y ciberseguridad bajo un mismo marco.
Un proveedor con experiencia no solo propone tiempos. Ayuda a priorizar, delimitar alcances, detectar vacíos y ajustar el servicio a la realidad de la operación. Eso resulta especialmente valioso en entornos donde cada interrupción impacta ventas, atención al cliente o cumplimiento.
Definir bien un SLA de soporte TI no consiste en pedir más. Consiste en pedir lo correcto, medirlo con claridad y sostenerlo con procesos viables. Cuando ese trabajo se hace bien, el soporte deja de ser una fuente de incertidumbre y se convierte en una base estable para crecer con menos fricción.