# Secuencias de emails de bienvenida: ejemplos, tiempos y requisitos

URL canónica: https://brew.new/es/blog/welcome-email-sequence
Autoría: Brew Team
Publicado: 2026-08-16
Actualizado: 2026-09-29

Una secuencia de bienvenida ayuda a un suscriptor nuevo a saber qué hacer a continuación. En un producto SaaS, puede ser crear su primer proyecto. En una tienda, entender la gama de productos. En una newsletter, saber qué va a recibir y con qué frecuencia.

Empieza por la promesa que hiciste en el registro. Cada email posterior debe ayudar a cumplirla. Los tiempos y el número de mensajes dependen del producto y de la audiencia; los ejemplos de abajo son puntos de partida que debes poner a prueba. La secuencia de bienvenida es el primero de los flujos de ciclo de vida de la guía de [automatización de emails con IA](/es/blog/ai-email-automation).

## Elige bien el evento de inicio

| Punto de partida | Primer mensaje útil | Qué comprobar |
| --- | --- | --- |
| Cuenta creada | Una acción de configuración | Si la verificación del email debe hacerse antes |
| Email verificado | Bienvenida y un enlace directo al producto | No duplicar el email de verificación |
| Suscripción a la newsletter | Qué esperar y un ejemplo útil | El consentimiento del destinatario y los temas que eligió |
| Registro en la tienda | Productos, orientación o la oferta prometida | Las condiciones reales de la oferta y su caducidad |

Brew puede iniciar flujos a partir de eventos personalizados de tu backend o de integraciones compatibles como [Supabase](/es/browse/integrations/supabase) y [Clerk](/es/browse/integrations/clerk). Crea el payload a partir del esquema del disparador que elijas y usa su ID real.

## Un ejemplo de bienvenida para SaaS

| Email | Momento inicial | Objetivo | Requisitos en el momento del envío |
| --- | --- | --- | --- |
| Bienvenida | Tras el registro o la verificación | Ayudar a crear el primer proyecto | Cuenta nueva |
| Ayuda con la configuración | Día 2 | Mostrar un ejemplo breve | No se ha activado |
| Siguiente paso | Tras la activación | Presentar la siguiente acción útil | Se ha activado |
| Recordatorio de la prueba | Antes de que termine la prueba | Explicar qué pasa después | Sigue en periodo de prueba y no ha pagado |
| Seguimiento | Tras un intervalo adecuado | Ofrecer ayuda | Sigue cumpliendo los requisitos y tiene permiso para recibirlo |

Escribe cada email en torno a una sola acción. Usa una URL de destino real, un asunto claro y una dirección de respuesta que alguien revise. Evita la urgencia genérica y las afirmaciones sobre resultados que no has medido.

## Un ejemplo de bienvenida para una newsletter o una tienda

En una newsletter, el primer mensaje puede entregar el recurso prometido, indicar la frecuencia prevista y mostrar un artículo representativo. Un mensaje posterior puede explicar las preferencias de temas o presentar a quien la escribe. Una newsletter no necesita un embudo de activación al estilo SaaS para justificar un segundo email.

En una tienda, entrega primero la oferta prometida y después ofrece orientación útil para comprar. Indica con exactitud las exclusiones y la caducidad. Una compra puede hacer que los recordatorios de descuento pendientes dejen de tener sentido, así que incluye el estado de compra en tus comprobaciones de requisitos.

## Define las reglas de salida antes de escribir los siguientes emails

Decide qué debe impedir cada mensaje: la activación, una compra, una oferta caducada, la eliminación de la cuenta, una baja o un cambio de plan. Después, implementa esa regla en el sistema que de verdad lee el estado actual.

En un flujo de Brew activado por un evento, una condición sobre `payload.activated` lee el evento original. Una condición sobre `contact.activated` lee el valor actual del campo del contacto en Brew cuando se ejecuta el nodo, también después de un paso de Espera. Declara y sincroniza el campo, y pon la condición antes de cada recordatorio que dependa de él. Una actualización del contacto o un evento posterior no cancelan automáticamente una ejecución anterior.

Si los requisitos dependen de datos de la cuenta que no están sincronizados o de una compra concreta, programa una comprobación en tu aplicación. Lee el registro de referencia cuando toque enviar el mensaje y, solo si la regla se sigue cumpliendo, dispara un evento aparte para el recordatorio. Consulta [cómo crear una automatización](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders) en la documentación.

## Crea y revisa la secuencia

Describe en Brew el disparador, la audiencia, la acción que buscas y el tono. También puedes partir de un ejemplo público de la [galería de flujos](/es/browse/flows). Toma sus tiempos como inspiración, no como prueba de que el mismo calendario funcionará con tu audiencia.

Revisa el grafo generado y cada email. Confirma los enlaces, el remitente, los valores predeterminados de la personalización y el propósito del dominio. Un mensaje de verificación y un mensaje promocional de onboarding pueden tener requisitos distintos. La [guía de la FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) explica el criterio de finalidad principal que se aplica en EE. UU.; los [requisitos para remitentes de Gmail](https://support.google.com/mail/answer/81126) cubren la autenticación, la tasa de spam y las normas de baja.

## Prueba algo más que el caso ideal

Prueba un registro, un evento repetido, la falta de datos de personalización y un destinatario que no cumple los requisitos. En las condiciones sobre el contacto, actualiza el campo sincronizado durante la espera y confirma que el recordatorio se omite; prueba también con campos vacíos. En los recordatorios programados desde la aplicación, activa la cuenta o haz una compra antes de la comprobación y confirma que no se dispara ningún evento de recordatorio. Revisa también la gestión de las bajas y los resultados de entrega.

Publica solo cuando hayas revisado los mensajes y las comprobaciones de requisitos. Haz un seguimiento de la acción que la secuencia debe impulsar, como una configuración completada o un primer pedido, junto con los datos de entrega y de clics. Conserva los mensajes que ayudan a dar ese paso y revisa el resto.

Para ver ejemplos de implementación, consulta [cómo crear el onboarding desde Cursor](/es/blog/how-to-create-an-email-onboarding-sequence-from-cursor) y [la conversión de pruebas a partir de eventos del producto](/es/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).