SLA soporte IT es la diferencia entre “tenemos soporte” y “tenemos continuidad”.
Porque el día que un sistema crítico cae, no importa cuántos técnicos haya: importa cuánto tardan en responder, cuánto tardan en resolver y qué ocurre si no cumplen.
En esta guía vas a ver exactamente qué cláusulas pedir, cómo evitar ambigüedades y cómo convertir un contrato de soporte en un acuerdo medible (y defendible).
Qué es un SLA y por qué en B2B debe ser un “acuerdo de negocio”
Un SLA (Service Level Agreement) es un acuerdo entre proveedor y cliente que define el servicio y el nivel de rendimiento esperado. En B2B no sirve si no aterriza en métricas y responsabilidades.
- Dirección quiere minimizar paradas y riesgos contractuales.
- Operaciones quiere resolver rápido sin improvisación.
- Compras quiere claridad: qué entra, qué no entra y cuánto cuesta incumplir.
Checklist de SLA soporte IT (PDF) para comprar soporte sin letra pequeña
- Resultado: reduces malentendidos típicos (alcance, horarios, severidades) y aceleras la comparación de proveedores.
- Tiempo: 5 minutos para solicitarlo + entrega en 24–48h.
Para quién es: empresas B2B con 20–500 usuarios (IT interno o proveedor externo) que necesitan soporte 24/7 o ampliación de cobertura.
SLA soporte IT: 9 cláusulas que debes exigir (con ejemplos)
1) Alcance del servicio (qué entra y qué NO entra)
La mayoría de conflictos nacen aquí. Define por escrito:
- Qué cubre: usuarios, puestos, servidores, red, cloud, M365/Google Workspace, backups, etc.
- Qué queda fuera: desarrollos, cambios mayores, proyectos, hardware no gestionado, terceros sin acceso, etc.
- Qué se considera “incidente” vs “solicitud” vs “cambio”.
2) Horario real y canales (y qué significa “24/7”)
“24/7” debe especificar canales (teléfono, email, portal, chat), cobertura real y si incluye guardias o equipo dedicado. Si no está definido, el SLA soporte IT es solo marketing.
3) Severidades (impacto) y criterios de clasificación
La severidad debe depender del impacto en negocio, no de “quién se queja más”. Exige criterios simples: número de usuarios afectados, caída total/parcial, servicio crítico, impacto económico.
4) Tiempos de respuesta y tiempos de resolución (no son lo mismo)
El tiempo de primera respuesta es el reconocimiento inicial y el compromiso; el tiempo de resolución es cuando el problema queda solucionado o hay workaround aceptado. Muchos proveedores confunden ambos. :contentReference[oaicite:4]{index=4}
Ejemplo de tabla (ajústala a tu negocio):
| Severidad | Ejemplo | Primera respuesta | Resolución objetivo |
|---|---|---|---|
| P1 Crítica | Servicio core caído / operación detenida | 10–15 min | 2–4 h (o workaround) |
| P2 Alta | Impacto alto / muchos usuarios | 30–60 min | 8–12 h |
| P3 Media | Impacto moderado / workaround disponible | 4 h | 1–3 días |
| P4 Baja | Consulta, ajuste menor, solicitud | 1 día | 3–10 días |
5) Escalado técnico y escalado de negocio
Un SLA soporte IT sólido define:
- Cuándo se escala a un nivel superior (L2/L3, fabricante, cloud provider).
- Quién aprueba acciones que impactan negocio (paradas controladas, cambios urgentes).
- Frecuencia de actualizaciones (“updates”) durante un P1.
6) Métricas de control: MTTD, MTTR y cumplimiento de SLA
Para que el SLA sea medible, necesitas reporting. Ejemplos:
- MTTD (tiempo medio de detección) y MTTR (tiempo medio de resolución).
- % de tickets dentro de SLA por severidad.
- Top 10 causas raíz y acciones preventivas.
7) Disponibilidad y mantenimiento planificado
Si el SLA incluye “uptime”, define cómo se mide, qué se excluye (mantenimiento planificado) y cómo se comunica. Los SLA suelen incluir disponibilidad y capacidad de respuesta como compromisos típicos. :contentReference[oaicite:5]{index=5}
8) Seguridad y cumplimiento (cuando el soporte toca sistemas sensibles)
En B2B, el soporte suele tener acceso privilegiado. Exige:
- Gestión de accesos (mínimo privilegio, MFA, trazabilidad).
- Registro de cambios y evidencias para auditoría.
- Procedimiento de incidentes (qué pasa si el “ticket” es un incidente de seguridad).
9) Penalizaciones, créditos de servicio y salida (exit plan)
Si el proveedor incumple sistemáticamente, debe haber consecuencias: créditos, descuentos o penalizaciones. Además, define un plan de salida: documentación, handover, inventario, contraseñas y accesos.
Cómo evitar pagar de más: 5 errores típicos al negociar un SLA soporte IT
- Comprar 24/7 cuando tu operación crítica es 12/5 (o al revés).
- No separar respuesta de resolución (te “responden” rápido, pero no resuelven).
- Sin inventario de activos: el proveedor no puede comprometerse a lo que no conoce.
- Sin monitorización: todo depende de que alguien “abra ticket”.
- Sin exclusiones claras: acabas pagando “proyectos” como si fueran soporte.
Si estás en esta situación… conviene revisar tu SLA soporte IT antes de renovar
- Tu equipo pierde horas “persiguiendo” tickets sin visibilidad de tiempos ni responsables.
- Tienes paradas repetidas y nadie te presenta acciones preventivas con fechas.
- Compras quiere comparar proveedores, pero los SLAs no son equivalentes.
Acción concreta: revisión técnica + plan de estabilización con 5 quick wins (prioridad alta) para reducir incidencias y mejorar el cumplimiento del SLA.
Resultado: SLA alineado a tu negocio + métricas mínimas + propuesta de mejora por fases.
Tiempo: 30 minutos (sesión) + resumen y próximos pasos en 48–72h.
Ver enfoque de soporte gestionado
Plantilla rápida: qué pedir en un RFP de SLA soporte IT
Si vas a pedir propuestas, copia y pega este “mínimo exigible”:
- Servicios cubiertos + exclusiones + definición de incidente/solicitud/cambio.
- Severidades con criterios objetivos + tiempos de respuesta y resolución.
- Canales + horarios + escalados + frecuencia de actualizaciones en P1.
- Reporting mensual con métricas (cumplimiento SLA, MTTR, causas raíz, mejoras).
- Seguridad de accesos + trazabilidad + procedimiento de incidentes.
- Penalizaciones/créditos + exit plan.
Preguntas frecuentes sobre SLA soporte IT
¿Qué SLA debería exigir una pyme B2B?
Depende de criticidad. Si tu facturación depende de sistemas (ERP, eCommerce, operación 24/7), exige P1 con primera respuesta en minutos y resolución objetivo con workaround. Si no, puedes optimizar costes con coberturas 12/5 o 16/5.
¿Qué es más importante: primera respuesta o resolución?
Ambas. La primera respuesta reduce incertidumbre, pero la resolución protege negocio. Por eso se miden por separado en políticas de SLA y herramientas de soporte.
¿Cómo se mide el cumplimiento del SLA soporte IT?
Por porcentaje de tickets dentro de SLA por severidad, más métricas de calidad (MTTR, recurrencias, causas raíz). Sin reporting, no hay SLA: hay promesas.
¿Tiene sentido incluir penalizaciones?
Sí, sobre todo si el servicio es crítico o contractual. Más que “castigar”, sirven para alinear incentivos. Acompáñalas de un plan de mejora: si no, solo cambias de proveedor y repites problemas.
¿Qué relación tiene el SLA con disponibilidad (uptime)?
Son compromisos distintos: el SLA puede incluir disponibilidad, capacidad de respuesta y resolución. Lo clave es definir cómo se mide y qué queda fuera (mantenimiento planificado). :contentReference[oaicite:7]{index=7}
¿Cómo evito que el proveedor culpe a “terceros”?
Define escalados y responsabilidades: quién abre caso con el fabricante/cloud provider, en qué plazo y cómo se te mantiene informado. Eso debe estar dentro del SLA soporte IT.
Un SLA soporte IT bueno te compra previsibilidad
El mejor SLA no es el más agresivo: es el que encaja con tu negocio, reduce paradas y te permite exigir mejoras con datos.
Si quieres un SLA soporte IT que realmente funcione (severidades, tiempos, reporting y mejora continua), podemos ayudarte a definirlo y operarlo con soporte 24/7.
- Resultado: menos incidencias repetidas y mayor cumplimiento por severidad en 30–60 días.
- Tiempo: propuesta inicial en 5–10 días laborables (según alcance y número de usuarios).
- Riesgo reducido: escalados definidos, trazabilidad y plan de mejora con métricas.
Solicitar propuesta de soporte 24/7 con SLA | Ver servicios