El primer paso en Migma es definir con precisión qué acción pedimos al usuario en cada email de onboarding. Justo después, conviene fijar una regla igual de clara con el responsable del flujo para determinar cuándo deja de tener sentido ese recordatorio. Por muy cuidado que esté el diseño de un email de configuración, resultará frustrante si el usuario completó ese paso ayer.
Esta guía elaborada por Migma se centra en las reglas de salida (exit rules) para equipos que trabajan con Loops. En lugar de limitarse al típico calendario de envíos por días fijos, propone una plantilla de revisión y casos de prueba prácticos. La documentación oficial se revisó el 15 de octubre de 2026. Migma cubre la fase de revisión creativa descrita aquí; los responsables de producto y de la plataforma de envío son quienes deben implementar y validar el estado de los contactos y la lógica del flujo.
Define la activación con un criterio verificable en producto
Resume en una sola frase la acción concreta que motiva el recordatorio. En una herramienta de gestión de proyectos, por ejemplo, un hito representativo sería crear un primer proyecto que incluya al menos una tarea. Iniciar sesión o abrir el email de bienvenida no demuestran que ese objetivo se haya cumplido.
A continuación, identifica la fuente de ese dato. Un evento de producto, una propiedad de contacto almacenada y la apertura de un email son señales totalmente distintas. El responsable de producto debe detallar cómo llega ese estado a la plataforma de envío y cómo se comprueba su recepción. Un texto que diga «termina de configurar tu proyecto» no puede basarse en suposiciones sobre si el usuario ya lo ha creado o no.
La guía de ejemplos de onboarding de Loops propone reflejar la activación en una propiedad de contacto y comprobarla antes de disparar los siguientes emails del flujo. Define un hito propio que encaje con tu producto en lugar de copiar propiedades de ejemplo sin consensuar qué representan.
Diseña un briefing creativo con columna de salida
Prepara en Migma el copy definitivo, las pautas de marca y la llamada a la acción de cada mensaje. Añade además una tabla de apoyo para el responsable de automatización. Mantén esta ficha junto a la versión de diseño para que el equipo pueda contrastar cada texto con la condición técnica que lo justifica.
| Objetivo del mensaje | Estado del usuario que lo justifica | Cuándo frenar o cambiar el mensaje |
|---|---|---|
| Ayudar a crear el primer proyecto | No ha alcanzado el hito acordado | Se registra la acción completada |
| Explicar una integración pendiente | La integración sigue sin configurarse y el usuario tiene permisos para gestionarla | La integración funciona o el usuario no tiene ese rol |
| Ofrecer soporte en la configuración | El usuario sigue cumpliendo condiciones pero no avanza | Se completa la configuración, cambia su rol o termina la secuencia |
| Proponer el siguiente paso de valor | Ha completado el primer hito | El siguiente paso ya se ha completado o no aplica |
Estas reglas son una propuesta para la app de ejemplo, no resultados métricos ni una configuración prediseñada para Loops. Revísalas con los responsables de datos de producto antes de activar el flujo.
Revisa el alcance de los filtros de audiencia
La documentación sobre ramificaciones de Loops distingue actualmente entre «All following nodes» y «Next node only». En el primer caso, si un contacto deja de cumplir el filtro más adelante, queda fuera del flujo. En el segundo, la condición se evalúa en el momento en que el contacto entra al nodo siguiente, por lo que cambios posteriores no lo expulsarán por ese motivo.
Este alcance es crítico cuando alguien completa la configuración durante un periodo de espera. Comprobar un filtro solo al inicio no garantiza que los mensajes posteriores sigan siendo pertinentes. Pide al responsable del flujo que muestre con claridad dónde se evalúa el hito y qué ocurre con los contactos que ya están esperando en un paso intermedio.
Revisa también la versión real de las ramas. Loops documenta una transición de la evaluación paralela anterior al modelo de primera coincidencia (first match) en ramas nuevas; las ramas creadas previamente conservan su lógica original hasta que se actualicen de forma explícita. No asumas el comportamiento de un flujo guardado basándote solo en una captura de la documentación actual.
Separa los roles de usuario del estado de activación
Un colaborador invitado puede estar muy activo sin tener permisos para conectar una fuente de datos corporativa. Del mismo modo, el propietario de un espacio de trabajo puede haber completado esa integración mientras otro compañero esperaba un recordatorio para hacerlo. El briefing debe delimitar si la acción corresponde al usuario individual, a la cuenta o al espacio de trabajo.
Refleja esta distinción en el copy. Decir «Conecta la fuente de datos de tu equipo» tiene sentido para un administrador, pero desconcierta a un perfil invitado sin permisos. Si no contáis con datos de rol fiables, redacta una alternativa neutral y pide al equipo técnico que gestione de forma explícita los estados indefinidos.
Según la documentación, las ramas actuales evalúan los filtros de izquierda a derecha y ejecutan la primera coincidencia válida. Un filtro situado al final sin condiciones puede servir como ruta predeterminada. Diseñar esta ruta es una decisión editorial clave: la falta de datos no debería traducirse automáticamente en un reproche injustificado por no haber terminado la configuración.
Pon a prueba a usuarios que cambian de estado durante la espera
Elabora un protocolo de pruebas con registros ficticios y haz que el responsable técnico lo ejecute en un entorno controlado. Nunca alteres propiedades de contactos reales solo para conseguir una captura de pantalla.
Configura al menos estos perfiles: uno que no complete el proceso; otro que alcance el hito antes del primer recordatorio; un tercero que termine la configuración en pleno periodo de espera entre emails; un cuarto con datos ausentes o incompletos; y un quinto que represente a un usuario sin permisos para realizar la acción solicitada.
En cada caso, documenta el mensaje esperado (o la salida del flujo), el comportamiento real observado y la versión de diseño evaluada. Si el usuario recibe un recordatorio después de haber completado la acción, revisa la actualización de estados y el alcance de los filtros antes de tocar el titular. Ningún copy puede compensar una segmentación de audiencia mal configurada.
Traslada el diseño validado a la plantilla final
Revisa el email en Migma para comprobar que la acción principal queda clara y que se explica bien el paso pendiente. Utiliza Email Preflight para inspeccionar los elementos de diseño. Mantén el contenido conciso para que la llamada a la acción y las vías de ayuda se identifiquen al instante.
Si el traspaso se hace en HTML, recurre a las opciones de exportación de Migma para que el equipo técnico adapte la plantilla de destino. Esto no implica la existencia de un conector nativo de exportación entre Migma y Loops. Comprueba el destino final de los botones según los roles y estados de prueba: un enlace puede funcionar a nivel técnico pero dirigir al usuario a una pantalla en la que no tiene permisos.
Distingue la validación creativa de las pruebas de automatización. El borrador en Migma refleja lo que el equipo ha aprobado; el email recibido de prueba y el registro del flujo muestran cómo responde el recorrido configurado.
Detén el recordatorio y abre la siguiente conversación útil
Alcanzar el objetivo debe cerrar de inmediato las peticiones de configuración obsoletas. Eso no significa disparar otro email al instante. Evalúa si el usuario necesita una confirmación, una guía sobre pasos posteriores más adelante o, sencillamente, espacio para explorar el producto.
En la aplicación de ejemplo, crear el primer proyecto puede dar paso días después a consejos sobre trabajo en equipo, mientras que un usuario estancado recibirá una propuesta breve de soporte. Son mensajes con propósitos distintos y exigen briefings independientes. Cambiarle el nombre al mismo aviso de configuración para seguir enviándolo no funciona.
Diseña las piezas en Migma manteniendo la regla de salida a la vista durante la revisión. Después, coordínate con el responsable del flujo para verificar que los recordatorios se detienen por el motivo adecuado. Una secuencia de onboarding eficaz valora el progreso del usuario con el mismo rigor con el que se lo pide.
Preguntas frecuentes
¿La apertura de un email sirve como regla de salida en el onboarding?
Abrir un email no demuestra que se haya alcanzado el hito de producto. Conviene acordar una acción real dentro del software y verificar cómo se transmite ese estado a la herramienta de envío.
¿Qué sucede si un usuario se activa durante un tiempo de espera?
Lo idóneo es que los recordatorios de configuración pendientes se detengan. El responsable del flujo debe comprobar el estado actualizado del contacto y el alcance de los filtros de audiencia para quienes ya estén esperando en ese paso.
¿Todas las ramas guardadas en Loops siguen la misma lógica de evaluación?
No. La documentación actual distingue entre ramas nuevas (evaluadas por primera coincidencia) y ramas antiguas (que conservan la evaluación en paralelo hasta que se actualizan expresamente). Comprueba la versión del flujo guardado antes de dar por sentada su lógica.
¿Este proceso requiere un conector nativo entre Migma y Loops?
No. El diseño y la revisión se gestionan en Migma y luego se adaptan en destino mediante una exportación adecuada o como referencia visual. El equipo técnico valida la plantilla final y el funcionamiento del flujo.