Precios de servicios administrados sin cobrar de menos

Respuesta corta: Cobra los servicios administrados alrededor de la promesa operativa, no sólo de la factura de herramientas. Un precio sostenible debe cubrir soporte recurrente, revisión, documentación, decisiones de riesgo, coordinación con vendors y el tiempo técnico necesario para sostener la promesa.

Cobra la responsabilidad, no la factura de herramientas

El precio de servicios administrados no es costo de herramientas más un poco de margen. Es el precio de una promesa operativa.

Esa promesa incluye respuesta, criterio, revisión de riesgo, documentación, control de accesos, monitoreo de backups, parches, coordinación con vendors, comunicación con cliente y tiempo técnico cuando algo no se comporta limpio.

Si la promesa no está clara, el cliente la va a definir después. Normalmente durante un problema urgente, una renovación o una queja de factura.

Define el servicio antes del precio

Antes de cotizar, escribe el límite del servicio en lenguaje claro. La guía de market research y análisis competitivo de la U.S. Small Business Administration recuerda que el precio se forma con contexto del comprador, alternativas, demanda y presión competitiva. Para un MSP, ese análisis de mercado importa, pero no reemplaza la disciplina de alcance.

Define:

• Usuarios, equipos, servidores, sedes, tenants cloud y aplicaciones soportadas.
• Canales de soporte incluidos.
• Horarios y reglas de emergencia.
• Ventanas de parches y mantenimiento.
• Monitoreo de backup y expectativas de restore.
• Base de seguridad y trabajo de seguridad excluido.
• Cadencia de reportes y revisión.
• Límites de coordinación con vendors.
• Reglas para proyectos, fuera de horario, trabajo en sitio e incidentes.
• Aprobaciones del cliente, riesgos aceptados y sistemas excluidos.

El precio solo tiene sentido cuando el límite ya existe. Usa la checklist de onboarding de clientes para descubrir el entorno real antes de tratar una cotización como final.

Empieza por la realidad de mano de obra

Los dueños de MSP pequeños suelen calcular con cuidado el costo de software y luego subestimar la mano de obra. Es al revés. Las herramientas importan, pero el tiempo técnico suele ser la restricción cara.

Haz matemática de mano de obra antes de matemática de paquetes:

• Tickets mensuales esperados por cliente.
• Minutos técnicos promedio por ticket.
• Tiempo recurrente de mantenimiento.
• Tiempo de revisión de parches.
• Tiempo de revisión de backups y pruebas de restore.
• Tiempo de triage de alertas de seguridad y revisión de identidad.
• Tiempo de coordinación con vendors.
• Tiempo de comunicación y revisión mensual con cliente.
• Tiempo de documentación.
• Tiempo de escalación y del dueño del MSP.
• Tiempo administrativo de facturación, renovación y cuenta.

El Occupational Outlook Handbook del U.S. Bureau of Labor Statistics para computer support specialists sirve como referencia de realidad al estimar costo laboral. El salario no es tu costo cargado completo, pero ayuda a evitar la fantasía de que el tiempo de soporte calificado es barato. Agrega impuestos de nómina, beneficios, tiempo del dueño, administración, capacitación, herramientas, tiempo no facturable y utilidad requerida antes de decidir si un precio mensual funciona.

Si la mensualidad no puede financiar el patrón de labor, el contrato normalmente ya nació presionado.

Construye un precio mínimo viable

Antes de presentar un paquete, calcula un precio mínimo viable. Debe ser suficientemente simple para explicarlo y repetirlo.

Usa este modelo:

1. Costo directo de herramientas: RMM, PSA, documentación, backup, seguridad, acceso remoto, seguridad de correo, reportes y cualquier costo de plataforma por cliente.
2. Labor esperada de servicio: tickets, mantenimiento, revisión de parches, revisión de backups, documentación, seguimiento con vendors y comunicación con cliente.
3. Labor de revisión: evidencia mensual, excepciones de seguridad, prueba de backup, patrones de cola y decisiones del cliente.
4. Carga administrativa y no facturable: facturación, cambios de acuerdo, renovaciones, limpieza interna, agenda y supervisión del dueño.
5. Buffer de riesgo: entornos ruidosos, sistemas legacy, vendors difíciles, documentación débil, usuarios de alto contacto y presión fuera de horario.
6. Margen requerido: el margen bruto que la cuenta debe proteger después de labor, herramientas y fricción normal.

Una fórmula práctica:

```text

Precio mensual mínimo =

costo de herramientas

+ costo de labor esperada

+ costo de revisión/admin

+ buffer de riesgo

+ margen requerido

```

No lo trates como lista pública de precios. Trátalo como el piso por debajo del cual la cuenta empieza a consumir el negocio.

Los recursos de SCORE sobre pricing y modelo de negocio son útiles porque el precio no es solo aritmética. El modelo debe coincidir con el valor entregado, el segmento de cliente y la forma en que el negocio gana margen. Para un MSP pequeño, eso significa que el precio debe financiar la promesa operativa, no solo sonar aceptable junto al nombre del paquete de un competidor.

Cotiza el mal mes ordinario

Un buen precio debe sobrevivir fricción normal. Prueba el paquete contra escenarios comunes:

• Una falla de backup cada semana.
• Un caso con vendor cada mes.
• Un hueco de onboarding descubierto después del arranque.
• Una solicitud fuera de horario.
• Una alerta de seguridad que necesita investigación.
• Una workstation envejecida o aplicación no soportada.
• Un contacto del cliente que brinca la cola.
• Una revisión mensual que expone una decisión o excepción.

Si el paquete falla esos escenarios ordinarios, el precio está demasiado bajo o el alcance demasiado amplio.

Separa recurrente, proyecto, incidente y excepción

Cobrar de menos suele empezar cuando todo tipo de trabajo cae dentro del plan mensual.

Crea cuatro cubetas:

• Servicio recurrente: soporte predecible, monitoreo, mantenimiento, revisión de parches, revisión de backups, revisión de accesos, mantenimiento de documentación, manejo de tickets y evidencia mensual.
• Proyecto: migraciones, despliegues nuevos, limpieza de problemas heredados, cambios mayores de aplicaciones, rediseño de red, remediación de onboarding y upgrades planeados.
• Incidente: ransomware, account takeover, malware activo, exposición de datos, interrupción fuerte del negocio y respuesta que interrumpe el servicio normal.
• Excepción aceptada: riesgos que el cliente decide no corregir todavía, con dueño, fecha, próxima revisión e impacto.

La checklist de revisión mensual debe exponer a qué cubeta pertenece el trabajo. Si la misma excepción aparece cada mes, ya no es ruido de fondo. Es una decisión de alcance, riesgo o precio.

Dónde cobran de menos los MSP pequeños

Cobrar de menos rara vez viene de una sola línea olvidada. Normalmente viene de responsabilidad que se filtra por alcance poco claro.

• Trabajo de "pregunta rápida" que se vuelve consultoría diaria.
• Equipos que no se cuentan pero igual se soportan.
• Soporte fuera de horario tratado como servicio normal.
• Tickets con vendors que consumen tiempo del MSP pero no están valuados.
• Expectativas de backup que incluyen responsabilidad de restore sin pruebas de restore.
• Lenguaje de seguridad que suena más amplio que lo que el equipo realmente verifica.
• Trabajo en sitio asumido como incluido porque el cliente está cerca.
• Servidores viejos y aplicaciones no soportadas cotizadas como entornos modernos limpios.
• Retrasos causados por el cliente que parecen incumplimiento de SLA del MSP.
• Planeación tipo vCIO incluida accidentalmente por llamadas ilimitadas de asesoría.

Cada fuga puede parecer pequeña. Juntas borran margen.

Modelos de precio y tradeoffs

Ningún modelo salva un alcance débil. Elige el modelo que tu equipo pueda explicar, operar y auditar cada mes.

• Por usuario: fácil para presupuesto del cliente, pero riesgoso cuando varía mucho la cantidad de equipos, workstations compartidas o comportamiento de soporte.
• Por equipo: más cercano a la carga de endpoints, pero puede ignorar soporte pesado de usuarios y administración SaaS.
• Por sede: útil cuando red, internet y expectativas en sitio varían por ubicación.
• Mensual fijo: simple de vender, pero peligroso sin exclusiones estrictas y una base clara de activos.
• Híbrido: útil cuando necesitas una base más variables por usuarios, equipos, sedes, controles de seguridad, backups o cobertura fuera de horario.

Si tu framework de selección de stack agrega costo por endpoint, tiempo de revisión de alertas, obligaciones de reporte o mínimos de contrato, el modelo de precio debe reflejarlo. Un stack barato que crea tickets ruidosos no es barato.

La seguridad no es lenguaje gratis

Las palabras de seguridad crean responsabilidad. El NIST Cybersecurity Framework 2.0 separa gobierno, identificación, protección, detección, respuesta y recuperación. Si tu plan mensual usa lenguaje de seguridad, decide cuáles de esas funciones están realmente incluidas y cuáles requieren proyecto, alcance de incidente o aprobación del cliente.

La guía de ciberseguridad para pequeños negocios de la FTC refuerza básicos prácticos como acceso, protección de datos, backups y preparación de respuesta. Esos básicos todavía requieren labor del MSP: configuración, revisión, manejo de alertas, documentación, explicación al cliente y seguimiento.

Conecta cada promesa de seguridad con la base de seguridad para MSP pequeños:

• Revisión de MFA.
• Revisión de cuentas administrativas.
• Dueño de alertas de endpoint.
• Excepciones de parches.
• Revisión de fallas de backup.
• Pruebas de ruta de restore.
• Excepciones de offboarding.
• Decisiones abiertas del cliente.

Si esos puntos están incluidos, cóbralos. Si no están incluidos, no dejes que la propuesta suene como si lo estuvieran.

La carga de mesa de servicio va en el precio

Pricing y diseño de mesa de servicio son la misma conversación desde dos ángulos. El modelo de mesa de servicio para MSP pequeño debe decirte qué tiene que financiar el plan mensual:

• Entrada de tickets.
• Triage.
• Manejo de prioridad.
• Asignación de dueño.
• Seguimiento de esperando cliente y esperando vendor.
• Escalación.
• Evidencia de cierre.
• Revisión de cola.

Si cada solicitud de soporte se trata como urgente e incluida, el precio no es de servicios administrados. Es una promesa de labor ilimitada con factura mensual.

Límites que deben quedar explícitos

Escribe estos límites en la oferta antes de que el cliente los necesite:

• Trabajo en sitio: visitas incluidas, límites de traslado, visitas de emergencia y cargos mínimos.
• Fuera de horario: qué califica, quién lo aprueba y cómo se cobra.
• Coordinación con vendors: qué está incluido, qué se vuelve proyecto y qué depende del vendor.
• vCIO o estrategia: cadencia de revisión, sesiones de planeación, apoyo de presupuesto y qué queda fuera de soporte normal.
• Respuesta a incidentes: cuándo termina el lenguaje normal de SLA y empieza el manejo de incidente.
• Remediación: riesgo heredado, sistemas no soportados, backups faltantes, controles débiles de identidad y limpieza descubierta durante onboarding.

Aquí es donde pricing conecta con qué es un MSP pequeño. El negocio es pequeño porque la capacidad es visible. Un límite no es falta de servicio. Es la forma de mantener real el servicio.

Regla de descuento

Antes de descontar, quita responsabilidad.

Un plan más barato debe incluir menos alcance, respuesta más lenta, menos canales incluidos, menos sistemas administrados, reportes más ligeros, menos controles de seguridad o menos acceso consultivo. No debe ser la misma promesa con peor margen.

Ejemplos:

• Quita soporte fuera de horario en vez de descontar la misma promesa de respuesta.
• Excluye trabajo en sitio en vez de absorber traslado e interrupción.
• Mueve pruebas de restore a un add-on pagado si el monitoreo de backup es la única tarea recurrente incluida.
• Reduce la profundidad de revisión mensual si el cliente elige un plan más ligero.
• Exige remediación pagada antes de incluir sistemas no soportados en el alcance administrado.

Los descuentos también necesitan regla de expiración. Un ramp temporal, periodo de migración o apoyo a nonprofit debe tener fecha, alcance y razón. Si no, el descuento se vuelve el precio real.

Explicación al cliente

Usa lenguaje claro:

Este servicio mensual está cotizado alrededor de los sistemas que administramos, el nivel de respuesta que esperas, los controles de seguridad que verificamos y el tiempo necesario para mantener el entorno soportable. Lo que queda fuera de ese límite se maneja como proyecto, incidente o aprobación separada.

Eso es mejor que esconderse detrás de nombres de paquetes. Puede que al cliente no le encante cada límite, pero los límites poco claros crean conversaciones peores después.

Error común

El error común es cotizar desde el miedo: miedo a perder el trato, miedo a verse caro o miedo a que un cliente pequeño no pueda pagar el costo real.

Si el precio no puede financiar la promesa, normalmente el contrato tampoco es accesible para el MSP.

Cuándo subir el nivel

Sube precios cuando el volumen de tickets crece sin cambio de alcance, aumenta la coordinación con vendors, se mueve el conteo de endpoints, la revisión de seguridad se vuelve más pesada, los clientes brincan la cola, el trabajo fuera de horario se vuelve normal o la revisión mensual expone riesgo no cotizado.

También sube precios cuando tu propia entrega mejora. Mejor documentación, revisión de seguridad más fuerte, evidencia de backup más limpia y mesa de servicio disciplinada no son solo mejoras operativas. Son parte de la promesa que el cliente está comprando.