Checklist de revisión mensual para MSP pequeños

Respuesta corta: Una revisión mensual útil convierte el servicio recurrente en evidencia y decisiones. Revisa salud del cliente, excepciones de seguridad, pruebas de backup, patrones de tickets, trabajo envejecido, alcance, señales de precio y quién tiene cada siguiente acción; evita dashboards que no cambian nada.

La revisión mensual es evidencia, no una junta

Una revisión mensual no vale por tener una presentación, una captura de dashboard o una invitación de calendario. Vale cuando convierte el servicio recurrente en evidencia visible, decisiones abiertas y siguientes acciones.

Para un MSP pequeño, la revisión mensual es donde el trabajo oculto se vuelve administrable. Muestra qué clientes se están desviando, qué tickets se repiten, qué backups solo se asumen, qué controles necesitan atención y qué promesas están empezando a exceder el precio mensual.

No construyas esto como un proceso pesado de QBR si eres operador independiente o un equipo de dos a cinco personas. Constrúyelo como un ritmo operativo corto que sí puedas repetir.

Define el límite de la revisión mensual

Antes de la checklist, define qué debe contestar la revisión:

• ¿El cliente sigue dentro de la promesa de servicio?
• ¿El MSP hizo el trabajo recurrente que vende?
• ¿Qué riesgos están abiertos y esperando al cliente?
• ¿Qué puntos deben convertirse en proyecto?
• ¿Qué tickets, alertas o eventos de backup requieren cambios de proceso?
• ¿Qué supuestos de precio o alcance ya no son ciertos?

Esto se conecta con la checklist de onboarding de clientes. Si onboarding no capturó sistemas, contactos, backups, vendors, excepciones y alcance soportado, la revisión mensual tendrá que reconstruir al cliente desde memoria.

Snapshot de salud del cliente

Empieza con un snapshot simple de salud del cliente. No es una calificación de satisfacción. Es la vista operativa de si la cuenta todavía se puede soportar bien.

Revisa:

• Contacto principal de negocio y contacto técnico todavía válidos.
• Contacto de emergencia y expectativas fuera de horario todavía válidas.
• Sedes, usuarios, endpoints, servidores y aplicaciones centrales soportadas.
• Sistemas no soportados conocidos.
• Dependencias abiertas con vendors.
• Candidatos a proyecto abiertos.
• Decisiones abiertas del cliente.
• Cambios recientes del negocio que afecten soporte.

Si el snapshot expone datos faltantes, no lo entierres. Regresa ese punto a limpieza tipo onboarding. El cliente ya puede estar en vivo, pero el trabajo sigue siendo el mismo: identificar dueño, sistema, riesgo y siguiente acción.

Evidencia de seguridad e identidad

La CPG Checklist de CISA sirve porque convierte metas de seguridad en puntos revisables. Un MSP pequeño no debe copiar cada control en un reporte para cliente. Úsala para mantener la revisión práctica: identidad, acceso, backups, logs, parches y ruta de respuesta.

Revisa:

• Cuentas administrativas agregadas, removidas o cambiadas.
• Excepciones de MFA.
• Excepciones de acceso remoto.
• Cuentas de vendors con acceso privilegiado.
• Exempleados, contratistas o vendors que sigan presentes.
• Estado de cuenta de emergencia.
• Alertas de seguridad que generaron tickets.
• Decisiones abiertas de riesgo del cliente.

Si Microsoft 365 está dentro del alcance, Microsoft Secure Score puede ayudar a identificar cambios de postura y acciones recomendadas. Trátalo como señal, no como toda la historia. Un score no reemplaza el conocimiento de alcance, excepciones aceptadas o qué está pagado para administrar el MSP.

Para clientes con Google Workspace, los reportes de Workspace y la herramienta de auditoría e investigación pueden apoyar la revisión de uso, eventos de seguridad, actividad administrativa y patrones de compartición cuando esas áreas estén dentro del alcance.

Conecta esta sección con la base de seguridad para MSP pequeños. Si un control se vende como servicio recurrente, la revisión mensual debe mostrar si se revisó.

Prueba de backup y restore

Backups es una de las áreas más fáciles de malinterpretar. Un dashboard puede estar verde mientras el cliente todavía tiene datos sin cobertura, credenciales obsoletas, supuestos de restore rotos o expectativas de retención poco claras.

La guía StopRansomware de CISA refuerza un punto práctico: la preparación de recuperación importa antes del incidente, no después. Para un MSP, eso significa que la revisión mensual debe mostrar estado de backup y confianza de restore, no solo presencia de producto.

Usa la checklist de pruebas de restauración para definir profundidad, cadencia, evidencia, manejo de fallas y el límite comercial detrás de esa confianza.

Revisa:

• Qué jobs de backup tuvieron éxito, fallaron o fueron deshabilitados.
• Qué sistemas o ubicaciones de datos no están cubiertos.
• Qué datos de Microsoft 365 o Google Workspace están cubiertos.
• Qué revisiones de ruta de restore se hicieron.
• Qué prueba de restore falló o se pospuso.
• Qué alertas de backup generaron tickets.
• Qué expectativas de retención o recuperación cambiaron.
• Qué decisiones del cliente siguen abiertas.

No digas "backup está sano" si nadie sabe qué se restauraría primero durante una caída. Di qué se revisó, qué sigue desconocido y qué acción se necesita.

Patrones de cola de tickets

La cola de tickets te dice si el modelo de servicio está funcionando. Un ticket puede ser ruido. Un patrón repetido es una señal operativa.

Revisa:

• Tipos de ticket más repetidos.
• Tickets reabiertos después del cierre.
• Tickets esperando al cliente.
• Tickets esperando al vendor.
• Tickets bloqueados por alcance.
• Tickets que debieron ser proyectos.
• Tickets que saltaron los canales aprobados.
• Eventos de seguridad tratados como soporte normal.

Usa el modelo de mesa de servicio para MSP pequeño para decidir qué significa el patrón. Si el trabajo entra por chat, llamadas, mensajes directos al técnico y memoria, la revisión mensual no debe fingir que la cola está sana.

Una pregunta útil: ¿qué trabajo desaparecería si el cliente aprobara un proyecto, cambiara un proceso, reemplazara una herramienta o aceptara un límite de soporte más claro?

Drift de herramientas y vendors

Las herramientas se desvían. Los vendors cambian contratos. Las alertas se vuelven ruidosas. Las integraciones se rompen en silencio. Una revisión mensual debe detectar ese drift operativo antes de que se vuelva problema de margen.

Revisa:

• Huecos de cobertura de RMM.
• Fricción en cola o flujo de PSA.
• Áreas de documentación obsoletas.
• Alertas o cambios de facturación en plataforma de backup.
• Alertas de seguridad ignoradas porque generan demasiado ruido.
• Renovaciones o cambios de precio de vendors.
• Herramientas con mala exportación o ruta de salida.
• Integraciones que ya no cargan el trabajo que debían cargar.

Aquí el framework de selección de stack sigue siendo útil después de la venta. Un stack no es bueno porque se veía completo en el demo. Es bueno cuando todavía sostiene el trabajo cada mes.

Excepciones y riesgo aceptado

La revisión mensual debe mantener visibles las excepciones. Si una excepción desaparece de la revisión, no se resolvió. Solo se movió a memoria.

Revisa cada excepción:

• ¿El riesgo sigue presente?
• ¿Quién es dueño de la decisión?
• ¿La siguiente acción está clara?
• ¿El punto sigue incluido, fuera de alcance o como proyecto?
• ¿Cambió el impacto de negocio?
• ¿El cliente debe aceptar, rechazar o aprobar trabajo otra vez?

Riesgo aceptado no significa que el MSP considere el riesgo inofensivo. Significa que el cliente tomó una decisión visible. Esa decisión necesita fecha, dueño y ritmo de revisión.

Señales de alcance y precio

La revisión mensual también protege margen. Si el servicio recurrente sigue absorbiendo proyectos, coordinación con vendors, respuesta a incidentes o aplicaciones no soportadas, el acuerdo se está desviando.

Busca estas señales de precio:

• El volumen de tickets es mayor de lo que la cuenta puede financiar.
• El cliente agregó usuarios, equipos, sedes o aplicaciones.
• El trabajo de revisión de seguridad creció.
• La cobertura de backup creció.
• La coordinación con vendors se volvió labor recurrente.
• El trabajo onsite se está tratando como incluido.
• El trabajo de incidente se está atendiendo como soporte normal.
• El cliente espera reportes que nunca se cotizaron.

Usa la guía de precios de servicios administrados cuando la revisión muestre que el plan mensual ya no financia la promesa.

Salud del negocio del MSP

La revisión del cliente no debe ignorar tu propio negocio. La guía de la SBA para administrar finanzas del negocio recuerda que flujo de efectivo, cuentas por cobrar y registros financieros necesitan un ritmo regular. Para un MSP pequeño, ese ritmo pertenece cerca de la salud del cliente porque el drift operativo se convierte en drift de margen.

Revisa:

• Facturas vencidas de clientes administrados.
• Cuentas por debajo del margen esperado.
• Costos de herramientas que aumentaron.
• Horas no facturables por cuenta.
• Trabajo de proyecto que no se ha cotizado.
• Acuerdos que necesitan actualización de alcance.
• Clientes que necesitan conversación de precio.

Esto no debe convertirse en teatro contable. Solo debe evitar que el MSP descubra problemas de margen meses tarde.

Qué enviar al cliente

No envíes cada detalle interno. Envía lo que ayuda al cliente a decidir.

Una nota mensual útil puede incluir:

1. Qué se revisó.
2. Qué cambió.
3. Qué está sano.
4. Qué necesita aprobación del cliente.
5. Qué sigue como riesgo aceptado.
6. Qué debe convertirse en proyecto.
7. Qué hará el MSP antes de la siguiente revisión.

Mantén el lenguaje claro. Un cliente no necesita cada ID de alerta. Necesita entender qué importa, quién lo posee y qué sigue.

Error común

El error común es convertir la revisión mensual en un QBR estilo vendor lleno de gráficas que no cambian decisiones.

Si la revisión no produce una siguiente acción, un riesgo aceptado, un candidato a proyecto, una corrección de alcance o evidencia de que el trabajo recurrente ocurrió, probablemente está demasiado decorada.

Cuándo subir el nivel

Sube el proceso de revisión mensual cuando un cliente tenga datos regulados, cambios frecuentes de usuarios, varias ubicaciones, excepciones recurrentes de seguridad, requisitos de cyber insurance o liderazgo pidiendo reportes más fuertes.

Sube tu propio proceso como MSP cuando preparar revisiones tome demasiado tiempo, los técnicos recolecten evidencia de formas distintas, los clientes malentiendan el alcance repetidamente o las conversaciones de precio ocurran solo después de que la cuenta ya perdió rentabilidad.