Transformez vos e-mails en revenus avec Brew.
Créez des automatisations e-mail utiles : déclencheurs explicites, contrôles d’éligibilité, délais et tests qui reflètent l’évolution de l’état du client.
Une automatisation e-mail est une décision reproductible sur le moment d’envoyer un message. L’outil de création n’en est qu’une partie. L’événement, l’état actuel du client et les règles d’arrêt comptent tout autant que le texte.
Avant de dessiner une séquence, notez pourquoi chaque message doit exister et ce qui le rendrait inapproprié au moment de son envoi.
Une inscription, un achat finalisé, un paiement échoué ou une étape clé dans le produit peuvent lancer une automatisation. Donnez à l’événement un sens clair. « Utilisateur actif » est ambigu ; « premier rapport exporté » est un fait que l’application peut enregistrer et tester.
N’incluez que les données dont le message a besoin, avec des identifiants stables et, si c’est utile, un horodatage. Décidez quel système fait foi pour chaque valeur. La transmission d’un événement peut donner lieu à de nouvelles tentatives : utilisez le mécanisme d’idempotence que prend en charge votre intégration et testez la réception d’un même événement en double.
L’intégration Stripe fournit des événements d’abonnement et de paiement documentés. Des événements personnalisés envoyés par votre application peuvent couvrir les étapes clés propres à votre produit.
Une attente change le moment où l’étape suivante s’exécute. Elle ne met pas à jour, à elle seule, les faits que connaît l’automatisation.
Dans une séquence Brew déclenchée par un événement, les nœuds « Filtre » et « Embranchement » conditionnel distinguent les données de l’événement de celles du contact. activated ou payload.activated lit l’événement d’origine. Un payload d’inscription qui indique activated: false peut être périmé dès le lendemain. contact.activated lit la valeur actuelle du champ de contact Brew du destinataire au moment où ce nœud de condition s’exécute, y compris après une « Attente ».
Pour un rappel de configuration, déclarez un champ de contact booléen activated, synchronisez-le depuis votre application, et placez un filtre contact.activated equals false après l’attente. Une valeur manquante n’équivaut pas à false : testez les deux cas. Placez une condition avant chaque rappel ultérieur qui dépend de cet état ; une mise à jour du contact ou un nouvel événement n’annule pas automatiquement une exécution déjà lancée.
Cette lecture du contact n’interroge ni la base de données de votre produit ni votre prestataire de facturation. Si l’éligibilité dépend d’une activité non synchronisée, d’une facture précise ou du contenu actuel du panier, programmez cette vérification dans votre application. À l’échéance, lisez l’enregistrement qui fait foi et ne déclenchez un nouvel événement d’éligibilité que si le rappel a encore du sens.
Le guide de la séquence d’essai présente les deux approches. La documentation des automatisations explique les chemins des champs de condition.
Une automatisation de bienvenue peut fournir la ressource ou l’étape suivante promise à l’inscription. Une notification de paiement peut expliquer un événement de facturation réel. Un e-mail d’étape clé peut aider quelqu’un à tirer parti de ce qu’il vient d’accomplir dans le produit.
Gardez une première version assez petite pour pouvoir l’examiner en détail. Pour chaque message, notez l’audience, le déclencheur, les champs requis, l’action visée et les conditions qui doivent empêcher l’envoi. Incluez le statut d’abonnement et le comportement des exclusions dans cette revue.
Dans Brew, ce sont les automatisations publiées qui déterminent l’exécution. Créer ou modifier un brouillon ne revient pas à le publier. Les réglages d’intégration et l’état d’une automatisation ont des rôles différents : par exemple, le paramètre Synchroniser le nom complet de l’intégration Stripe contrôle la mise à jour des noms, pas l’exécution des automatisations déclenchées par des événements.
Testez une exécution normale, des champs facultatifs manquants, un événement en double, un contact désabonné du marketing et un client dont l’état change avant l’échéance d’un rappel. Pour les conditions sur le contact, modifiez le champ Brew pendant l’attente et vérifiez que la condition suivante écarte bien le rappel. Pour les rappels programmés par l’application, vérifiez qu’elle n’envoie pas de nouvel événement d’éligibilité quand le client ne remplit plus les conditions.
Examinez l’e-mail réellement reçu, en plus de l’historique d’exécution. Vérifiez les liens, les balises de fusion, le domaine d’envoi et la version publiée exacte. Une requête de déclenchement réussie ne prouve pas à elle seule que le bon message est arrivé dans la bonne boîte de réception.
Une séquence permanente peut devenir obsolète sans bruit quand les étapes de configuration, les tarifs ou l’accès au produit changent. Attribuez un responsable à chaque séquence et revoyez-la après chaque version du produit qui la concerne.
Mesurez le résultat visé et les effets indésirables. Si l’objectif est que la configuration soit terminée, suivez cette action en même temps que les plaintes et les désabonnements. Appuyez-vous sur le guide des métriques pour ne pas prendre les ouvertures pour la preuve que l’automatisation a aidé.
