Qué tiene que estar listo antes de abrir registros en un lanzamiento: checklist técnico

Un checklist técnico de un lanzamiento es la lista de comprobaciones que confirma, antes de abrir registros, que cada capa del sistema aguanta el pico: captación, tracking, deduplicación, CRM, asignación comercial, comunidades, mensajería y dashboards. Su objetivo no es que todo funcione en una prueba tranquila, sino que siga funcionando con miles de registros en pocas horas.

He trabajado en lanzamientos que concentran en pocos días la mayor parte de la captación y de las ventas de un negocio, con registros entrando a la vez desde YouTube, Instagram, Telegram, Ads y email. Lo que aprendes ahí es incómodo: durante el pico no hay tiempo para diagnosticar nada. O el sistema estaba preparado, o improvisas con el equipo comercial esperando leads y la audiencia haciendo clic en enlaces que no llevan a ninguna parte.

Este artículo es la versión ordenada de ese aprendizaje. Primero, cómo se ve la arquitectura de un lanzamiento; después, el checklist por fases. Si lo que vas a lanzar es un curso o una membresía, conviene tener antes clara la máquina de entrega: la repaso en infoproductos: qué son y qué exigen por debajo.

¿Por qué colapsan los lanzamientos si “todo funcionaba” la semana anterior?

Porque la semana anterior no había volumen. Un formulario que recibe diez registros al día no te enseña nada sobre cómo se comporta cuando recibe cientos en una hora. Los errores pequeños, con volumen, se multiplican.

En un lanzamiento típico, los síntomas se parecen mucho entre sí:

• Formularios que dejan de enviar datos o que los envían sin la fuente, así que nadie sabe de qué canal viene cada registro.
• Leads duplicados: la misma persona se registra desde un anuncio y luego desde un email, y aparece dos veces en el CRM.
• Dos comerciales llamando al mismo lead, porque el reparto se hizo antes de detectar el duplicado.
• Grupos de WhatsApp llenos: el enlace publicado en anuncios y emails apunta a un grupo que ya no admite a nadie más, justo cuando más tráfico llega.
• Cifras que llegan tarde: el informe del lanzamiento se reconstruye al día siguiente, cuando ya no sirve para mover presupuesto ni para repartir mejor el trabajo.

Ninguno de estos problemas es exótico. Lo que los hace caros es el momento en que aparecen. Por eso un lanzamiento se diseña como un sistema, no como una colección de herramientas conectadas a última hora. Si quieres el marco general de cómo se piensan estas capas, lo explico en la guía de sistemas para negocios digitales.

¿Qué capas tiene el sistema técnico de un lanzamiento?

Cuando reviso la infraestructura de un lanzamiento, no empiezo por las herramientas. Empiezo por el recorrido de un registro: desde que alguien hace clic en un anuncio hasta que un comercial habla con él o entra en una comunidad. Ese recorrido atraviesa siempre las mismas capas.

Captación: el punto donde se pierden registros sin que nadie lo vea

La captación es la capa más visible y, curiosamente, la que menos se prueba. Una página que carga bien en tu portátil puede ir lenta con tráfico concentrado, y un formulario conectado por un webhook puede dejar de enviar datos sin mostrar ningún error al usuario. El usuario ve “gracias por registrarte” y el registro no existe en ningún sitio.

Lo mínimo aquí: saber exactamente dónde se guarda cada registro en el momento en que se envía, y tener una copia de respaldo si el destino principal falla.

Tracking: la fuente de cada registro tiene que viajar hasta el CRM

Si el canal y la campaña no se guardan en el propio registro, la atribución del lanzamiento se convierte en una discusión entre GA4, la plataforma de anuncios y el CRM, que nunca van a dar la misma cifra. Profundizo en ese problema en el artículo sobre atribución rota entre GA4 y el CRM. Para un lanzamiento, la regla práctica es sencilla: cada registro entra etiquetado con su canal y su campaña, y esa etiqueta no se pierde por el camino.

Deduplicación antes de asignación, nunca después

Este es probablemente el aprendizaje más caro de todos los que salen del caso de infraestructura para lanzamientos de alto volumen. Si el reparto de leads ocurre antes de detectar duplicados, dos comerciales acaban hablando con la misma persona y deshacer ese reparto con el lanzamiento en marcha cuesta muchísimo más que evitarlo.

La deduplicación tiene que decidir qué dato identifica a una persona (email normalizado, teléfono con prefijo, o una combinación), qué registro se conserva cuando hay dos y qué información del duplicado se fusiona, por ejemplo una segunda fuente.

CRM y asignación: un lead, un responsable

El CRM es la fuente de verdad del lanzamiento. Si hay una hoja de cálculo paralela “por si acaso”, ya tienes dos fuentes de verdad y ninguna fiable. La asignación comercial reparte cada lead por reglas explícitas (capacidad de cada comercial, tipo de lead, horario) y deja constancia de quién es el responsable.

Comunidades: el enlace que no puede apuntar a un grupo lleno

Muchos lanzamientos usan grupos y comunidades de WhatsApp para calentar a la audiencia, enviar recordatorios y abrir ventas. Los grupos tienen un límite de participantes y se llenan justo cuando más tráfico llega. Cambiar enlaces a mano en anuncios, emails y páginas durante la campaña es lento y propenso a errores.

Este problema aparecía en cada lanzamiento, y por eso lo convertimos en producto: CommunityRedirect es un enlace único que consulta la capacidad, rota destinos y no envía a nadie a un grupo sin plazas. Tanto si usas una herramienta así como si lo resuelves de otra forma, la pregunta del checklist es la misma: ¿qué pasa con el siguiente clic cuando el grupo actual se llena? Y si además envías recordatorios y avisos automáticos por WhatsApp, decide antes del lanzamiento si van por la app o por la API oficial, con sus plantillas y límites: lo comparo en WhatsApp Business o API oficial.

Dashboards: leer el lanzamiento mientras ocurre

Un dashboard de lanzamiento no es un informe bonito para el lunes. Es la herramienta con la que decides, durante la campaña, qué canal está trayendo registros de calidad, si hay que mover presupuesto o si el equipo comercial está saturado. Solo sirve si lee de una fuente en la que todos confían, y eso nos devuelve a las capas anteriores.

¿Cómo se prueba un lanzamiento antes de abrir registros?

Con volumen. Un lanzamiento se prueba con carga antes de abrir registros, porque durante el pico no hay tiempo para diagnosticar. Probar que “un registro de prueba llega al CRM” no es suficiente.

Lo que conviene simular:

1. Registros en ráfaga desde varios canales a la vez, con fuentes distintas, para ver que el tracking no se mezcla.
2. Duplicados intencionados: la misma persona desde dos canales, con el email escrito de forma distinta (mayúsculas, espacios), para comprobar que la deduplicación los detecta.
3. Asignación con capacidad llena: qué pasa cuando todos los comerciales llegan a su límite.
4. Fallo de una integración: desconectar a propósito un destino y confirmar que los registros no se pierden y que alguien recibe una alerta.
5. Grupo lleno: forzar que un destino de comunidad no tenga plazas y verificar a dónde va el siguiente usuario.

Después de las pruebas, se borran los datos ficticios del CRM, de los dashboards y de las listas de envío. Parece obvio, pero un dashboard que arranca el lanzamiento con registros de prueba ya ha perdido la confianza del equipo.

¿Qué es un plan B en la infraestructura de un lanzamiento?

Es la respuesta escrita, antes del lanzamiento, a la pregunta “¿qué hacemos si esto falla?” para cada capa crítica. No hace falta un documento largo. Hace falta que exista, que el equipo lo conozca y que no dependa de que una persona concreta esté despierta.

Un plan B razonable incluye:

• Formulario alternativo preparado y probado, con los mismos campos y la misma etiqueta de fuente.
• Copia de los registros en un destino secundario, para poder reconstruir si el principal falla.
• Destinos de comunidad de reserva listos para recibir tráfico.
• Mensajes preparados para la audiencia si hay que cambiar una fecha o un enlace.
• Responsable técnico y canal de aviso definidos para la ventana crítica, con un criterio claro de qué se considera incidencia grave.

Sobre este último punto conviene ser honesto: el soporte técnico instantáneo no existe por defecto. Si necesitas a alguien disponible durante las horas críticas del lanzamiento, eso se planifica y se reserva. En FCG Systems, la disponibilidad en directo durante las ventanas críticas se define por escrito antes de empezar (ventanas, prioridades y capacidad reservada), dentro del alcance del proyecto.

Checklist técnico de un lanzamiento, por fases

Esta es la lista que usaría para revisar un lanzamiento de infoproducto. Adáptala a tus herramientas, pero no te saltes fases.

Semanas antes de abrir registros

• Recorrido de un registro dibujado de principio a fin: clic, formulario, CRM, asignación, comunidad, mensajes.
• Una fuente de verdad definida para los leads del lanzamiento (y comunicada al equipo).
• Parámetros de campaña (UTM o equivalentes) definidos por canal: YouTube, Instagram, Telegram, Ads y email.
• Canal y campaña guardados en el propio registro, no solo en la herramienta de analítica.
• Criterio de deduplicación decidido: qué identifica a una persona y qué registro se conserva.
• Deduplicación colocada antes de la asignación comercial.
• Reglas de asignación escritas: capacidad por comercial, prioridades y qué pasa cuando todos están llenos.
• Destinos de comunidad preparados, con reservas, y sistema para no enviar a nadie a un grupo lleno.
• Secuencias de email y WhatsApp revisadas, con límites de envío de cada plataforma comprobados en su documentación.
• Dashboard del lanzamiento conectado a la fuente de verdad, con registros, asignaciones y ventas por fuente.
• Logs y alertas en cada integración crítica, con una persona responsable de cada alerta.
• Credenciales y accesos revisados: nada caduca durante el lanzamiento, nada está guardado en un chat.
• Copias de seguridad de los datos que no se pueden reconstruir.

72 horas antes

• Prueba de carga con registros en ráfaga desde varios canales.
• Prueba de duplicados con variantes de email y teléfono.
• Prueba de asignación con comerciales al límite de capacidad.
• Prueba de fallo: una integración desconectada a propósito, registros recuperados y alerta recibida.
• Prueba de grupo lleno y paso al siguiente destino.
• Datos de prueba eliminados del CRM, dashboards y listas.
• Plan B escrito y compartido: formulario alternativo, destinos de reserva, mensajes preparados.
• Responsable técnico y canal de aviso confirmados para la ventana crítica.
• Congelación de cambios: nada nuevo entra en producción sin validación.

Durante el lanzamiento

• Dashboard abierto y revisado a intervalos fijos, no solo cuando alguien pregunta.
• Comparación rápida entre registros recibidos en formularios y registros en el CRM, para detectar pérdidas.
• Vigilancia de la capacidad del equipo comercial y de los destinos de comunidad.
• Alertas atendidas por su responsable, con registro de qué pasó y qué se hizo.
• Cambios en caliente solo si están en el plan B; el resto, anotado para después.

Después del lanzamiento

• Reconciliación final: registros, duplicados fusionados, asignaciones y ventas por fuente.
• Lista de incidencias con causa, impacto y solución aplicada.
• Documentación actualizada con lo aprendido.
• Decisión sobre qué problemas se repiten y merecen una solución permanente en lugar de otro parche.
• Sistema preparado para reutilizarse en el siguiente lanzamiento, no desmontado.

¿Merece la pena montar esto para cada lanzamiento?

Si cada lanzamiento se construye desde cero, no. Es caro, cansado y repites los mismos errores. Lo que cambia la ecuación es tratarlo como infraestructura: un sistema documentado que se reutiliza de un lanzamiento a otro y mejora con los datos de cada campaña.

En el caso de lanzamientos de alto volumen, el resultado fue exactamente ese: operar con un único registro por persona, un responsable comercial por lead y una lectura por fuente disponible durante la campaña, con un sistema que se reutiliza en lugar de montarse cada vez. Las cifras detalladas de esa operación no se publican, pero el patrón sirve para cualquier negocio que viva de lanzamientos.

Y hay un último aprendizaje que me parece el más útil: los problemas que aparecen en cada lanzamiento son candidatos a producto. Si tu equipo arregla lo mismo en cada campaña, no necesitas otro parche; necesitas que esa pieza deje de depender de la improvisación. Si además tus automatizaciones fallan sin que nadie se entere, te interesa leer por qué las automatizaciones que fallan en silencio son el riesgo más infravalorado de un lanzamiento.

¿Tu próximo lanzamiento tiene alguna capa sin resolver?

Si al repasar el checklist has encontrado casillas que no puedes marcar con seguridad, ese es el punto de partida. En FCG Systems diseñamos y construimos infraestructura de lanzamientos para infoproductores, academias y negocios que concentran su captación en pocos días: captación, tracking, deduplicación, asignación, comunidades y dashboards funcionando como un solo sistema. También cubrimos la parte de datos y tracking y la infraestructura técnica que hay debajo.

Lo mejor es empezar varias semanas antes de abrir registros. Cuéntame qué proceso os está frenando en el próximo lanzamiento y te digo por qué capa empezaría.