Precio fijo para proyectos de MSP pequeños

Respuesta corta: Para proyectos SMB, el precio fijo funciona cuando el resultado tiene límites claros. Cotiza la labor estimada con una tarifa interna de venta, agrega costos directos y una contingencia de riesgo, cobra en hitos que protejan tu flujo y define los cambios antes de empezar. Usa el proyecto para ganar confianza y conocer el entorno, pero deja el soporte y la responsabilidad recurrente en un contrato mensual separado.

Los proyectos pueden abrir la puerta sin convertirse en todo el negocio

Para un MSP nuevo de una sola persona puede ser más fácil vender una migración a Microsoft 365, un reemplazo de firewall o un rollout de Intune que un contrato administrado completo. El cliente ve un problema finito y un resultado identificable. El MSP recibe pago por conocer el entorno y demostrar cómo trabaja.

Es una entrada útil, pero los ingresos por proyecto son irregulares. Un MSP sano todavía necesita ingresos predecibles para financiar disponibilidad, herramientas, documentación, revisión de seguridad y seguimiento entre emergencias. Trata los proyectos como un canal de adquisición y entrega, no como prueba de que el servicio recurrente puede esperar para siempre.

El proyecto debe terminar con uno de tres resultados claros:

• El cliente acepta el resultado y asume la operación.
• El cliente compra un add-on definido de soporte o mantenimiento.
• El cliente firma un acuerdo de servicios administrados para la responsabilidad recurrente que reveló el proyecto.

No presentes el contrato recurrente como condición sorpresa al final. Inclúyelo como opción desde la propuesta para que el cliente entienda quién operará el entorno después de la aceptación.

El precio fijo empieza con un resultado acotado

Los negocios pequeños suelen preferir una cantidad que puedan aprobar y presupuestar. El precio fijo puede dar esa claridad, pero solo cuando la propuesta define qué significa terminar.

Escribe:

• Los entregables que recibirá el cliente.
• Los sistemas, usuarios, sedes, tenants o endpoints incluidos.
• Los supuestos sobre licencias, accesos, datos de origen, hardware y cooperación de vendors.
• Las responsabilidades del cliente y fechas límite para decisiones.
• La ventana de trabajo y las restricciones de cutover.
• Las pruebas y el periodo de aceptación.
• Las exclusiones, especialmente desarrollo personalizado, remediación, capacitación, limpieza de datos y trabajo fuera de horario.
• Lo que activa una orden de cambio, una pausa o una nueva estimación.

La guía de Microsoft para planeación de proyectos organiza el plan alrededor de alcance, calendario, recursos, entregables, dependencias, responsables y feedback. Una propuesta SMB puede ser mucho más corta, pero todavía necesita esos límites de decisión.

Si no puedes describir el resultado y el límite, todavía no tienes un proyecto de precio fijo. Tienes un entorno desconocido con una cifra optimista pegada.

Construye el precio desde tu propia economía

Usa un modelo interno sencillo:

```text

Precio fijo del proyecto =

(horas estimadas × tarifa interna de venta)

+ costos directos del proyecto

+ contingencia de riesgo

```

La tarifa interna de venta no es solo el sueldo del técnico. Debe ayudar a financiar carga laboral, tiempo del dueño, administración, herramientas, capacitación, trabajo no facturable y la contribución de utilidad que necesita el negocio. Si tu tarifa representa únicamente costo laboral cargado, agrega por separado la contribución de utilidad requerida.

Los costos directos pueden incluir licencias temporales, herramientas de migración, subcontratistas, traslado, envío, disposición o manejo de hardware. No escondas un costo de vendor dentro de la labor esperando que sobreviva.

La contingencia no es un porcentaje arbitrario. Conéctala con incertidumbre identificable:

• Documentación débil o inexistente.
• Volumen o calidad de datos desconocidos.
• Autenticación legacy y sistemas sin soporte.
• Un vendor externo que controla una dependencia.
• Ventanas de cutover muy estrechas.
• Trabajo nuevo que tu equipo todavía no entrega de forma repetible.
• Retrasos del cliente que pueden forzar reprogramación.

La guía de punto de equilibrio de la U.S. Small Business Administration conecta precio con costos fijos, costos variables y margen de contribución. Esa es la disciplina correcta: el proyecto debe cubrir el trabajo y contribuir al negocio, no solo verse aceptable junto al número de un competidor.

No copies el número de proyecto de otra empresa

Un ejemplo de comunidad como 2,500 dólares por proyecto no es una lista de precios. La misma etiqueta puede esconder trabajos completamente distintos.

Una evaluación de seguridad de M365 para 12 usuarios y un tenant no es igual que una para 80 usuarios, cuentas administrativas sin control, varios dominios, aplicaciones legacy y cero documentación. Instalar un firewall puede ser un reemplazo limpio con reglas conocidas o descubrir la red del cliente mientras el negocio ya está detenido.

Usa cifras externas como comprobación de razonabilidad después de estimar, nunca como la estimación. Si tu precio queda mucho más alto o bajo, identifica la causa: alcance, geografía, riesgo, experiencia, herramientas, traslado, calendario o nivel de evidencia entregado.

Usa discovery pagado cuando la incertidumbre sea demasiado alta

No obligues cada oportunidad a caber en un solo precio fijo. Vende una fase pequeña de discovery cuando todavía no puedes verificar los datos de entrada.

El discovery puede entregar:

• Conteos de activos y usuarios.
• Diagramas del estado actual.
• Hallazgos de volumen de datos y origen de migración.
• Brechas de licenciamiento y prerrequisitos.
• Dependencias conocidas de vendors.
• Lista de riesgos y remediación.
• Plan recomendado y cotización final.

El cliente recibe un entregable útil aunque la implementación no continúe. El MSP evita regalar la parte más difícil del análisis y absorber incógnitas dentro de un precio prematuro.

En migraciones, el resumen de migración de Microsoft 365 separa escenarios y workloads, mientras la guía de migración de SharePoint subraya evaluación, remediación, preparación del destino, migración y onboarding de usuarios. Esa secuencia recuerda que “muévenos a M365” no es una sola tarea.

AYCE aplica al soporte definido, no a cambios ilimitados

El soporte all-you-can-eat no es un acuerdo para construir cualquier cosa que imagine el cliente. Es un enfoque de precio para actividad de soporte definida y dentro de alcance.

El contrato puede incluir restablecimiento de contraseñas, soporte a usuarios, monitoreo, mantenimiento rutinario, revisión de parches, administración de licencias y otro trabajo predecible. Puede excluir aplicaciones personalizadas, Power Apps, integraciones web, migraciones mayores, nuevas sedes, remediación heredada y cambios grandes.

Usa la guía de límites de alcance y SLA para separar:

• Soporte recurrente.
• Trabajo planeado como proyecto.
• Respuesta a incidentes.
• Trabajo fuera de horario.
• Excepciones aceptadas por el cliente.

El plan mensual debe financiar una promesa estable. El precio de proyecto debe financiar un cambio finito. Mezclarlos sin un límite escrito hace más difícil entregar ambos.

Decide dónde pertenecen los proyectos SMB comunes

Algunos servicios tienen una fase de implementación y otra de operación recurrente. Sepáralas deliberadamente.

• Evaluación de seguridad de M365: assessment pagado independiente cuando el cliente quiere hallazgos, o parte del onboarding pagado cuando alimenta un plan administrado.
• Migración de Google Workspace a M365: proyecto con discovery, prerrequisitos, alcance de datos, cutover, validación, comunicación a usuarios y datos fuera de alcance explícitos.
• Tenant nuevo de M365: proyecto o entregable de onboarding; identidad, licencias, soporte y revisión recurrente de seguridad pertenecen al servicio mensual si están incluidos.
• Rollout de Intune: proyecto de implementación para enrollment, políticas, pruebas, excepciones y despliegue; el mantenimiento de políticas y manejo de alertas son trabajo recurrente.
• Instalación de firewall: proyecto de diseño, instalación, reglas, pruebas, documentación y entrega; monitoreo, revisión de firmware, backup de configuración y coordinación con vendor pueden ser recurrentes.
• Rollout de Defender, EDR o hardening: proyecto o remediación de onboarding para despliegue y configuración base; triage de alertas, exclusiones, revisión de políticas y evidencia necesitan un responsable recurrente.

Esta separación evita que el cliente pague tarifa de proyecto para siempre y que el MSP asuma responsabilidad operativa gratis.

Protege el flujo con un calendario de pagos

Un MSP nuevo no debe financiar el proyecto del cliente con su propio efectivo. Haz que el pago corresponda con la exposición.

Estructuras razonables:

• Pago completo por adelantado para trabajo pequeño, corto y bien acotado.
• Discovery no reembolsable seguido por una cotización de implementación.
• Anticipo antes de agendar, pago antes del cutover y pago final de aceptación.
• Prepago de hardware, licencias, subcontratistas y otros costos comprometidos con terceros.

Define qué ocurre si el cliente retrasa accesos, incumple una fecha de decisión, cancela después de comprar licencias o deja el proyecto detenido. Define también si el pago final depende de criterios objetivos de aceptación y no de una sensación abierta de que “todo está perfecto”.

Compara cada estimación contra el trabajo real

Las primeras estimaciones serán imperfectas. La solución no es una contingencia gigante permanente. Es costeo disciplinado por proyecto.

Después de cada trabajo registra:

• Horas estimadas contra reales por fase.
• Coordinación no planeada con cliente y vendors.
• Retrabajo y su causa.
• Impacto de traslados y fuera de horario.
• Herramientas o licencias omitidas en la estimación.
• Supuestos que fallaron.
• Cambios aprobados contra trabajo absorbido.
• Contribución bruta después de labor y costos directos.

Actualiza la plantilla antes de cotizar el siguiente proyecto similar. Después de varios trabajos comparables, el MSP debe saber qué preguntas de discovery predicen esfuerzo y qué trabajo nunca debe venderse sin una evaluación pagada.

Checklist de propuesta

Antes de enviar una propuesta de precio fijo, confirma:

• El resultado y la evidencia de aceptación son explícitos.
• Las cantidades y sistemas incluidos están listados.
• Los supuestos y dependencias del cliente son visibles.
• Las exclusiones cubren trabajo personalizado y remediación desconocida.
• La tarifa interna refleja el costo real del negocio.
• Los costos directos están incluidos.
• La contingencia está ligada a riesgos nombrados.
• Las reglas de orden de cambio son utilizables.
• El momento de cobro limita riesgo de efectivo y cobranza.
• Está nombrado el responsable posterior al proyecto.
• La opción de servicios administrados tiene alcance y precio propios.

Error común

El error común es usar precio fijo para darle certeza al cliente y dejar toda la incertidumbre del lado del MSP. La propuesta promete un resultado, pero no limita cantidades, no nombra supuestos, no define obligaciones del cliente y no cotiza riesgo.

Eso no es simplicidad amigable para el cliente. Es una garantía sin precio.

Cuándo subir el nivel

Pasa de estimación informal a discovery pagado, plantillas estándar, costeo por proyecto y control de cambios más fuerte cuando los proyectos se repiten, más vendors externos controlan dependencias, los cutovers afectan continuidad o un error de estimación puede borrar la utilidad de un mes.

Mueve a los clientes adecuados hacia servicio recurrente cuando el proyecto terminado crea responsabilidad continua por monitoreo, mantenimiento, identidad, seguridad, backup, seguimiento con vendors o soporte a usuarios. La señal no es que el cliente haya comprado un proyecto. La señal es que alguien debe ser dueño de la siguiente acción operativa después del cierre.