Cómo iniciar un MSP pequeño: primeros 90 días

Respuesta corta: No uses los primeros 90 días para armar un stack perfecto. Demuestra que un cliente específico comprará un servicio acotado que tu negocio puede entregar con seguridad, de forma repetible y con margen. Para el día 90 debes tener una oferta clara, una base operativa, un ritmo comercial semanal, una ruta controlada de onboarding y un disparador escrito para sumar capacidad.

El primer problema no es la tecnología

La experiencia técnica ayuda, pero no crea por sí sola un servicio administrado. Un MSP nuevo debe hacer funcionar cinco sistemas en conjunto:

1. Un mercado suficientemente específico para alcanzarlo.
2. Una promesa suficientemente acotada para cotizarla y soportarla.
3. Una ruta de entrega que funcione cuando el dueño esté ocupado, enfermo o no disponible.
4. Un piso de seguridad y documentación que proteja al cliente y al MSP.
5. Un ritmo comercial que produzca conversaciones sin depender de la suerte.

Conversaciones públicas recientes en r/SmallMSP regresan a las mismas presiones: conseguir clientes durante los primeros meses, iniciar sin ser el técnico principal, comenzar mientras mantienes otro empleo y definir tarifas de contratistas. Esos threads son señales útiles, no una fórmula universal ni un consenso formal de la comunidad.

Esta guía convierte las preguntas repetidas en un plan operativo comprobable de 90 días.

Antes del día uno, define el límite para avanzar o detenerte

No firmes un cliente administrado hasta poder responder con claridad:

• ¿Quién puede interrumpirte durante el horario de soporte?
• ¿Qué ocurre si llega un incidente prioritario mientras estás en otro empleo o con otro cliente?
• ¿Quién puede entregar si no estás disponible?
• ¿Qué servicios, tamaños de cliente, ubicaciones y tecnologías rechazarás?
• ¿Cuál es el piso mínimo de seguridad que exigirás?
• ¿Cuánto efectivo y tiempo puedes invertir antes de que el negocio deba pagarte?
• ¿Qué obligaciones laborales, de no solicitación, confidencialidad, licencias, impuestos, seguros y conflicto de interés aplican localmente?

Si comienzas mientras conservas otro empleo, la separación debe ser absoluta. No uses tiempo, equipos, software, datos, cuentas, relaciones ni propiedad intelectual del empleador. Las expectativas escritas y una cobertura técnica calificada importan más que confiar en que las emergencias serán raras.

Comenzar a tiempo parcial puede funcionar para proyectos acotados o una ventana de servicio deliberadamente limitada. Es mala combinación con un contrato que implique respuesta inmediata durante el día cuando nadie está realmente disponible.

Días 1–30: construye un servicio que sobreviva el contacto con un cliente

Elige un perfil de cliente antes que las herramientas

Define el perfil inicial con hechos operativos, no solo con una industria:

• Cantidad típica de endpoints y usuarios.
• Mezcla cloud, on-premises, remota y multisucursal.
• Sistemas operativos y aplicaciones principales soportadas.
• Restricciones regulatorias, del seguro o contractuales.
• Contacto interno que pueda aprobar accesos, gasto, interrupciones y riesgo.
• Límites geográficos y de trabajo onsite.
• Problemas que el cliente ya reconoce y está dispuesto a financiar.

“Cualquier pequeña empresa” no es un perfil útil. Una oficina profesional de 15 usuarios con Microsoft 365, sin TI interno, soporte en horario hábil y una sola ubicación crea un límite inicial mucho más claro que “pymes que necesitan tecnología”.

El enfoque de mercado no es permanente. Da al primer mensaje comercial, checklist de onboarding, prueba del stack y precio un entorno real al cual ajustarse. La guía de planeación de la U.S. Small Business Administration también conecta investigación de mercado, análisis competitivo, costos iniciales y plan de negocio en lugar de tratarlos como ejercicios separados.

Escribe un plan operativo de una página

Tu primer plan debe responder:

• Cliente: ¿Cuál es el perfil inicial?
• Problema: ¿De qué riesgos operativos recurrentes asumirás ownership?
• Oferta: ¿Qué está incluido, excluido y se cotiza aparte?
• Cobertura: ¿Qué horarios, canales, objetivos de respuesta y escalaciones aplican?
• Entrega: ¿Quién ejecuta, revisa, aprueba y documenta el trabajo?
• Piso de seguridad: ¿Qué controles y prácticas de acceso son obligatorios?
• Economía: ¿Cuánto debe pagar el cliente para que la promesa siga siendo sostenible?
• Adquisición: ¿Qué dos o tres canales operarás cada semana?
• Disparador de capacidad: ¿Qué evidencia hará que sumes contratista o empleado?
• Salida: ¿Cómo recibirá el cliente datos, credenciales y documentación al terminar la relación?

Un plan lean es suficiente cuando cambia decisiones operativas. La guía de plan de negocio de la SBA incluye segmentos de clientes, canales, estructura de costos, fuentes de ingresos, recursos clave y socios estratégicos; todos ayudan cuando el dueño decide qué debe existir antes del primer contrato.

Define el servicio mínimo entregable

Escribe la primera oferta como un compromiso operativo:

• Usuarios, equipos, sedes, tenants cloud y aplicaciones soportadas.
• Entrada de tickets y horario de soporte.
• Definiciones de prioridad y objetivos de respuesta.
• Responsabilidades de parches, monitoreo, backup, restore, identidad y seguridad de endpoints.
• Coordinación con vendors y límites onsite.
• Límites de proyectos, fuera de horario, incidentes, cumplimiento y compras.
• Responsabilidades del cliente y contactos de aprobación.
• Reglas de onboarding, vigencia, renovación, revisión de precio y offboarding.

Usa la guía de límites de alcance y SLA para mantener finita la promesa. Si no puedes describir el servicio sin decir “lo que necesiten”, tampoco puedes cotizarlo ni delegarlo de forma confiable.

Construye funciones antes de comprar un stack grande

La operación necesita estas funciones desde el inicio:

• Identidad nominal y autenticación fuerte para administración.
• Registro controlado de activos, contactos, vendors, ownership de accesos y excepciones.
• Un solo lugar para solicitudes, acciones, aprobaciones, tiempo y evidencia de cierre.
• Evidencia de monitoreo y parches acorde con la promesa.
• Ownership de backup y ruta de restore probada cuando el backup esté incluido.
• Documentación segura con posibilidad de exportación.
• Facturación recurrente y conciliación.

Un RMM, PSA, plataforma documental y sistema de facturación pueden ofrecer esas funciones, pero comprarlos no demuestra el flujo. Usa el framework de selección de stack para probar herramientas con criterios reales de aceptación y contrato.

Ensaya el servicio antes de venderlo

Ejecuta pruebas de mesa y prácticas con un laboratorio o entorno autorizado:

1. Un usuario nuevo necesita acceso.
2. A una laptop le faltan parches críticos.
3. Un job de backup está en verde, pero se solicita un restore.
4. Llega un ticket prioritario fuera de la disponibilidad del dueño.
5. Un vendor bloquea el avance durante tres días.
6. Debe rotarse una credencial privilegiada.
7. El cliente pide trabajo fuera de alcance.
8. La relación termina y deben entregarse todos los datos.

En cada prueba registra entrada, responsable, aprobación, acción, evidencia, comunicación con el cliente, tratamiento de facturación y cierre. Las brechas se convierten en tu primer backlog de procesos.

Días 31–60: crea una ruta repetible hacia los primeros clientes

Vende un resultado operativo específico

Evita comenzar con una lista de herramientas. Una pequeña empresa compra menos incertidumbre: soporte responsable, rutas de respuesta conocidas, sistemas recuperables, administración más segura o una transición controlada desde TI improvisado.

Una declaración inicial útil tiene cuatro partes:

Ayudamos a [cliente definido] a reducir [problema operativo reconocido] mediante [servicio administrado acotado], con [evidencia o límite de servicio].

La frase debe facilitar la decisión de quién no encaja.

Usa varios canales, pero una sola cadencia semanal

Las referencias importan, pero “esperar el boca a boca” no es un proceso. Comienza con una lista pequeña de prospectos y socios que puedas investigar bien:

• Relaciones profesionales anteriores que puedas contactar de forma ética y legal.
• Contadores, proveedores de telecom, cableado, consultores de software, especialistas de seguridad y otros proveedores adyacentes.
• Grupos empresariales locales y asociaciones de industria.
• Empresas seleccionadas cuidadosamente que coincidan con el perfil.
• Clientes de proyecto que puedan tener una necesidad operativa recurrente.

Cada semana registra:

• Nuevas cuentas investigadas.
• Introducciones relevantes solicitadas.
• Primeras conversaciones.
• Discovery calls.
• Oportunidades calificadas.
• Evaluaciones o propuestas.
• Cierres, pérdidas, razones y fuente.
• Siguiente acción y fecha para cada oportunidad abierta.

Correo frío, llamadas, LinkedIn, eventos, alianzas y referencias pueden funcionar distinto según el mercado. Los primeros 90 días deben identificar qué canal produce conversaciones calificadas para tu perfil, no declarar un ganador universal después de pocos intentos.

Usa discovery para descalificar riesgo

Antes de proponer servicio administrado, confirma:

• Tamaño, ubicaciones, horarios y flujos críticos del negocio.
• Ownership actual de TI y razón del cambio.
• Usuarios, equipos, servidores, tenants, vendors, red, backups y controles de seguridad.
• Incidentes, sistemas sin soporte, proyectos y fechas límite existentes.
• Tomador de decisión, proceso de presupuesto, fechas contractuales e inicio deseado.
• Requisitos regulatorios, de ciberseguro, auditoría o clientes.
• Si el cliente acepta tus estándares mínimos de seguridad y acceso.

Discovery no es diseño gratuito. Cuando el entorno exija evaluación profunda o planeación de remediación, define y cotiza ese trabajo por separado.

Días 61–90: haz onboarding de una promesa controlada

El primer cliente administrado debe validar el modelo operativo, no obligar al negocio a fingir que ya es un proveedor 24/7 maduro.

Usa una puerta de aceptación

No inicies responsabilidad recurrente hasta registrar:

• Alcance, precio, vigencia, horario y exclusiones firmados.
• Contactos autorizados y límites de aprobación.
• Base de activos e identidades.
• Ownership de acceso administrativo y estado de MFA.
• Ownership de backups, retención y expectativas de restore.
• Agentes, licencias, vendors y excepciones requeridas.
• Incidentes, proyectos, sistemas sin soporte y riesgos aceptados abiertos.
• Hitos de onboarding y fecha en que comienza la responsabilidad recurrente.

La checklist de onboarding de clientes contiene la ruta detallada. Cuando el intake revele riesgo desconocido, pausa la promesa afectada o convierte la brecha en un proyecto de remediación aprobado por separado.

Revisa los primeros 30 días de entrega

En la primera revisión operativa, pregunta:

• ¿Cada solicitud entró por el canal acordado?
• ¿La cola mostró responsable y siguiente acción?
• ¿Qué trabajo quedó fuera de alcance?
• ¿Qué alertas produjeron acción y cuáles solo ruido?
• ¿El tiempo y costo directo coincidieron con las suposiciones del precio?
• ¿Las decisiones y credenciales quedaron documentadas de forma segura?
• ¿Alguna promesa dependió por completo de la memoria o disponibilidad de una persona?
• ¿Qué debe cambiar antes de aceptar otro cliente similar?

No escales un flujo solo porque el primer mes fue soportable. Escálalo cuando la evidencia sea repetible.

Entrega dirigida por el dueño frente a ownership solo comercial

El dueño no tiene que seguir siendo el técnico principal para siempre. Al inicio, sin embargo, alguien calificado debe ser responsable de la verdad técnica y la entrega frente al cliente.

Si el fundador no ejecutará el trabajo, establece antes de vender:

• Un responsable técnico nominal con experiencia verificada.
• Expectativas escritas de disponibilidad, respuesta, escalación y handoff.
• Acceso al stack seleccionado y un ensayo completo del flujo.
• Una segunda ruta ante ausencia o falla.
• Autoridad clara para cambios rutinarios y aprobación del cliente para acciones de mayor riesgo.
• Efectivo suficiente para pagar entrega, retrabajo y escalación antes de cobrar al cliente.

Una lista de freelancers posibles no es capacidad de entrega. La capacidad existe cuando una persona calificada aceptó el rol, conoce el entorno y proceso, puede acceder de forma segura y tiene una ruta de escalación probada.

Contratista o empleado: decide por la relación y el trabajo

No fijes el pago del contratista como un porcentaje universal de tu tarifa al cliente. Ubicación, habilidad, escasez, horario, responsabilidad, herramientas, seguro, viaje, utilización y clasificación laboral cambian la respuesta.

Usa contratista cuando

• El trabajo es acotado, especializado, por proyecto, onsite o variable.
• Puedes especificar un resultado y evidencia de aceptación.
• La demanda todavía no sostiene utilización estable.
• La entrega independiente y la sustitución coinciden con la relación real.

Considera empleado cuando

• El trabajo es recurrente, central al servicio y necesita disponibilidad constante.
• Necesitas controlar horarios, coaching, proceso y continuidad con el cliente.
• El margen predecible puede sostener nómina cargada y tiempo no facturable.
• La relación real opera como empleo supervisado.

Para cada opción modela el costo cargado de entrega: compensación, cargas de nómina o contratista, impuestos aplicables, tiempo de gestión, herramientas, seguro, viaje, capacitación, tiempo sin asignación, retrabajo y escalación. Después prueba si el ingreso recurrente todavía financia ventas, administración, riesgo y utilidad después de la entrega.

La clasificación es una cuestión legal y fiscal, no una elección de nombre. En Estados Unidos, la guía de clasificación del IRS considera control conductual, control financiero y relación entre las partes. En Reino Unido, la guía de contratistas de GOV.UK señala que el estatus fiscal y laboral puede ser distinto. Busca asesoría local calificada para tu jurisdicción.

Un dashboard semanal para los primeros 90 días

Mantén el dashboard lo bastante pequeño para revisarlo cada semana:

• Conversaciones comerciales calificadas creadas.
• Oportunidades abiertas con siguiente acción y fecha.
• Ingreso recurrente firmado y fecha de inicio.
• Trabajo de onboarding restante y bloqueos.
• Tickets por prioridad, responsable y estado de espera.
• Tiempo facturable, incluido, de onboarding y retrabajo.
• Costo directo del servicio y margen estimado de entrega.
• Excepciones de seguridad, backup, acceso y alcance sin responsable.
• Horas del dueño en entrega, ventas, administración y fuera de horario.
• Runway de efectivo y costos mensuales comprometidos.

El propósito no es reportar a inversionistas. Es exponer cuándo el crecimiento, la calidad de servicio o la carga del dueño se vuelven inseguros.

Checklist de los primeros 90 días

Para el día 90, confirma:

• Existe un perfil inicial de cliente y otro de no encaje.
• Una oferta recurrente acotada está documentada.
• Horario, prioridades, exclusiones y escalación están por escrito.
• Los estándares mínimos de seguridad, backup, acceso y documentación están definidos.
• El servicio completo fue ensayado.
• El precio incluye entrega, administración, riesgo y trabajo no facturable.
• Una cadencia semanal de prospección corrió el tiempo suficiente para mostrar señal real.
• Discovery captura encaje comercial y riesgo técnico.
• El primer onboarding usa una puerta de aceptación y fecha de responsabilidad.
• Cada ticket puede mostrar responsable, siguiente acción y evidencia de cierre.
• Existe una ruta alternativa de entrega ante ausencia del dueño.
• Los disparadores para contratista o contratación están escritos en términos operativos y financieros.
• La operación puede exportar datos del cliente y completar un offboarding limpio.

Error común

El error común es construir las partes visibles del MSP antes que su sistema operativo invisible. Un sitio pulido, varias suscripciones de vendors y un catálogo largo pueden existir mientras nadie sabe quién responde un ticket prioritario, cómo se aprueba una excepción, si funciona un restore o qué canal crea la siguiente conversación calificada.

Construye primero la promesa y la evidencia. Agrega herramientas, clientes y personas solo cuando cada adición tenga responsable, un flujo financiado y prueba de que funciona.

Cuándo cambiar de nivel

Agrega capacidad dedicada cuando el trabajo recurrente esté documentado, sea predecible y desplace de forma constante ventas, revisión o entrega segura; no solo después de una semana ocupada. Fortalece la mesa de servicio cuando responsables y siguientes acciones vivan en chat o memoria. Reduce la oferta cuando cada cliente nuevo cree stack y procesos distintos. Eleva precio o cambia alcance cuando el servicio consuma más entrega y riesgo de lo que financia el contrato.

Antes de expandirte a cobertura 24/7, entornos regulados, respuesta avanzada de seguridad, cloud complejo o soporte onsite amplio, confirma que personas calificadas, contratos, seguros, herramientas, escalación y efectivo pueden sostener la promesa más fuerte.

Para la base de ciberseguridad del negocio y de su servicio a clientes, usa los recursos rápidos de NIST CSF 2.0 para pequeñas empresas. La guía es un punto de partida para decisiones de riesgo, no un sustituto de obligaciones específicas de tus clientes o jurisdicción.