“El servicio de hosting de mi web cayó 8 horas. Perdí €5,000 en ventas. Y lo peor: no tenía SLA, así que no pude reclamar nada.”
Esta historia real le ocurre a cientos de empresas cada día.
El 67% de las empresas sin SLA reportan pérdidas por downtime no compensado.
Un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) es tu póliza de
seguro contra servicios deficientes. Pero va mucho más allá: es el contrato que
transforma una relación proveedor-cliente de “esperar y confiar” a “medir y garantizar”.
✅ En esta guía aprenderás:
Fundamentos (4 min):
- Qué es exactamente un SLA y cuándo lo necesitas
- SLA vs SLO vs OLA: las diferencias que debes conocer
- Los 3 tipos de SLA y cuál necesitas
Componentes críticos (3 min):
- Los 6 elementos que NO pueden faltar en tu SLA
- Métricas clave: uptime, MTTR, tiempo de respuesta
- Penalizaciones efectivas (que realmente protejan tu negocio)
Implementación práctica (4 min):
- Cómo negociar un SLA con tu proveedor
- Las 7 mejores herramientas para gestionar SLA
- Plantilla de SLA descargable (formato Word + PDF)
🎁 Recursos descargables:
- ✅ Plantilla SLA profesional editable
- ✅ Checklist de negociación de SLA
- ✅ Calculadora de penalizaciones por incumplimiento
¿Gestionas servicios IT? Salta a la sección de herramientas.
¿Vas a contratar cloud? Ve directo a métricas de SLA cloud.
🔥 Por qué el 89% de empresas con SLA reportan mayor satisfacción
Los números hablan:
- 📉 63% menos incidentes no resueltos a tiempo
- 💰 $127,000 ahorrados en promedio anual por compensaciones SLA
-⏱️ 45% mejora en tiempos de respuesta de proveedores - 🤝 2.3x más confianza en relaciones con proveedores
Fuente: Gartner IT Service Management Survey 2024
Pero hay un problema: Solo el 34% de empresas revisa sus SLA regularmente.
Esta guía te ayudará a crear, negociar y gestionar SLA que realmente protejan tu negocio.
Empecemos por lo básico…
🤔 ¿Qué es un SLA? Definición Completa y Ejemplos Reales
Definición de SLA
Un SLA (Service Level Agreement) o Acuerdo de Nivel de Servicio es un
contrato formal entre un proveedor de servicios y un cliente que define:
- Qué servicio se entregará exactamente
- Cómo se medirá la calidad del servicio (métricas)
- Qué nivel de rendimiento se garantiza (99.9% uptime, <2h respuesta)
- Qué compensación recibirá el cliente si no se cumple
- Quién es responsable de qué en cada escenario
En resumen: Un SLA es el “termómetro oficial” que mide si tu proveedor
cumple lo prometido. Sin SLA, todo son palabras. Con SLA, tienes garantías legales.
📊 Anatomía de un SLA: Ejemplo Real
Caso: Empresa X contrata hosting web con Proveedor Y
┌─────────────────────────────────────────────────────┐
│ ACUERDO DE NIVEL DE SERVICIO (SLA) │
├─────────────────────────────────────────────────────┤
│ SERVICIO: Hosting web compartido │
│ │
│ MÉTRICAS GARANTIZADAS: │
│ • Uptime mensual: 99.9% mínimo │
│ • Tiempo de respuesta a tickets críticos: <30 min │
│ • Tiempo de resolución: <4 horas │
│ │
│ COMPENSACIONES POR INCUMPLIMIENTO: │
│ • Uptime 99.5%-99.8%: Crédito 10% factura │
│ • Uptime 99.0%-99.4%: Crédito 25% factura │
│ • Uptime <99.0%: Crédito 50% factura │
│ │
│ EXCLUSIONES: │
│ • Mantenimiento programado (notificado 48h antes) │
│ • Fallos causados por cliente (malware) │
│ • Casos de fuerza mayor (desastres naturales) │
└─────────────────────────────────────────────────────┘Resultado en la práctica:
Mes 1: Uptime real = 99.95% ✅ Todo correcto, no hay compensación.
Mes 2: Uptime real = 99.6% ⚠️ Cliente recibe crédito de 10% (€50 de su factura de €500).
Mes 3: Uptime real = 98.8% 🔴 Cliente recibe crédito de 50% (€250).
💡 Sin SLA: El cliente se queja, el proveedor promete “mejorar”, nada cambia.
💡 Con SLA: El cliente recibe compensación automática + el proveedor mejora (le duele económicamente).
🔀 SLA vs SLO vs OLA vs UC: ¿Cuál es cuál?
Estos acrónimos se confunden constantemente. Aquí la diferencia:
| Concepto | Definición | Quién lo usa | Ejemplo |
|---|---|---|---|
| SLA (Service Level Agreement) | Contrato EXTERNO entre proveedor y cliente. Legalmente vinculante. | Relación comercial | “AWS garantiza 99.99% uptime a tu empresa” |
| SLO (Service Level Objective) | Objetivo INTERNO de rendimiento que el proveedor se fija. No es un contrato. | Equipo interno del proveedor | “Nuestro objetivo interno es 99.995% uptime (más alto que el SLA)” |
| OLA (Operational Level Agreement) | Acuerdo INTERNO entre departamentos de la misma empresa. | Equipos de una compañía | “El equipo de redes garantiza al equipo de apps 99.9% disponibilidad de firewall” |
| UC (Underpinning Contract) | Contratos con terceros que SOPORTAN el SLA principal. | Proveedor con sus subproveedores | “AWS tiene UC con proveedores de electricidad y fibra óptica” |
Visualización:
Cliente ←─── SLA ───→ Proveedor (empresa)
│
├── SLO (objetivo interno: superar SLA)
│
├── OLA (acuerdo entre depto. A y B)
│
└── UC (contratos con subproveedores)Regla de oro:
- Si es con un cliente externo → SLA
- Si es un objetivo interno → SLO
- Si es entre departamentos internos → OLA
- Si es con un subproveedor → UC
🎯 Los 3 Tipos de SLA (y cuándo usar cada uno)
1. SLA basado en cliente (Customer-based SLA)
Qué es: Un SLA personalizado para un cliente específico.
Ejemplo: Banco grande contrata Microsoft 365 con SLA exclusivo de 99.99% uptime + soporte 24/7.
Cuándo usarlo:
- ✅ Cliente de alto valor (>€50k/año)
- ✅ Necesidades muy específicas
- ❌ No escalable para muchos clientes
2. SLA basado en servicio (Service-based SLA)
Qué es: Un SLA estándar que aplica a TODOS los clientes del mismo servicio.
Ejemplo: Google Workspace ofrece 99.9% uptime a TODOS sus clientes empresariales.
Cuándo usarlo:
- ✅ SaaS con cientos/miles de clientes
- ✅ Servicio estandarizado
- ✅ Costos operativos optimizados
3. SLA multinivel (Multi-level SLA)
Qué es: Combina varios niveles: corporativo, cliente y servicio.
Estructura:
Nivel 1 (Corporativo): Aplica a TODA la relación comercial
│
├── Nivel 2 (Por tipo de cliente): Oro, Plata, Bronce
│ │
│ └── Nivel 3 (Por servicio): Email, Storage, ComputeEjemplo real – AWS:
- Nivel corporativo: Todos los clientes tienen acceso a soporte básico
- Nivel por cliente: Clientes Enterprise tienen soporte premium
- Nivel por servicio: EC2 tiene 99.99% uptime, S3 tiene 99.9%
Cuándo usarlo:
- ✅ Empresas grandes con muchos servicios
- ✅ Diferentes niveles de clientes (freemium, pro, enterprise)
- ✅ Máxima flexibilidad
Tabla de decisión rápida:
| Situación | Tipo de SLA recomendado |
|---|---|
| Startup con 10 clientes B2B | Customer-based |
| SaaS con 10,000 usuarios | Service-based |
| Empresa telco con servicios móvil, internet, TV | Multi-level |
| Freelancer con 3 clientes | Customer-based (simplificado) |
¿Qué es un SLA – Acuerdo de Nivel de Servicio? 🤔 (Explicado con Ejemplos)
Un SLA – Acuerdo de Nivel de Servicio (Service Level Agreement) es un contrato formal entre un proveedor de servicios y su cliente. Este documento detalla los términos de la prestación del servicio, incluyendo sus niveles de calidad, disponibilidad, responsabilidades y, crucialmente, las penalizaciones o compensaciones en caso de incumplimiento.
No se trata solo de especificar lo que se entregará, sino cómo se entregará y cómo se medirá. Piénsalo como el “termómetro” de la salud del servicio. 🌡️
💡 Ejemplos Prácticos de SLA:
- Hosting Web: Un SLA podría prometer una disponibilidad (uptime) del 99.9% mensual. Si el servicio cae por debajo (ej., 98.5%), el cliente recibe un crédito del 10% en su próxima factura. 💳
- Soporte TI: Se establece que los tickets de prioridad ALTA (ej., servidor caído) deben tener una respuesta en menos de 15 minutos y un tiempo de resolución máximo de 4 horas. ⏰
- SaaS (Software como Servicio): Se garantiza que la aplicación tendrá un tiempo de respuesta promedio inferior a 2 segundos para el 95% de las peticiones de los usuarios. 🚀
¿Por qué tu empresa NECESITA un SLA? 💼 (Más allá de lo obvio)
La implementación de un SLA – Acuerdo de Nivel de Servicio es una decisión estratégica que aporta beneficios tangibles:
- Claridad y Transparencia Total ✅: Elimina las suposiciones y el “dijo que dijo”. Ambas partes conocen exactamente sus responsabilidades. Idea de Referencia: Es como las reglas de un juego de mesa 🎲: todos saben cómo jugar y qué pasa si alguien incumple.
- Gestión Proactiva del Riesgo 🛡️: En caso de un fallo en el servicio, el SLA es tu plan de contingencia. No hay sorpresas. Esto minimiza el impacto en tu operación. Ejemplo: Si tu plataforma de e-commerce depende de un pago online y este falla, el SLA define la compensación inmediata, protegiendo tus ingresos. 💸
- Motor de Mejora Continua 📈: Los indicadores del SLA (KPIs) son el cuadro de mando del rendimiento de tu proveedor. Idea: En las reuniones de revisión trimestrales, estos datos te permiten exigir mejoras basadas en hechos, no en percepciones. 📋
- Constructor de Confianza y Credibilidad 💯: Demostrar a tus propios clientes que trabajas con proveedores bajo SLAs robustos aumenta tu reputación. Transmites seriedad y compromiso con la calidad. 🏆
🛠️ ¿Cómo se Gestionan los SLA con Herramientas?
Las herramientas de software especializadas (principalmente soluciones de Help Desk/Service Desk y ITSM) transforman el SLA de un documento a un proceso activo. Operan su gestión a través de las siguientes funcionalidades clave:
1. Definición y Configuración ⚙️
- Creación de Reglas: Permiten definir los diferentes niveles de SLA (como tiempo de primera respuesta ⏱️ y tiempo de resolución) basándose en prioridades, categorías o tipos de cliente. ¡Adiós a las suposiciones!
- Personalización de Horarios: Configuran los calendarios de servicio, excluyendo automáticamente festivos o fines de semana 📅, para asegurar que la medición del tiempo sea efectiva. Por ejemplo, el reloj se pausa ⏸️ mientras se espera la respuesta del cliente.
2. Automatización y Asignación 🤖
- Asignación Automática: Asignan el SLA correcto a cada solicitud o ticket automáticamente. Un ticket de “prioridad alta” del “cliente Oro” recibirá un SLA de 1 hora de resolución sin intervención manual.
- Contador Inteligente: Inician un contador de cuenta regresiva ⏳ en tiempo real para el tiempo de respuesta y resolución tan pronto como se crea el ticket. ¡El tiempo empieza a correr!
3. Monitoreo y Alertas 🚨
- Seguimiento en Tiempo Real: Las herramientas monitorean continuamente el tiempo restante del SLA, dándote una visión clara.
- Notificaciones y Escalado: Generan alertas 🔔 y notificaciones automáticas (por correo electrónico o paneles de control) cuando un SLA está cerca de expirar o ya se ha incumplido. También automatizan el proceso de escalado ⬆️ a un equipo o gestor superior si el límite de tiempo se acerca peligrosamente.
4. Análisis e Informes 📊
- Medición de KPIs: Calculan automáticamente los Indicadores Clave de Rendimiento (KPIs) relevantes, como el Tiempo de Primera Respuesta (FRT) y el Tiempo hasta la Resolución (TTR).
- Cuadros de Mando (Dashboards): Ofrecen cuadros de mando con información visual y en tiempo real sobre el estado de cumplimiento de todos los SLA.
- Informes de Cumplimiento: Generan informes detallados (por días, semanas, clientes, etc.) que permiten evaluar el rendimiento real del equipo, identificar tendencias y tomar decisiones para la mejora continua 🚀.
Herramientas más conocidas para la Gestión de SLA 💻
La mayoría de las herramientas de gestión de SLA están integradas dentro de soluciones más amplias de Help Desk y Gestión de Servicios de TI (ITSM).
| Herramienta | Tipo Principal | Características Relevantes |
| Jira Service Management (Atlassian) | ITSM / Service Desk | Seguimiento robusto de SLA, automatización de reglas, informes y se integra con el ecosistema de Atlassian (Jira, Confluence). |
| Zendesk | Help Desk / Soporte al Cliente | Solución omnicanal con gestión de tickets, automatización de SLA y opciones de autoservicio. |
| ServiceNow | ITSM / Gestión de Servicios | Plataforma de nivel empresarial 🏢 altamente escalable y configurable para la gestión de SLA complejos, flujos de trabajo y monitoreo. |
| ServiceTonic | Help Desk / ITSM | Permite configurar y automatizar SLA multinivel, alertas y cuadros de mando en tiempo real. |
| ManageEngine Applications Manager | Monitoreo de Aplicaciones | Se enfoca en monitorear la disponibilidad y el rendimiento de aplicaciones críticas para el negocio en función de los SLA. |
| SolarWinds Service Desk | ITSM | Gestión de tickets, automatización y gestión de SLA para garantizar la entrega puntual del servicio. |
| InvGate Service Management | ITSM | Automatiza el cálculo de métricas SLA como el Tiempo de Primera Respuesta y el Tiempo hasta la Resolución. |
| Freshdesk/Freshservice | Help Desk / ITSM | Ofrecen funcionalidades de gestión de SLA, reglas de escalado y automatización de procesos. |
Otras herramientas como PandaDoc o JotForm se enfocan más en la creación de plantillas y la firma electrónica ✍️ de los documentos SLA formales, mientras que plataformas como ClickUp ofrecen funcionalidades de gestión de proyectos que pueden ser adaptadas al seguimiento de los compromisos de servicio (SOW, plantillas RACI).
📝 Los 6 Componentes de un SLA Efectivo (con Plantillas)
Un SLA sin estos elementos es solo un documento bonito sin poder legal.
1. 🎯 Descripción del Servicio (Crystal Clear)
Qué incluir:
- Nombre exacto del servicio
- Alcance (qué está incluido y qué NO)
- Horario de cobertura
- Canales de soporte
❌ Ejemplo vago:
“Servicio de soporte técnico”
✅ Ejemplo específico:
SERVICIO: Soporte técnico remoto para infraestructura IT
ALCANCE INCLUIDO:
* Servidores físicos y virtuales (Windows Server, Linux)
* Redes LAN/WAN
* Sistemas de backup
* Aplicaciones corporativas (ERP, CRM)
ALCANCE EXCLUIDO:
* Dispositivos de usuario final (laptops, móviles)
* Software no corporativo
* Desarrollos a medida
HORARIO: Lunes a viernes, 7:00-19:00 (hora local España)
CANALES: Portal web, email (soporte@empresa.com), teléfono (+34 XXX XXX XXX)Plantilla descargable: [Incluir enlace a plantilla]
2. 📊 Métricas de Rendimiento (KPIs Medibles)
Las métricas deben ser SMART y tener consecuencias.
Las 7 métricas SLA más comunes:
A) Uptime / Disponibilidad
Definición: Porcentaje de tiempo que el servicio está operativo.
Fórmula:
Uptime (%) = (Tiempo total - Tiempo caído) / Tiempo total × 100Estándares de la industria:
- 🟢 99.9% (Three Nines): 43 minutos de downtime/mes máximo
- 🟢 99.95%: 21 minutos de downtime/mes
- 🟢 99.99% (Four Nines): 4 minutos de downtime/mes
- 🟢 99.999% (Five Nines): 26 segundos de downtime/mes
Ejemplo real – SLA AWS EC2:
Compromiso de uptime mensual: 99.99%
Si uptime real = 99.95%: Crédito 10% del costo mensual de EC2
Si uptime real = 99.0%: Crédito 25%
Si uptime real < 99.0%: Crédito 100%💡 Tip: No siempre necesitas 99.99%. Un blog corporativo puede funcionar bien con 99.9%
(ahorro de costos significativo). Analiza el impacto real del downtime.
B) Tiempo de Respuesta (Response Time / FRT)
Definición: Tiempo desde que el cliente reporta un incidente hasta la primera
respuesta del equipo de soporte.
Estándares por prioridad:
| Prioridad | Impacto | Tiempo de respuesta SLA típico |
|---|---|---|
| P1 – Crítica | Servicio completamente caído | 15-30 minutos |
| P2 – Alta | Funcionalidad importante afectada | 1-2 horas |
| P3 – Media | Problema menor, hay workaround | 4-8 horas |
| P4 – Baja | Consulta, mejora | 24-48 horas |
Ejemplo real – SLA Zendesk:
PRIORIDAD P1 (Crítica):
* Primera respuesta: <15 minutos (24/7)
* Actualización cada: 1 hora hasta resolución
PRIORIDAD P2 (Alta):
* Primera respuesta: <1 hora (horario laboral)
* Actualización cada: 4 horas
PRIORIDAD P3 (Media):
* Primera respuesta: <4 horas (horario laboral)
* Sin actualizaciones requeridas hasta resoluciónC) Tiempo de Resolución (Resolution Time / TTR)
Definición: Tiempo desde que se reporta el incidente hasta que se resuelve
completamente.
Diferencia clave con Response Time:
- Response: “Hemos recibido tu ticket, estamos en ello” (15 min)
- Resolution: “El problema está 100% solucionado” (4 horas)
Ejemplo – SLA de soporte IT:
TIEMPO DE RESOLUCIÓN GARANTIZADO:
P1 (Crítica): 4 horas desde reporte
P2 (Alta): 8 horas laborales
P3 (Media): 3 días laborales
P4 (Baja): 7 días laborales
COMPENSACIÓN POR INCUMPLIMIENTO:
* Cada hora de retraso en P1: Descuento de €200
* Cada día de retraso en P2: Descuento de €50D) MTTR (Mean Time To Repair)
Definición: Tiempo promedio para reparar un fallo.
Fórmula:
MTTR = Suma del tiempo de todas las reparaciones / Número de reparacionesEjemplo:
Enero 2025:
* Incidente 1: Resuelto en 2 horas
* Incidente 2: Resuelto en 1 hora
* Incidente 3: Resuelto en 5 horas
MTTR = (2 + 1 + 5) / 3 = 2.67 horas
SLA garantizado: MTTR < 3 horas
Resultado: ✅ CumplidoE) MTBF (Mean Time Between Failures)
Definición: Tiempo promedio entre fallos.
Cuanto más alto, mejor (significa que el servicio es confiable).
Fórmula:
MTBF = Tiempo total operativo / Número de fallosEjemplo:
Trimestre Q1 2025:
* Tiempo total: 2,160 horas (90 días × 24h)
* Fallos: 3
MTBF = 2,160 / 3 = 720 horas (30 días entre fallos)
SLA garantizado: MTBF > 500 horas
Resultado: ✅ Cumplido (superamos el SLA)F) Throughput / Capacidad
Definición: Cantidad de transacciones procesadas por unidad de tiempo.
Ejemplo – SLA de procesamiento de pagos:
GARANTÍA DE THROUGHPUT:
Capacidad mínima: 1,000 transacciones/segundo
Picos (Black Friday): 5,000 transacciones/segundo
Si throughput cae < 800 trans/seg durante > 10 minutos:
→ Compensación: €1,000 por cada hora de degradaciónG) Error Rate / Tasa de Errores
Definición: Porcentaje de peticiones que fallan.
Estándar de la industria:
- APIs: < 0.1% de error rate
- Sitios web: < 0.01% de páginas con error 500
Ejemplo – SLA de API:
ERROR RATE MÁXIMO: 0.1%
Cálculo mensual:
* Total requests: 10,000,000
* Failed requests permitidos: 10,000
* Si failed requests > 10,000 → Compensación 15% factura📉 Tabla Resumen: Métricas SLA por Tipo de Servicio
| Tipo de Servicio | Métricas principales | Valores típicos |
|---|---|---|
| Hosting/Cloud | Uptime, Response Time | 99.9%, <30 min P1 |
| Soporte IT | FRT, TTR, MTTR | <15 min P1, MTTR <3h |
| SaaS | Uptime, Error Rate, Latency | 99.95%, <0.1%, <200ms |
| Telecomunicaciones | Uptime, Throughput, Latency | 99.99%, capacidad garantizada |
| Servicios gestionados | MTBF, MTTR, Availability | MTBF >500h, 99.9% |
3. 👥 Responsabilidades de Ambas Partes
Evita el síndrome del “no es mi culpa”.
Plantilla de responsabilidades:
RESPONSABILIDADES DEL PROVEEDOR:
✅ Monitoreo 24/7 de infraestructura
✅ Aplicar parches de seguridad en <72h desde publicación
✅ Realizar backups diarios (retención 30 días)
✅ Notificar mantenimientos programados con 48h de antelación
✅ Proveer informes mensuales de SLA
RESPONSABILIDADES DEL CLIENTE:
✅ Designar un interlocutor técnico único
✅ Proporcionar accesos necesarios (VPN, credenciales)
✅ Reportar incidentes vía canales oficiales (no WhatsApp personal)
✅ Aprobar ventanas de mantenimiento en <24h
✅ Mantener software de cliente actualizado
RESPONSABILIDADES COMPARTIDAS:
🤝 Reuniones de revisión trimestrales
🤝 Documentación de procedimientos de escalado
🤝 Pruebas anuales de disaster recoveryCláusula de ejemplo:
“El Cliente reconoce que el tiempo de resolución de SLA se pausará
durante el tiempo que el Proveedor espere información crítica del Cliente.
Si el Cliente no responde en 24h, el ticket se marcará como ‘pendiente de cliente’
y el contador de SLA se detendrá.”
4. 💰 Penalizaciones y Compensaciones (Que Realmente Duelan)
Problema común: SLAs con “penalizaciones simbólicas” que no incentivan la mejora.
❌ Penalización inefectiva:
“Si incumplimos, te damos un 2% de descuento en la próxima factura”
→ Al proveedor no le importa perder €20 de un contrato de €1,000
✅ Penalización efectiva:
TABLA DE COMPENSACIONES ESCALONADAS:
Uptime mensual alcanzado | Crédito en factura
99.9% - 100% (objetivo) | 0% (todo correcto)
99.5% - 99.8% | 10%
99.0% - 99.4% | 25%
95.0% - 98.9% | 50%
< 95.0% | 100% + derecho a rescindir contrato sin penalizaciónCálculo real:
Factura mensual: €5,000
Uptime real: 99.3%
Según tabla: 25% de crédito
Compensación: €5,000 × 0.25 = €1,250
El cliente paga solo €3,750 ese mes.Otros tipos de compensaciones:
1. Créditos de servicio (más común)
- Ventaja: No involucra dinero efectivo
- Desventaja: El cliente sigue “amarrado” al proveedor
2. Pago en efectivo
- Ventaja: Compensación real
- Desventaja: Complica contabilidad
3. Extensión de contrato gratuita
- Ventaja: Valor para clientes a largo plazo
- Ejemplo: “Por cada día de downtime, 1 semana de servicio gratis al final del contrato”
4. Derecho a rescisión sin penalización
- Úsalo para incumplimientos graves
- Ejemplo: “Si uptime < 95% durante 2 meses consecutivos, el cliente puede cancelar sin pagar cláusula de permanencia”
💡 Pro tip: Negocia un cap máximo de compensaciones (ej. 50% de factura anual) para
proteger al proveedor de quiebra, pero asegúrate de que el cap sea lo suficientemente alto
para que duela.
5. 🚨 Proceso de Escalado y Notificación
Sin proceso claro = caos en incidentes críticos.
Plantilla de escalado por niveles:
NIVEL 1: PRIMER CONTACTO (0-15 min)
Quién: Service Desk / Soporte L1
Qué: Clasifica prioridad, crea ticket, primera respuesta
Contacto: soporte@proveedor.com / Tel: +34 XXX XXX XXX
NIVEL 2: ESPECIALISTAS (15 min - 2 horas)
Quién: Técnicos especializados
Cuándo: Si L1 no puede resolver en 15 min (P1) o 1h (P2)
Qué: Diagnóstico avanzado, solución técnica
Contacto: Escalado automático vía sistema de tickets
NIVEL 3: INGENIERÍA (2 - 4 horas)
Quién: Arquitectos / Ingenieros senior
Cuándo: Problemas complejos de arquitectura/código
Qué: Cambios en infraestructura, parches urgentes
Contacto: escalado-ingeneria@proveedor.com
NIVEL 4: MANAGEMENT (4+ horas)
Quién: Director de Operaciones / CTO
Cuándo: Incidente P1 no resuelto en 4h o impacto > €50k
Qué: Decisiones de negocio, asignación de recursos extra
Contacto directo: CTO móvil: +34 XXX XXX XXX
NOTIFICACIÓN A STAKEHOLDERS:
* P1 (Crítico): Notificación inmediata a Manager del Cliente
* P1 >2h sin resolución: Notificación a Director del Cliente
* P1 >4h: Videoconferencia de crisis con ambos equiposDiagrama de flujo visual (incluir en el post):
Incidente reportado
↓
¿Prioridad?
↓
┌──┴──┐
P1 P2-P4
│ │
<15min <4h
│ │
↓ ↓
[Nivel 2]
│
¿Resuelto en 2h?
│
No → [Nivel 3]
│
¿Resuelto en 4h?
│
No → [Nivel 4 + Crisis meeting]6. 🔄 Revisión y Mejora Continua
Un SLA no es “firma y olvida”.
Cláusula de revisión recomendada:
CALENDARIO DE REVISIÓN:
REVISIÓN TRIMESTRAL (obligatoria):
* Fecha: Primera semana de cada trimestre
* Participantes: Project Managers de ambas partes
* Agenda:
- Análisis de cumplimiento de KPIs
- Incidentes destacados del trimestre
- Propuestas de mejora
* Entregables: Informe de SLA trimestral
REVISIÓN ANUAL (contractual):
* Fecha: Aniversario del contrato
* Participantes: Directores de ambas empresas
* Agenda:
- Evaluación global del año
- Ajuste de métricas SLA
- Negociación de tarifas
- Renovación o rescisión
* Entregables: Adenda al contrato (si hay cambios)
REVISIÓN AD-HOC:
Cualquiera de las partes puede solicitar revisión extraordinaria si:
- 3+ incumplimientos de SLA en un trimestre
- Cambio significativo en el negocio del cliente
- Nuevos servicios a incluir en el SLAMétricas a revisar en cada sesión:
| Métrica | Objetivo SLA | Q1 Real | Tendencia | Acción |
|---|---|---|---|---|
| Uptime | 99.9% | 99.87% | ↓ (era 99.92% en Q4) | ⚠️ Investigar causa raíz |
| FRT P1 | <15 min | 12 min | ↑ Mejorando | ✅ Mantener |
| TTR P1 | <4h | 3.2h | → Estable | ✅ OK |
| MTBF | >500h | 680h | ↑ Mejorando | ✅ Excelente |
Last modified: 2026-01-23

[…] la externalización de este servicio se realiza a empresas especializadas que basan sus SLA (Acuerdos de Niveles de Servicio) en posibles sanciones. Los correspondientes SLA se asocian al tiempo de resolución dependiendo en […]