Un email para convertir una prueba gratuita debe responder a lo que ha hecho el usuario. Quien todavía no ha creado ningún proyecto necesita ayuda con la configuración. Quien ha usado el producto a diario necesita una explicación clara del plan de pago. Si les envías a los dos la misma cuenta regresiva, pasas por alto esa diferencia.

Esta guía separa el diseño de la secuencia de la lógica de la aplicación que decide quién debe recibir cada email.

Elige un evento de activación

Elige una acción que demuestre que el usuario ha llegado al primer resultado útil del producto. Tiene que ser lo bastante concreta como para que tu backend pueda registrarla: un proyecto creado, una importación completada o una invitación enviada a alguien del equipo. Una visita a una página rara vez basta por sí sola.

Guarda el momento del registro, el fin de la prueba, la activación y el estado de pago en el sistema responsable de esos datos. Trata los campos de contacto de la plataforma de email como datos sincronizados, no como garantía de que un flujo iniciado antes esté leyendo el estado actual.

Dale a cada mensaje un solo objetivo

Estos tiempos son puntos de partida que debes poner a prueba, no intervalos medidos que hayan demostrado funcionar mejor. Indica la fecha real de fin de la prueba y qué pasa después. No inventes escasez ni des a entender que se hará un cargo si no hay ningún método de pago registrado.

Elige la fuente de las comprobaciones de requisitos

En un flujo de Brew activado por un evento, payload.activated lee el evento original, mientras que contact.activated lee el valor actual del campo del contacto del destinatario en Brew cuando se ejecuta un nodo Filtro o División por condiciones. Para omitir los recordatorios de configuración después de la activación, declara ese campo booleano, mantenlo sincronizado desde tu producto y comprueba contact.activated equals false después de cada paso de Espera relevante. Que falte el valor no es lo mismo que valga false; pruébalo por separado.

Estas lecturas usan el contacto guardado en Brew, no la base de datos de tu aplicación ni una consulta a Stripe en tiempo real. Recibir un evento de activación o de pago no cancela automáticamente una ejecución anterior. El grafo necesita una condición antes de cada envío que dependa del estado.

Para los datos que están fuera de Brew, haz que tu aplicación programe una tarea. Cuando toque ejecutarla, lee el estado actual de la cuenta o de la factura y lanza un evento personalizado de Brew aparte solo si el destinatario sigue cumpliendo los requisitos. Incluye en ese evento nuevo los datos actuales que necesita la personalización.

Por ejemplo, un recordatorio programado desde la aplicación funciona así:

Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data

Es decir: cuando se confirma el registro, se lanza el evento de bienvenida. Cuando vence la tarea del recordatorio, se lee la cuenta actual. Si el usuario ya se activó o pagó, la tarea termina sin lanzar ningún evento de email; si sigue cumpliendo los requisitos, se lanza el evento del recordatorio de configuración con los datos actuales.

Usa el ID de disparador que devuelve Brew y el esquema declarado del disparador. Sigue la guía para configurar automatizaciones y la documentación sobre contratos de payload tipados. Cuando reintentes el lanzamiento de un evento, usa el mecanismo de idempotencia documentado.

Usa Stripe para los datos de los que es responsable

Si Stripe gestiona la prueba, sus eventos de suscripción aportan el contexto de facturación. La integración con Stripe ofrece disparadores para los eventos compatibles, como customer.subscription.trial_will_end. La activación en el producto sigue siendo responsabilidad de tu aplicación, salvo que envíes esa información por separado.

Para un recordatorio posterior relacionado con el pago, comprueba el registro actual en Stripe. Que una tarjeta se haya actualizado correctamente no demuestra que se haya pagado una factura. Coordínate con los emails que envía el propio Stripe para que el cliente reciba un solo aviso por cada finalidad.

Escribe el email después de definir la regla de requisitos

Parte de la situación real del destinatario. Explica una acción útil y enlaza directamente a ella. Un email de configuración puede ofrecer un ejemplo breve y una dirección de respuesta. Un email sobre el plan de pago debe describir el límite o la función que vienen al caso y el precio real, con un enlace a los precios vigentes.

Haz que el consentimiento de marketing, la gestión de las bajas y el propósito del dominio encajen con el mensaje. Registrarse en una prueba no justifica recibir emails promocionales que no tienen nada que ver con ella.

Demuestra que las salidas funcionan

Prueba qué ocurre cuando un contacto se activa o paga antes de cada comprobación de requisitos. Con condiciones sobre el contacto, actualiza los campos de Brew correspondientes durante la espera y confirma que el recordatorio se omite. Con comprobaciones programadas desde la aplicación, confirma que las cuentas que no cumplen los requisitos no generan ningún evento de recordatorio. Comprueba también los reintentos, las ampliaciones del periodo de prueba, la eliminación de cuentas, las bajas y los campos que faltan. Revisa tanto los registros de la aplicación como el historial de ejecuciones de Brew.

Evalúa la activación y la conversión a planes de pago con los datos de tu producto, y los fallos de entrega con la plataforma de email. Las tasas de apertura, por sí solas, no muestran si la secuencia ha ayudado a un usuario en periodo de prueba. Consulta el diseño de secuencias de bienvenida para ver ejemplos y MCP frente a REST para saber cómo repartir la implementación.