Trasforma le email in fatturato con Brew.
Crea automazioni email utili con trigger espliciti, verifiche di idoneità, attese e test che riflettono come cambia lo stato dei clienti.
Un’automazione email è una decisione ripetibile su quando inviare un messaggio. L’editor ne è solo una parte. L’evento, lo stato attuale del cliente e le regole di interruzione contano quanto i testi.
Prima di disegnare una sequenza, metti per iscritto perché ogni messaggio dovrebbe esistere e cosa lo renderebbe fuori luogo nel momento in cui parte.
Una registrazione, un acquisto completato, un pagamento non riuscito o un traguardo nel prodotto possono avviare un’automazione. Dai all’evento un significato chiaro. “Utente attivo” è ambiguo; “primo report esportato” è qualcosa che l’applicazione può registrare e testare.
Includi solo i dati che servono al messaggio, con identificativi stabili e, dove serve, un timestamp. Decidi quale sistema fa fede per ciascun valore. La consegna degli eventi può essere ritentata, quindi usa il meccanismo di idempotenza supportato dalla tua integrazione e testa le consegne duplicate.
L’integrazione con Stripe fornisce eventi documentati su abbonamenti e pagamenti. Gli eventi personalizzati della tua applicazione possono coprire i traguardi specifici del tuo prodotto.
Un’attesa cambia il momento in cui viene eseguito il passaggio successivo. Da sola, non aggiorna le informazioni che l’automazione conosce.
In un flusso di Brew attivato da un evento, i nodi Filtro e i nodi Divisione condizionale distinguono i dati dell’evento da quelli del contatto. activated o payload.activated leggono l’evento originale. Un payload di registrazione con activated: false potrebbe essere già superato domani. contact.activated legge il campo attuale del contatto del destinatario in Brew nel momento in cui quel nodo condizione viene eseguito, anche dopo un nodo Attesa.
Per un promemoria sulla configurazione, dichiara un campo booleano del contatto activated, mantienilo sincronizzato dalla tua applicazione e metti un filtro contact.activated equals false dopo l’attesa. Un valore mancante non equivale a false, quindi testa entrambi i casi. Metti una condizione prima di ogni promemoria successivo che dipende da questo stato: un aggiornamento del contatto o un nuovo evento non annulla automaticamente un’esecuzione già in corso.
La lettura del contatto non interroga il database del tuo prodotto né la tua piattaforma di fatturazione. Se l’idoneità dipende da un’attività non sincronizzata, da una specifica fattura o dal contenuto attuale del carrello, programma quella verifica nella tua applicazione. All’orario previsto, leggi il dato che fa fede e invia un nuovo evento idoneo solo se il promemoria ha ancora senso.
La guida alla sequenza per il periodo di prova spiega entrambi gli approcci. La documentazione sulle automazioni spiega i percorsi dei campi nelle condizioni.
Un’automazione di benvenuto può consegnare la risorsa o il passo successivo promesso al momento della registrazione. Una notifica di pagamento può spiegare un evento di fatturazione reale. Un’email per un traguardo nel prodotto può aiutare qualcuno a usare il risultato di ciò che ha appena completato.
Mantieni la prima versione abbastanza piccola da poterla controllare. Per ogni messaggio, annota il pubblico, il trigger, i campi obbligatori, l’azione prevista e le condizioni che dovrebbero impedire un invio. In questa revisione includi lo stato dell’iscrizione e il comportamento delle esclusioni.
In Brew sono le automazioni pubblicate a controllare l’esecuzione. Creare o modificare una bozza non equivale a pubblicarla. Le impostazioni delle integrazioni e lo stato delle automazioni hanno compiti diversi: per esempio, l’impostazione Sincronizza il nome completo di Stripe controlla gli aggiornamenti del nome, non se le automazioni basate sugli eventi vengono eseguite.
Testa un’esecuzione normale, campi facoltativi mancanti, un evento duplicato, un contatto disiscritto dal marketing e un cliente il cui stato cambia prima che sia il momento di inviare un promemoria. Per le condizioni sul contatto, aggiorna il campo in Brew durante l’attesa e verifica che la condizione successiva salti il promemoria. Per i promemoria programmati dall’applicazione, verifica che l’applicazione non invii un nuovo evento idoneo quando il cliente non ha più i requisiti.
Controlla l’email reale oltre al registro dell’esecuzione. Verifica link, merge tag, dominio di invio e la versione pubblicata esatta. Una richiesta al trigger andata a buon fine, da sola, non dimostra che il messaggio giusto sia arrivato nella inbox giusta.
Una sequenza evergreen può diventare obsoleta senza che nessuno se ne accorga quando cambiano i passaggi di configurazione, i prezzi o l’accesso al prodotto. Assegna a ogni sequenza un responsabile e rivedila dopo i rilasci che la riguardano.
Misura il risultato previsto e gli effetti indesiderati. Se l’obiettivo è completare la configurazione, monitora quell’azione insieme a segnalazioni di spam e disiscrizioni. Usa la guida alle metriche per non trattare le aperture come la prova che l’automazione abbia funzionato.
