Secuencia de emails de onboarding basada en eventos
Resumen
Una secuencia de emails de onboarding debe construirse alrededor de un evento de activación y enviarse según señales de comportamiento, no según días del calendario. Empieza con un email de bienvenida, añade un empujón de 24 horas que solo se dispare si falta la primera acción, define las reglas de salida antes de escribir el copy y mide el clic hasta la activación frente a un grupo de control, no la tasa de apertura.
Una secuencia de emails de onboarding funciona cuando reacciona a lo que hizo un usuario nuevo, no a cuántos días han pasado. Construyela alrededor de un evento de activación, envía cada email por una señal concreta y dale a cada uno una condición de salida. Un calendario fijo de día 1, día 3 y día 7 sirve como plan de respaldo, no como diseño.
La mayoría de los equipos hace lo contrario. Escriben cinco emails, les ponen retrasos y lo lanzan. Seis semanas después la activación no se ha movido y nadie sabe qué email es responsable.
Empieza por el evento de activación, no por el email de bienvenida
La secuencia existe para llevar a un registro hasta una sola acción medible. Elígela antes de escribir una línea de copy. "Creó un proyecto" o "envió la primera petición a la API" sirven. "Inició sesión" no.
Define también la ventana. Nuestro valor por defecto es la activación dentro de los 14 días posteriores al registro, contada por cohorte de registro. Sin ventana no hay forma de comparar dos versiones de la secuencia.
Después trabaja hacia atrás. Lista los pasos que un usuario debe completar para llegar a ese evento y asigna como máximo un email por paso. Si un paso no tiene email, el usuario lo hace solo o aceptas la pérdida.
Omite el email de "recorrido por las funciones". Responde a una pregunta que nadie se hizo el segundo día. Un email, una acción, un enlace.
¿Cómo es una secuencia mínima en la práctica?
Cinco emails cubren la mayoría de los productos SaaS con prueba gratuita. Esta es la forma que vemos funcionar, con el disparador de cada uno.
Bienvenida: se envía con
user.signed_up, en cuestión de segundos. Confirma la cuenta, nombra la única primera acción y enlaza directamente a ella.Empujón a la primera acción: se envía 24 horas después del registro, solo si todavía no se disparó el evento del paso 1 de activación.
Ayuda ante bloqueos: se envía cuando aparece una señal de fallo conocida, como una clave de API inválida o una importación abandonada. Es el email de mayor valor de todo el conjunto.
Prueba social: se envía el día 3 a quienes empezaron pero no terminaron. Un resultado de cliente, un número con su contexto.
Último empujón: se envía cuando el usuario está a un evento de la activación, o el día 7 como respaldo basado en tiempo.
Fíjate en que tres de los cinco son condicionales. El email de bienvenida es el único que va a todos.
Los emails de bienvenida también tienen las mejores tasas de apertura que verás jamás. Desconfía de ese número: la protección de privacidad de Apple Mail precarga las imágenes e infla las aperturas en buena parte de tu lista. Mide el clic hasta la activación en su lugar.
Los envíos por tiempo fallan justo con los usuarios que más importan
Un envío puramente basado en tiempo manda el email del día 3 a un usuario que se activó el día 1. Ese usuario recibe ahora un mensaje que le pide hacer algo que ya hizo. Se lee como automatización, y lo es.
También falla en sentido contrario. Un usuario atascado en el paso 2 recibe un email alegre sobre una función, no ayuda. La secuencia no ve el problema, así que no puede responder.
La solución no es complicada, pero necesita una fuente de eventos. Las secuencias de comportamiento necesitan tres entradas: el flujo de eventos, un estado por usuario y una regla que compruebe ese estado antes de cada envío.
{
"trigger": "user.signed_up",
"steps": [
{ "id": "welcome", "delay": "0s" },
{ "id": "first_action_nudge", "delay": "24h",
"send_if": "NOT event(project.created)" },
{ "id": "proof", "delay": "72h",
"send_if": "event(project.created) AND NOT event(first_send)" },
{ "id": "last_step", "delay": "7d",
"send_if": "NOT event(activated)" }
],
"exit_when": ["activated", "unsubscribed", "account.deleted"]
}La comprobación send_if se ejecuta en el momento del envío, no en el momento de la inscripción. Esa diferencia importa. Si evalúas la condición cuando el usuario entra en el flujo, has construido un segmento estático, y el estado estará desactualizado cuando el email salga.
La condición de salida es la función que la gente olvida
Toda secuencia necesita una regla que la termine. La obvia es la activación. Otras dos suelen olvidarse: darse de baja del flujo de onboarding, y la eliminación de la cuenta o el fin de la prueba.
Hemos visto secuencias que siguen escribiendo a usuarios que ya habían pasado a ser de pago. Eso es un error en la condición de salida, y cuesta más que una apertura perdida. Le enseña al usuario que tus emails no están ligados a su cuenta.
Escribe primero las reglas de salida y pruébalas primero. Reproduce algunas trayectorias reales de usuarios por el flujo en un entorno de staging y comprueba que cada una se detiene donde debe. Una secuencia con buen copy y sin salidas es peor que una con copy sencillo y salidas limpias.
De dónde salen los datos de eventos
La calidad de la secuencia depende de la calidad de la señal. Hay tres fuentes habituales, y cada una tiene una latencia y unos modos de fallo distintos.
Un pipeline de analítica de producto como Segment reenvía eventos en segundos, pero solo los eventos que instrumentaste. Un webhook directo desde tu backend es el más fiable, porque se dispara desde el mismo código que hace el trabajo. La captura de cambios de Postgres ve todo lo que toca la fila, incluidos los cambios hechos por scripts de administración, lo que puede ser una función o un bug.
Elige una sola fuente de verdad para el evento de activación y documéntala junto a la definición del flujo, para que el siguiente ingeniero no añada una segunda. Dos fuentes que discrepan unos minutos producen emails que contradicen el estado del producto. Así es como un usuario recibe "Termina de configurar tu cuenta" después de haberla terminado.
La idempotencia también importa. Los pipelines de eventos reintentan, así que el mismo project.created puede llegar dos veces. Si tu sender no deduplica por clave, el usuario recibe un envío doble.
Customer.io está construido alrededor de este modelo: ingiere eventos por API, SDKs o un CDP, y dispara desde un constructor de flujos. Si ya trabajas con otro stack, el mismo patrón funciona con cualquier sender que acepte un disparador y evalúe las condiciones en el momento del envío.
Transaccional o marketing: elige el canal con intención
Algunos emails de onboarding son transaccionales en la práctica. Un mensaje de "tu clave de API está lista" o una verificación de email no deberían esperar detrás de una cola de marketing, ni compartir reputación de envío con una campaña promocional.
Postmark convierte esta separación en un principio de diseño, separando los streams de mensajes en infraestructuras distintas. El razonamiento es sólido aunque no uses Postmark: una mala campaña promocional nunca debería retrasar un restablecimiento de contraseña.
Nuestra regla es simple. Si el usuario no puede avanzar sin el email, va al stream transaccional. Si el email es un ánimo o un consejo, va al stream de lifecycle, con un enlace de baja que solo afecta a ese stream.
¿Un sender pensado para desarrolladores cambia la forma de construirlo?
Cambia el punto de partida. Con un sender con API primero, la lógica de la secuencia vive en tu código o en un worker pequeño, y el proveedor solo entrega. Obtienes control de versiones, tests y revisión de código para tus flujos, y pierdes el constructor visual.
Resend sigue este camino, con una API REST, SDKs oficiales y plantillas de React Email. Para un equipo que ya trata los emails como componentes, es un encaje razonable. Para un equipo de crecimiento que quiere editar el copy sin hacer deploy, es fricción.
Sé honesto sobre quién edita la secuencia. Si la respuesta es "crecimiento, cada semana", un constructor de flujos es la opción correcta, aunque a los ingenieros no les guste. Si la respuesta es "ingeniería, en cada release", déjala en código.
Mide el clic hasta la activación, no las aperturas
La tasa de apertura es una señal débil para este trabajo. Las funciones de privacidad del correo la inflan, y una apertura no significa que el usuario hiciera nada. Tres números dicen más.
Clic hasta la activación: de los usuarios que hicieron clic en un email concreto, cuántos alcanzaron el evento de activación en 24 horas.
Latencia de disparo: el tiempo entre el evento y el envío. En un email de ayuda ante bloqueos, cualquier retraso de más de unos minutos hace perder el momento.
Tasa de activación frente a un grupo de control: aparta un pequeño grupo de registros de la secuencia y compara su activación a 14 días con la del resto.
El grupo de control es la única forma de saber que la secuencia funciona. Sin él, atribuyes a los emails una activación que habría ocurrido igual.
No citamos aquí una tasa de activación de referencia, porque las publicadas por proveedores usan definiciones distintas. Mide primero tu propia línea base. Después cambia un email cada vez.
¿Una secuencia o varias?
Divide por condición de entrada, no por etiquetas de perfil. Un usuario que se registró con una invitación tiene una primera acción distinta a la de quien se registró solo. Un usuario que importó datos ya cruzó una línea que los demás todavía no han cruzado.
Dos o tres rutas de entrada suelen bastar. Más que eso, y el coste de mantenimiento supera la mejora, porque cada ruta necesita sus propias salidas y pruebas.
Una plataforma todo en uno puede reducir el trabajo de configuración cuando el equipo es pequeño. Brevo reúne email, SMS y CRM bajo un mismo acceso, lo que encaja con equipos que todavía no quieren montar un pipeline de eventos. La contrapartida es que el panel de marketing queda en el centro, y los disparos en menos de un segundo no son lo que optimiza.
Qué lanzaríamos primero
Escribe el evento de activación y la ventana de 14 días en una sola línea. Construye el email de bienvenida y el empujón de 24 horas con una comprobación send_if y una salida limpia. Añade un grupo de control del 5 al 10 por ciento desde el primer día.
Deja la prueba social y el último empujón para cuando tengas dos semanas de datos. Añade el email de ayuda ante bloqueos en cuanto puedas nombrar el fallo más frecuente en tus logs. ¿Qué señal de fallo de tu producto conectarías primero?