Límites de alcance y SLA para MSP pequeños

Respuesta corta: Un límite de alcance protege la promesa de servicio. Le dice al cliente qué está incluido, qué necesita aprobación y dónde un objetivo de respuesta deja de ser una garantía de resolución.

El alcance es la línea de servicio

Los MSP pequeños pierden margen cuando cualquier problema técnico se vuelve soporte incluido. El problema rara vez es un ticket. El problema es el patrón recurrente donde limpieza, presión de vendors, sistemas no soportados, trabajo fuera de horario y cambios de proyecto se tratan como servicio mensual normal.

La guía de precios de servicios administrados debe definir el precio. Esta guía define la línea que ese precio financia.

Usa marcos de referencia para aclarar responsabilidad, no para inflar la promesa. El NIST Cybersecurity Framework 2.0 separa gobernar, identificar, proteger, detectar, responder y recuperar. El alcance de un MSP pequeño debe decir cuáles de esas funciones están incluidas, apoyadas, excluidas o manejadas sólo mediante proyecto separado.

Respuesta no es resolución

Un objetivo de respuesta puede servir: el MSP reconoce el ticket, evalúa impacto, asigna dueño e inicia la siguiente acción. Resolución es otra cosa. La resolución puede depender de aprobación del cliente, soporte del vendor, hardware, licenciamiento, backups, accesos, riesgo de seguridad o una decisión de proyecto.

La visión de ITIL sobre IT service management sirve como vocabulario porque la gestión de servicio trata de cómo se controla el trabajo, no sólo de si un técnico se esforzó. Para un MSP pequeño, respuesta, prioridad, dueño, comunicación y evidencia de cierre deben escribirse por separado de una resolución garantizada.

No vendas lenguaje de resolución si el equipo no controla las variables.

Define qué está incluido

El servicio recurrente incluido debe estar escrito en términos operativos:

• usuarios, sedes, equipos y servicios cloud soportados;
• canales y horarios normales de soporte;
• revisión de parches, monitoreo de backups, revisión de accesos y evidencia mensual;
• manejo de cola con el modelo de mesa de servicio para MSP pequeños;
• coordinación básica con vendors cuando el camino del vendor es claro y acotado.

El cliente debe poder leer el alcance y entender cómo entra el trabajo a la cola.

Define qué necesita aprobación

Algunos trabajos pueden estar relacionados con el servicio administrado y aun así quedar fuera de la mensualidad:

• migraciones y cambios mayores de configuración;
• limpieza de problemas heredados detectados durante onboarding;
• visitas en sitio fuera del plan;
• soporte fuera de horario;
• respuesta a incidentes;
• remediación después de un evento de seguridad;
• escalaciones largas con vendors donde el MSP termina como project manager.

Los básicos de plan de respuesta a incidentes de CISA sirven como referencia para este límite. La respuesta a incidentes incluye preparación, roles, comunicación, contención, recuperación y mejora. Si eso no se vendió explícitamente, no debe quedar escondido dentro del soporte normal.

Usa el checklist de onboarding para detectar estos puntos temprano. El trabajo desconocido se cotiza mejor cuando queda escrito como excepción.

Mantén el SLA al tamaño que puedes operar

Para un MSP pequeño, un SLA debe ser primero una promesa de cola y comunicación antes que una promesa heroica de resolución. Define:

1. dónde se aceptan solicitudes;
2. cuándo está disponible el soporte;
3. cómo el impacto de negocio cambia prioridad;
4. qué califica como emergencia;
5. cuándo el tiempo de espera por cliente o vendor pausa la acción del MSP;
6. qué evidencia cierra el ticket.

Si el equipo no puede medirlo cada semana, no lo pongas como promesa principal.

La guía de ciberseguridad para pequeños negocios de la FTC mantiene las promesas de seguridad en básicos prácticos como accesos, protección de datos, backups y preparación de respuesta. Esos básicos todavía requieren trabajo y evidencia, así que sólo pertenecen al alcance cuando el MSP puede operarlos de verdad.

Evidencia de que el límite funcionó

Los buenos límites dejan evidencia:

• los tickets muestran dueño, prioridad, siguiente acción y estado de espera;
• los proyectos aprobados están separados del soporte recurrente;
• las demoras de vendors quedan documentadas;
• los riesgos aceptados son visibles en la revisión mensual;
• las excepciones de factura coinciden con aprobaciones escritas.

Usa el checklist de revisión mensual para detectar drift de alcance antes de la renovación.

Error común

El error común es usar lenguaje amplio porque parece más fácil de vender. Palabras como ilimitado, completo, garantizado y todo incluido crean una promesa que el equipo quizá no puede operar.

Los límites claros no son anti-cliente. Mantienen el soporte honesto.

Cuándo subir el nivel

Cambia el alcance cuando las excepciones se repiten, los horarios de soporte crecen informalmente, la coordinación con vendors consume tiempo senior o el trabajo de seguridad se vuelve parte de la promesa recurrente. En ese punto, contrato, precio y mesa de servicio deben moverse juntos.