Crea automatizaciones de email útiles con disparadores claros, comprobaciones de requisitos, esperas y pruebas que reflejen cómo cambia el estado del cliente.
Una automatización de email es una decisión repetible sobre cuándo enviar un mensaje. El editor es solo una parte. El evento, el estado actual del cliente y las reglas para detenerla importan tanto como los textos.
Antes de dibujar una secuencia, anota por qué debería existir cada mensaje y qué haría que dejara de ser adecuado en el momento de enviarse.
Un registro, una compra completada, un pago fallido o un hito en el producto pueden iniciar una automatización. Dale al evento un significado claro. “Usuario activo” es ambiguo; “primer informe exportado” es algo que la aplicación puede registrar y probar.
Incluye solo los datos que necesita el mensaje, con identificadores estables y una marca de tiempo cuando sea relevante. Decide qué sistema es el responsable de cada valor. La entrega de eventos puede reintentarse, así que usa el mecanismo de idempotencia que admita tu integración y prueba qué pasa con una entrega duplicada.
La integración con Stripe proporciona eventos documentados de suscripciones y pagos. Los eventos personalizados de tu aplicación pueden cubrir los hitos propios de tu producto.
Una espera cambia cuándo se ejecuta el siguiente paso. Por sí sola, no actualiza los datos que conoce la automatización.
En un flujo de Brew activado por un evento, los nodos Filtro y los nodos División por condiciones distinguen los datos del evento de los datos del contacto. activated o payload.activated leen el evento original. Un payload de registro que dice activated: false puede estar desfasado mañana. contact.activated lee el valor actual del campo del contacto en Brew cuando se ejecuta ese nodo de condición, también después de un paso de Espera.
Para un recordatorio de configuración, declara un campo booleano del contacto llamado activated, mantenlo sincronizado desde tu aplicación y pon un filtro contact.activated equals false después de la espera. Que falte el campo no es lo mismo que valga false, así que prueba los dos casos. Pon una condición antes de cada recordatorio posterior que dependa de este estado; una actualización del contacto o un evento nuevo no cancelan automáticamente una ejecución ya iniciada.
Esa lectura del contacto no consulta la base de datos de tu producto ni tu proveedor de facturación. Si los requisitos dependen de actividad que no está sincronizada, de una factura concreta o del contenido actual del carrito, programa esa comprobación en tu aplicación. Cuando toque, lee el registro de referencia y lanza un evento nuevo para quien cumpla los requisitos solo si el recordatorio sigue teniendo sentido.
La guía de secuencias para convertir pruebas gratuitas cubre los dos enfoques. La referencia de automatizaciones explica las rutas de los campos en las condiciones.
Una automatización de bienvenida puede entregar el recurso o el siguiente paso que prometiste en el registro. Una notificación de pago puede explicar un evento de facturación real. Un email por un hito en el producto puede ayudar a alguien a aprovechar el resultado de lo que acaba de completar.
Haz que la primera versión sea lo bastante pequeña como para revisarla a fondo. Para cada mensaje, anota la audiencia, el disparador, los campos obligatorios, la acción que buscas y las condiciones que deberían impedir el envío. Incluye en esa revisión el estado de suscripción y el comportamiento de las supresiones.
En Brew, son las automatizaciones publicadas las que controlan la ejecución. Crear o editar un borrador no es lo mismo que publicarlo. La configuración de las integraciones y el estado de las automatizaciones cumplen funciones distintas; por ejemplo, la opción Sincronizar el nombre completo de Stripe controla las actualizaciones del nombre, no si se ejecutan las automatizaciones por eventos.
Prueba una ejecución normal, la falta de campos opcionales, un evento duplicado, un contacto que se ha dado de baja del marketing y un cliente cuyo estado cambia antes de que toque el recordatorio. En las condiciones sobre el contacto, actualiza el campo en Brew durante la espera y confirma que la condición posterior omite el recordatorio. En los recordatorios programados desde la aplicación, confirma que esta no lanza el evento nuevo cuando el cliente ya no cumple los requisitos.
Revisa el email real, no solo el registro de la ejecución. Comprueba los enlaces, las etiquetas de combinación, el dominio de envío y la versión publicada exacta. Que la solicitud al disparador se complete correctamente no demuestra, por sí solo, que el mensaje correcto haya llegado a la bandeja de entrada correcta.
Una secuencia siempre activa puede quedarse obsoleta sin que nadie lo note cuando cambian los pasos de configuración, los precios o el acceso al producto. Asigna un responsable a cada secuencia y revísala después de cada lanzamiento relevante.
Mide el resultado que buscas y los efectos no deseados. Si el objetivo es completar la configuración, haz un seguimiento de esa acción junto con las quejas y las bajas. Usa la guía de métricas para no tomar las aperturas como prueba de que la automatización ha funcionado.
