El cliente dice: "es urgente".
El técnico piensa: "¿urgente para quién?".
El reloj corre… y nadie acordó qué significa responder.
Ahí nace el problema que un SLA sí puede evitar.
Un acuerdo de nivel de servicio no sirve para prometer que todo quedará resuelto en minutos. Sirve para definir qué atiendes, cuándo empieza el reloj, quién responde, cómo se escala y qué evidencia recibe el cliente.
Esta guía incluye una base operativa para un MSP pequeño. No sustituye la revisión de un abogado ni las condiciones comerciales de tu contrato; úsala para ordenar el servicio antes de convertirla en un compromiso legal.
1) Define qué controla el SLA
Un SLA no es una frase como "soporte rápido".
Eso no se puede medir.
El glosario de NIST describe el SLA como un compromiso entre proveedor y cliente que puede cubrir responsabilidades, tipo de servicio, desempeño esperado, tiempos de respuesta, reportes, resolución y terminación.
Para un MSP, eso se convierte en seis preguntas:
- ¿qué servicios y endpoints están cubiertos?;
- ¿en qué horario corre el compromiso?;
- ¿qué canal inicia una solicitud válida?;
- ¿cómo se asigna la prioridad?;
- ¿cuándo debe recibir respuesta y actualizaciones el cliente?;
- ¿qué queda fuera o se cotiza aparte?
Si una de esas respuestas vive solo en tu cabeza, todavía no tienes un SLA. Tienes una expectativa peligrosa.
2) Separa respuesta, actualización y resolución
Tres relojes. Tres cosas distintas.
Tiempo de primera respuesta: cuándo una persona confirma recepción, asigna responsable y comunica el siguiente paso.
Cadencia de actualización: cada cuánto informas mientras el incidente sigue abierto.
Objetivo de restauración o resolución: cuándo esperas recuperar el servicio o cerrar la causa, según dependencias y alcance.
PeopleCert explica en su práctica oficial de ITIL Service Level Management que los objetivos deben basarse en el negocio y que los niveles acordados deben monitorearse, reportarse y mejorarse.
Por eso no conviene prometer "resolución en 30 minutos" cuando podrías depender del proveedor de internet, una refacción, Microsoft, el fabricante o una autorización del cliente.
3) Asigna prioridad con impacto y urgencia
Todo es urgente cuando no existe una matriz.
Una prioridad útil combina:
- impacto: cuántas personas, ubicaciones o procesos están afectados;
- urgencia: cuánto puede esperar la operación antes de sufrir una consecuencia seria.
Puedes empezar con esta tabla y ajustarla a tu capacidad real:
| Prioridad | Ejemplo | Primera respuesta | Actualizaciones | Objetivo inicial |
|---|---|---|---|---|
| P1 Crítica | operación principal detenida, múltiples usuarios sin trabajar o posible incidente de seguridad activo | 30 minutos dentro de cobertura | cada 60 minutos | trabajar hasta restaurar o contener |
| P2 Alta | función importante degradada, varios usuarios afectados, existe una alternativa limitada | 2 horas hábiles | al menos una vez por día hábil | restaurar en 1 día hábil cuando dependa del MSP |
| P3 Normal | incidente individual con alternativa disponible | 4 horas hábiles | cuando cambie el estado | resolver en 2 días hábiles como objetivo |
| P4 Solicitud | alta, cambio, consulta o mejora sin interrupción | 1 día hábil | al acordar fecha | programar en 3 a 5 días hábiles |
P1 Crítica
operación principal detenida, múltiples usuarios sin trabajar o posible incidente de seguridad activo
30 minutos dentro de cobertura
cada 60 minutos
trabajar hasta restaurar o contener
P2 Alta
función importante degradada, varios usuarios afectados, existe una alternativa limitada
2 horas hábiles
al menos una vez por día hábil
restaurar en 1 día hábil cuando dependa del MSP
P3 Normal
incidente individual con alternativa disponible
4 horas hábiles
cuando cambie el estado
resolver en 2 días hábiles como objetivo
P4 Solicitud
alta, cambio, consulta o mejora sin interrupción
1 día hábil
al acordar fecha
programar en 3 a 5 días hábiles
No copies esos tiempos si no puedes sostenerlos. Mide primero cuántos tickets atiendes, cuántos técnicos tienes y qué horario vendes.
4) Escribe cuándo empieza, se pausa y termina el reloj
El cliente manda un WhatsApp a las 11:48 p. m.
¿Ya empezó el SLA?
La respuesta debe estar escrita antes de que ocurra.
Define como mínimo:
- zona horaria y horario de cobertura;
- días festivos y ventanas de mantenimiento;
- canal que crea un ticket válido;
- datos mínimos: cliente, usuario, endpoint, síntoma e impacto;
- si el tiempo corre fuera de horario para P1;
- cuándo se pausa por falta de acceso, aprobación, información o respuesta del cliente;
- cuándo se considera restaurado, resuelto o cerrado;
- cuántos intentos de contacto haces antes de cerrar por falta de respuesta.
La pausa no debe convertirse en truco para maquillar métricas. Debe tener causa, hora y evidencia visibles.
5) Define canales, responsables y escalamiento
Un buen SLA no solo dice "en cuánto".
También dice "quién sigue".
Ejemplo simple:
| Momento | Responsable | Acción |
|---|---|---|
| Entrada | mesa de ayuda o técnico de guardia | validar cliente, alcance, impacto y prioridad |
| Asignación | técnico responsable | confirmar recepción y siguiente acción |
| Escalamiento técnico | líder o especialista | intervenir cuando falta acceso, conocimiento o autoridad técnica |
| Escalamiento comercial | responsable de cuenta | resolver alcance, autorización, costo o expectativa |
| Comunicación ejecutiva | dueño del MSP o líder de servicio | informar incidentes P1 y decisiones necesarias |
Entrada
mesa de ayuda o técnico de guardia
validar cliente, alcance, impacto y prioridad
Asignación
técnico responsable
confirmar recepción y siguiente acción
Escalamiento técnico
líder o especialista
intervenir cuando falta acceso, conocimiento o autoridad técnica
Escalamiento comercial
responsable de cuenta
resolver alcance, autorización, costo o expectativa
Comunicación ejecutiva
dueño del MSP o líder de servicio
informar incidentes P1 y decisiones necesarias
Para cada P1, define también a quién llama el MSP del lado del cliente. Un incidente crítico sin contacto autorizado termina detenido justo cuando más importa.
6) Protege el alcance con exclusiones y responsabilidades
El SLA no debe convertir tu paquete mensual en trabajo infinito.
Aclara qué está incluido y qué requiere cotización, autorización o calendario independiente:
- endpoints, usuarios y ubicaciones no registrados;
- proyectos, migraciones, cableado y cambios mayores;
- soporte fuera de horario;
- fallas de terceros, aunque sí puedas coordinar el seguimiento;
- hardware, licencias y refacciones;
- recuperación cuando no existe respaldo válido;
- incidentes causados por accesos o cambios no autorizados;
- trabajo presencial y gastos de traslado.
El cliente también necesita responsabilidades: mantener contactos vigentes, dar acceso autorizado, responder solicitudes de información, aprobar cambios y reportar por el canal acordado.
7) Usa esta plantilla como punto de partida
Puedes adaptar este bloque a tu propuesta o anexo operativo:
```text ACUERDO DE NIVEL DE SERVICIO — BASE OPERATIVA
Cobertura:
- Servicios incluidos: [lista]
- Endpoints/usuarios/ubicaciones: [cantidad y alcance]
- Horario: [días, horas y zona horaria]
- Canal válido: [portal o correo]
Prioridades:
- P1 Crítica: [definición] — respuesta [tiempo] — actualización [frecuencia]
- P2 Alta: [definición] — respuesta [tiempo] — actualización [frecuencia]
- P3 Normal: [definición] — respuesta [tiempo] — objetivo [tiempo]
- P4 Solicitud: [definición] — respuesta [tiempo] — programación [tiempo]
Reglas del reloj:
- Inicia cuando [condición].
- Se pausa cuando [condiciones y evidencia].
- Termina cuando [restauración, resolución o cierre].
Escalamiento:
- Responsable inicial: [rol]
- Escalamiento técnico: [rol y condición]
- Escalamiento comercial: [rol y condición]
- Contacto autorizado del cliente: [rol]
Exclusiones:
- [proyectos, terceros, fuera de horario, hardware y otras]
Reporte mensual:
- cumplimiento de primera respuesta;
- tickets por prioridad;
- tiempos de restauración/resolución;
- tickets reabiertos o envejecidos;
- decisiones pendientes del cliente.
```
Antes de firmarla, revisa capacidad, dependencias, remedios, límites de responsabilidad y legislación aplicable con asesoría profesional.
8) Mide el SLA y revísalo cada mes
Un SLA guardado en PDF no mejora el servicio.
La revisión mensual sí puede hacerlo.
Mide al menos:
- porcentaje de tickets con primera respuesta dentro del objetivo;
- tiempo mediano de primera respuesta por prioridad;
- tiempo de restauración o resolución;
- tickets abiertos por antigüedad;
- tickets reabiertos;
- incidentes repetidos;
- tiempo detenido por decisión o respuesta del cliente;
- causas principales de incumplimiento.
CISA recomienda que incluso los equipos pequeños documenten y practiquen un plan de respuesta a incidentes. Para un MSP, una simulación sencilla de P1 ayuda a verificar contactos, escalamiento y comunicación antes del incidente real.
No uses el reporte para esconder fallas. Úsalo para decidir: ajustar capacidad, redefinir alcance, automatizar una tarea o corregir una promesa.
FAQ: SLA para MSPs
¿SLA significa tiempo garantizado de resolución?
No necesariamente. Puede incluir primera respuesta, actualizaciones, disponibilidad y objetivos de restauración o resolución. Distingue cada compromiso y sus dependencias.
¿Un MSP pequeño necesita cuatro prioridades?
Cuatro funcionan bien como punto de partida, pero puedes usar tres si tu operación es sencilla. Lo importante es que cada nivel tenga criterios y ejemplos claros.
¿Debo ofrecer soporte P1 las 24 horas?
Solo si tienes cobertura, rotación y precio para sostenerlo. Si no, define horario y proceso fuera de cobertura sin vender una disponibilidad que no existe.
¿Esta plantilla reemplaza un contrato?
No. Es una base operativa. Un profesional legal debe adaptar obligaciones, remedios, privacidad, responsabilidad y jurisdicción.
¿Cómo ayuda Lunixar RMM a cumplir un SLA?
Un RMM ayuda a centralizar contexto operativo como endpoints, alertas, parches, tickets, soporte remoto y reportes. El cumplimiento sigue dependiendo de tu alcance, personal, procesos y capacidad.
Un SLA debe proteger al cliente y al MSP
El cliente necesita saber qué puede esperar.
Tu equipo necesita saber qué debe hacer.
Y tu MSP necesita compromisos que realmente pueda cumplir.
Lunixar RMM puede apoyar esa operación al conectar visibilidad, alertas, soporte y evidencia desde una sola consola. Conoce Lunixar RMM para MSPs o inicia una prueba de 2 semanas sin tarjeta, con hasta 5 dispositivos y acceso completo.
Continúa con estas guías:
