proceso de incorporación MSP: primeros 14 días, día a día

Cliente nuevo, dispositivos nuevos y un SLA que corre — las dos primeras semanas determinan si la incorporación se convierte en una relación gestionada estable o en una crisis recurrente. Este artículo ofrece un proceso de incorporación para MSP accionable, día a día, para los primeros 14 días de la flota de un cliente: qué desplegar, qué verificar, qué automatizar y cuándo escalar.

Objetivos, alcance y supuestos

Este playbook asume: una flota de 25–500 endpoints, mezcla de Windows y macOS con algunos servidores Linux, una cola central de tickets (SLA: 4 horas hábiles para P2) y un RMM bajo tu control. El enfoque es acceso desatendido, inventario, línea base segura, monitoreo y registros de auditoría. Si el cliente exige infraestructura únicamente local (residencia de datos, sin relays de terceros), trata el alojamiento propio como un requisito de cumplimiento — de lo contrario, el relay gestionado es la opción operativa por defecto.

Herramientas, arquitectura y valores predeterminados recomendados

• Acceso remoto: clientes nativos de Tenvo para Windows/macOS/Linux, además del cliente en navegador (beta pública). Usa el relay gestionado multi-región de Tenvo como predeterminado: reduce la carga del on-call, la rotación de certificados y el esfuerzo de failover cross‑region. Tenvo plans: Free $0, Lite $2.99/mo, Pro $7.99/mo — elige según características y límites de sesión.
• Ticketing/RMM: integra webhooks de inicio/parada de sesión en tu sistema de tickets y RMM. Si necesitas una lista de verificación para conectar el punto de inicio del flujo de trabajo del help‑desk, consulta Cómo configurar soporte remoto para mesa de ayuda.
• Auditoría y grabación: planifica el registro de auditoría desde el día uno. Si tu contrato exige retención larga, diseña el almacenamiento junto al sistema de tickets; consulta Registro de auditoría para escritorios remotos para patrones de implementación.
• Cuándo alojarlo propio: solo por mandatos escritos de cumplimiento, redes aisladas o reglas estrictas de residencia de datos. El alojamiento propio implica operaciones de certificados, failover de relay en on‑call y carga de parcheo — frecuentemente cuesta más en headcount operativo que usar relay gestionado. Consulta Self-Hosted Remote Desktop: Why, How, and What Breaks para los tradeoffs.
• Selección de herramientas: este playbook tiene como objetivo el relay gestionado de Tenvo por defecto. Si quieres comparar alternativas primero, revisa MSP remote support tools: choosing the right stack for 2026.

Día a día: los primeros 14 días (lista de verificación práctica)

1. Day 1 — Contract and access kickoff (Day 0 if you prefer): confirma alcance, SLAs, entrega de cuentas privilegiadas y ventanas de mantenimiento. Recopila credenciales admin, información de VPN y una lista de responsables por unidad de negocio. Añade un contacto de emergencia para administradores de dominio/controlador.
2. Day 2 — Inventory and baseline snapshot: despliega el agente a un grupo piloto (10–20 devices). Captura detalles de hardware/OS, antivirus instalado, uso de disco y rendimiento base. Usa etiquetas del agente para OS, departamento y entorno (prod/test).
3. Day 3 — Unattended access configuration (pilot): habilita acceso desatendido en los dispositivos piloto. Configura acceso basado en roles para técnicos y exige contraseñas fuertes o SSO donde esté soportado. Verifica que los eventos de inicio de sesión se registran en el sistema de tickets.
4. Day 4 — Certificate & network verification: verifica la inscripción de certificados y la conectividad de cada dispositivo. Revisa la traversía NAT: confirma qué dispositivos conectan P2P vs relay. Nota: cuando el tráfico usa el relay, TLS termina en el relay, por lo que el operador del relay puede acceder a los datos de la sesión. Registra qué subredes requieren ajustes de firewall.
5. Day 5 — Firewall and gateway rules: despliega las reglas requeridas de FQDN/IP y excepciones de inspección HTTP/S TLS si el cliente inspecciona tráfico. Prueba una transición de bloqueado a permitido y un camino forzado por relay para confirmar que las sesiones siguen conectando.
6. Day 6 — Credential and vault integration: integra inyección de credenciales de sesión o un vault de secretos (Vault, Bitwarden, CyberArk) para sesiones privilegiadas. Deja de guardar contraseñas admin compartidas en hojas de cálculo; crea una cadencia de rotación (30–90 días) y documenta el proceso de rotación en el runbook.
7. Day 7 — Monitoring and alerting baseline: añade checks de salud de acceso remoto al monitoreo (porcentaje de agentes online, percentiles de tiempo de conexión y conteo de auth fallidas). Establece umbrales de alerta: p. ej., >3 sesiones fallidas en 15m, agente offline >30m.
8. Day 8 — Scale deployment: expande el despliegue del agente al 50–75% de los devices. Usa MSI/GPO o tu RMM para automatizar instalaciones. Mantén una ventana de despliegue por departamento para limitar la interrupción y revertir rápido si aparece un problema con el instalador.
9. Day 9 — Session policies & permissions: aplica el principio de menor privilegio: los técnicos reciben solo los grupos que necesitan. Crea un procedimiento separado de 'break‑glass' para acceso de emergencia con aprobaciones y grabación de auditoría habilitada.
10. Day 10 — Integrate with ticketing and SSO: conecta las APIs de sesión para adjuntar automáticamente IDs de sesión y logs a los tickets. Habilita SAML/SSO (Okta, Azure AD) para logins de técnicos y prueba los flujos de aprovisionamiento/desaprovisionamiento.
11. Day 11 — Recordings and retention policy: si grabas sesiones de soporte, define la retención según contrato y normas de privacidad. Almacena metadata (usuario, técnico, ID de ticket) junto a las grabaciones para auditabilidad. Prueba reproducción y flujos de redacción cuando sea necesario.
12. Day 12 — Performance and UX tuning: mide latencia de sesión, tasa de frames y ancho de banda. Ajusta parámetros de códec, sincronización del portapapeles y políticas de redirección de periféricos para grupos de alto uso (diseñadores, editores de video) y bloquea funciones innecesarias para soporte regular.
13. Day 13 — Backup & failover test: simula una caída del relay y verifica failover a regiones alternativas o rutas VPN locales. Si el cliente prohíbe relays externos, verifica el failover de tu cluster de relay propio, la renovación de certificados y el monitoreo.
14. Day 14 — Review, SLA signoff, and runbook handover: realiza una revisión de 60–90 minutos con el cliente: cobertura de inventario, pasos de respuesta a incidentes, escalamiento on‑call y un plan rodante a 30/60/90 días. Publica runbooks y un panel 'qué vigilamos'. Cierra los items de onboarding en tickets y convierte tareas recurrentes de onboarding en tareas de automatización.

Lista operativa después del día 14

• KPI diarios/semanales a seguir: % de cobertura de agentes, tiempo medio de conexión, tasa de resolución en primer contacto, número de eventos break‑glass.
• Mensual: rotación de credenciales, comprobación de expiración de certificados y un simulacro de respuesta a incidentes (restaurar un dispositivo desde backup y conectar dentro del SLA).
• Runbooks: mantiene un runbook corto por fallo común (instalador de agente fallido, mismatch de certificado, accesibilidad al relay). Guarda scripts de remediación en control de código con historial de cambios.
• Auditoría y cumplimiento: asegura que los logs de sesión se retienen según contrato; considera retenciones más largas para clientes regulados. Consulta Registro de auditoría para escritorios remotos para patrones de implementación.
• Conexión con help‑desk: asegura que los técnicos tengan el conjunto mínimo de herramientas para seguridad y velocidad. Para playbooks de flujo de trabajo y sesiones dirigidas por tickets, consulta Cómo configurar soporte remoto para mesa de ayuda.

Cuándo elegir relay gestionado vs alojamiento propio

Por defecto: usa el relay gestionado de Tenvo. Elimina la carga de failover por región, distribución de certificados y las operaciones 24/7 de relay. Los relays gestionados reducen el tiempo medio de reparación porque no ejecutas la infraestructura de relay, no renuevas certificados en varias regiones ni manejas la custodia de claves.

Alójalo propio solo cuando el contrato del cliente prohíba explícitamente relays de terceros o la red esté aislada. El alojamiento propio requiere correr un cluster HA de relay, renovación automatizada de certificados, monitoreo y gestión de parches — considera el headcount operativo continuo y el riesgo para el SLA. Para un recorrido técnico sobre los tradeoffs del alojamiento propio, consulta Self-Hosted Remote Desktop: Why, How, and What Breaks. Si estás comparando proveedores antes de decidir, este artículo MSP remote support tools ayuda a dimensionar las diferencias operativas.

Scripts prácticos, ejemplos de instalador y comandos de verificación

REM Windows MSI silent install (example)
msiexec /i "tenvo-agent.msi" /qn /norestart /l*v "C:\Windows\Temp\tenvo-install.log"

# PowerShell: verify agent is installed and running
Get-Service -Name TenvoAgent | Select-Object Name, Status

# Powershell: check certificate thumbprint and expiry (local store)
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "CN=tenvo-*" } | Select-Object Subject, Thumbprint, NotAfter

# macOS: pkg install and verify
sudo installer -pkg tenvo-agent.pkg -target /
launchctl list | grep com.tenvo.agent

# Test connectivity: verify P2P vs relay (example agent tool)
tenvo-agent --diag --show-connection
# Expect output: P2P:true or Relay:us-east.tenvo.net

Notas de seguridad y una comprobación realista

Sé explícito con los clientes sobre el modelo de amenazas: una sesión P2P directa es de extremo a extremo entre los dos dispositivos. Cuando la conexión cae al relay, TLS termina en el relay, por lo que quien opere ese relay puede observar el tráfico de la sesión. El relay gestionado de Tenvo usa certificados por dispositivo y relays multi‑región por defecto; eso reduce el riesgo operativo pero no elimina la necesidad de tratar los relays como infraestructura con poder de acceso. Si el cliente no puede tolerar operadores de relay de terceros, planifica el alojamiento propio y presupuesta el trabajo operativo continuo.

Errores comunes y cómo evitarlos

• Desplegar a todos a la vez: causa sobrecarga en el help‑desk. Escala por departamentos y monitoriza la cola de tickets durante el despliegue.
• Omitir comprobaciones de certificados: programa comprobaciones automáticas de expiración y una alerta para certificados con <30 días restantes.
• Sin rastro de auditoría para el break‑glass: cualquier acceso de emergencia debe requerir un ticket de auditoría y grabación para evitar abusos.
• Asumir que el alojamiento propio es más barato: incluye on‑call, parcheo, backups y pruebas de failover en los modelos de costo. Para una comparación realista de TCO, consulta el análisis de herramientas MSP relacionado en MSP remote support tools: choosing the right stack for 2026.

La incorporación de una nueva flota de clientes es principalmente coordinación y automatización: consigue el inventario correcto, asegura el acceso y las credenciales, haz que el monitoreo sea accionable y automatiza correcciones repetitivas en los primeros 14 días para dejar de apagar incendios y empezar a ofrecer operaciones estables. Si quieres un agente listo para el cliente y un relay gestionado para evitar las operaciones de relay, comienza por descargar los clientes y probar un piloto hoy.

Descarga Tenvo para comenzar un despliegue piloto y seguir este playbook de 14 días. Si necesitas ejemplos de configuración más profundos o una checklist de migración, nuestra documentación y los artículos enlazados arriba tienen guías paso a paso.