Un’email pensata per convertire una prova dovrebbe rispondere a ciò che l’utente ha fatto. Chi non ha ancora creato un progetto ha bisogno di aiuto con la configurazione. Chi ha usato il prodotto ogni giorno ha bisogno di una spiegazione chiara del piano a pagamento. Mandare a entrambi lo stesso conto alla rovescia ignora questa differenza.

Questa guida tiene separata la progettazione della sequenza dalla logica applicativa che decide chi deve ricevere ogni email.

Scegli un evento di attivazione

Individua un’azione che dimostri che l’utente ha ottenuto il primo risultato utile dal prodotto. Rendila abbastanza specifica da poter essere registrata dal tuo backend: un progetto creato, un’importazione completata o un collega invitato. Una visualizzazione di pagina, da sola, raramente basta.

Salva l’orario di registrazione, la fine della prova, l’attivazione e lo stato del pagamento nel sistema che fa fede per quei dati. Tratta i campi del contatto nella piattaforma email come dati sincronizzati, non come la prova che un flusso avviato in precedenza stia leggendo uno stato aggiornato.

Dai a ogni messaggio un solo compito

Queste tempistiche sono punti di partenza per un test, non intervalli misurati come i più efficaci. Indica la scadenza effettiva della prova e cosa succede dopo. Non inventare scarsità e non lasciare intendere che ci sarà un addebito se non è registrato nessun metodo di pagamento.

Scegli la fonte per le verifiche di idoneità

In un flusso di Brew attivato da un evento, payload.activated legge l’evento originale, mentre contact.activated legge il campo attuale del contatto del destinatario in Brew nel momento in cui viene eseguito un nodo Filtro o Divisione condizionale. Per saltare i promemoria sulla configurazione dopo l’attivazione, dichiara quel campo booleano, mantienilo sincronizzato dal tuo prodotto e verifica contact.activated equals false dopo ogni Attesa rilevante. Un valore mancante non equivale a false: testalo a parte.

Queste letture usano il contatto salvato in Brew, non il database della tua applicazione né una richiesta in tempo reale a Stripe. Ricevere un evento di attivazione o di pagamento non annulla automaticamente un’esecuzione già avviata. Il diagramma ha bisogno di una condizione prima di ogni invio che dipende dallo stato.

Per i dati che stanno fuori da Brew, fai programmare un processo alla tua applicazione. Quando arriva il momento, leggi l’account o la fattura attuali e invia a Brew un evento personalizzato separato solo se il destinatario è ancora idoneo. Includi in quel nuovo evento i dati aggiornati che servono per la personalizzazione.

Ad esempio, un promemoria programmato dall’applicazione funziona così:

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

In altre parole: quando la registrazione viene salvata, parte l’evento di benvenuto. Quando arriva il momento del processo del promemoria, l’applicazione legge l’account attuale: se l’utente ha già completato l’attivazione o pagato, il processo si chiude senza inviare nessun evento email; se è ancora idoneo, invia l’evento del promemoria sulla configurazione con i dati aggiornati.

Usa l’ID del trigger effettivamente restituito da Brew e lo schema dichiarato del trigger. Segui la guida alla configurazione delle automazioni e la documentazione sui contratti tipizzati del payload. Per i nuovi tentativi di attivazione degli eventi, usa il meccanismo di idempotenza documentato.

Usa Stripe per i dati di sua competenza

Se è Stripe a gestire la prova, i suoi eventi sugli abbonamenti forniscono il contesto della fatturazione. L’integrazione con Stripe mette a disposizione trigger per gli eventi supportati, tra cui customer.subscription.trial_will_end. L’attivazione nel prodotto resta di competenza della tua applicazione, a meno che tu non invii quell’informazione separatamente.

Per un promemoria successivo legato al pagamento, controlla il record attuale su Stripe. Un aggiornamento della carta andato a buon fine non dimostra che una fattura sia stata pagata. Coordinati con le email che invia Stripe, così il cliente riceve un solo avviso per ogni scopo.

Scrivi l’email dopo la regola di idoneità

Parti dalla situazione reale del destinatario. Spiega un’azione utile e metti un link diretto per compierla. Un’email sulla configurazione può offrire un breve esempio e un indirizzo a cui rispondere. Un’email sul piano a pagamento dovrebbe descrivere il limite o la funzionalità pertinente e il prezzo reale, con un link ai prezzi aggiornati.

Mantieni consenso al marketing, gestione della disiscrizione e finalità del dominio coerenti con il messaggio. Una registrazione alla prova non giustifica email promozionali che non c’entrano.

Dimostra che le uscite funzionano

Testa cosa succede quando un contatto completa l’attivazione o paga prima di ciascuna verifica di idoneità. Con le condizioni sul contatto, aggiorna i campi rilevanti in Brew durante l’attesa e conferma che il promemoria venga saltato. Con le verifiche programmate dall’applicazione, controlla che gli account non idonei non generino un evento di promemoria. Testa anche i nuovi tentativi, le proroghe della prova, l’eliminazione dell’account, le disiscrizioni e i campi mancanti. Controlla sia i log dell’applicazione sia la cronologia delle esecuzioni in Brew.

Valuta l’attivazione e la conversione a pagamento con i dati del tuo prodotto, e gli errori di consegna con la piattaforma email. I tassi di apertura da soli non dicono se la sequenza ha aiutato un utente in prova. Consulta come progettare una sequenza di benvenuto per gli esempi e MCP o API REST per come dividere il lavoro di implementazione.