Sequenza email di onboarding: su eventi, non su giorni
Riassunto
Una sequenza email di onboarding dovrebbe ruotare attorno a un solo evento di attivazione e inviare ogni email per effetto di un segnale dell'utente, non di un giorno del calendario. Si parte da un'email di benvenuto, si aggiunge una spinta a 24 ore che scatta solo se manca la prima azione, si definiscono le uscite prima del copy e si misura il click-to-activate rispetto a un holdout, non il tasso di apertura.
Una sequenza email di onboarding funziona quando reagisce a quello che un nuovo utente ha fatto, non a quanti giorni sono passati. Va costruita attorno a un solo evento di attivazione, con ogni email inviata per effetto di un segnale e con una condizione di uscita per ciascuna. Un calendario fisso con giorno 1, giorno 3 e giorno 7 è il ripiego, non il progetto.
La maggior parte dei team fa il contrario. Scrivono cinque email, aggiungono dei ritardi e rilasciano tutto. Sei settimane dopo, l'attivazione non si è mossa e nessuno sa dire quale email ne sia responsabile.
Partire dall'evento di attivazione, non dall'email di benvenuto
La sequenza esiste per portare una registrazione verso un'azione misurabile. Va scelta prima di scrivere una sola riga di copy. «Ha creato un progetto» oppure «ha inviato la prima richiesta API» vanno bene. «Ha fatto il login» no.
Definire anche la finestra temporale. Il nostro default è l'attivazione entro 14 giorni dalla registrazione, contata per coorte di iscrizione. Senza finestra non si possono confrontare due versioni della sequenza.
Poi si lavora a ritroso: si elencano i passaggi che l'utente deve completare per arrivare a quell'evento e si assegna al massimo una email a ogni passaggio. Se un passaggio non ha un'email, l'utente lo fa da solo oppure si accetta l'abbandono.
Saltare l'email «tour delle funzionalità». Risponde a una domanda che nessuno si era posto il secondo giorno. Una email, un'azione, un link.
Come appare una sequenza minima nella pratica?
Cinque email coprono la maggior parte dei prodotti SaaS con una prova gratuita. Questa è la forma che regge, con il trigger di ciascuna.
Benvenuto: inviata su
user.signed_up, entro pochi secondi. Conferma l'account, indica la prima azione e porta dritto a quella.Spinta sulla prima azione: inviata 24 ore dopo la registrazione, solo se non è scattato l'evento del primo passaggio verso l'attivazione.
Aiuto sul blocco: inviata quando compare un segnale di errore noto, come una chiave API non valida o un import abbandonato. È l'email con il valore più alto dell'intero set.
Email di prova: inviata al giorno 3 a chi ha iniziato ma non ha finito. Un solo risultato concreto del cliente, un solo numero con il suo contesto.
Ultimo passo: inviata quando l'utente è a un solo evento dall'attivazione, oppure al giorno 7 come ripiego basato sul tempo.
Tre su cinque sono condizionate. L'email di benvenuto è l'unica che va a tutti.
Anche le email di benvenuto hanno i tassi di apertura più alti che vedrai mai. Va trattato questo numero con sospetto: la Mail Privacy Protection di Apple precarica le immagini e gonfia le aperture per una parte consistente della lista. Conviene misurare il click-to-activate.
Le sequenze a tempo falliscono proprio con gli utenti più importanti
Un drip puramente temporale invia l'email del giorno 3 a un utente che si è attivato il giorno 1. Quell'utente riceve l'invito a fare qualcosa che ha già fatto. Sembra automazione, ed è automazione.
Fallisce anche nell'altra direzione. Un utente bloccato sul secondo passaggio riceve un'email allegra sulle funzionalità, non un aiuto. La sequenza non vede il problema, quindi non può reagire.
La soluzione non è complicata, ma richiede una fonte di eventi. Le sequenze comportamentali hanno bisogno di tre input: il flusso di eventi, uno stato per ogni utente e una regola che controlla lo stato prima di ogni invio.
{
"trigger": "user.signed_up",
"steps": [
{ "id": "welcome", "delay": "0s" },
{ "id": "first_action_nudge", "delay": "24h",
"send_if": "NOT event(project.created)" },
{ "id": "proof", "delay": "72h",
"send_if": "event(project.created) AND NOT event(first_send)" },
{ "id": "last_step", "delay": "7d",
"send_if": "NOT event(activated)" }
],
"exit_when": ["activated", "unsubscribed", "account.deleted"]
}Il controllo send_if gira al momento dell'invio, non al momento dell'iscrizione. La distinzione conta. Se la condizione viene valutata quando l'utente entra nel flusso, si è costruito un segmento statico, e lo stato sarà già vecchio quando l'email partirà.
L'uscita è la funzionalità che tutti dimenticano
Ogni sequenza ha bisogno di una regola che la chiuda. Quella ovvia è l'attivazione. Altre due vengono spesso trascurate: la disiscrizione dal flusso di onboarding e la cancellazione dell'account o la scadenza della prova.
Abbiamo visto sequenze continuare a scrivere agli utenti dopo che erano passati a un piano a pagamento. È un bug della condizione di uscita, e costa più di un'apertura mancata. Insegna all'utente che le tue email non sono legate al suo account.
Scrivere prima le regole di uscita e testarle per prime. Riprodurre in staging alcune timeline di utenti reali attraverso il flusso e verificare che ciascuna si fermi dove deve. Una sequenza con un copy ottimo ma senza uscite è peggiore di una sequenza con un copy semplice e uscite pulite.
Da dove arrivano i dati degli eventi
La qualità della sequenza dipende dalla qualità del segnale. Ci sono tre fonti comuni, con latenze e modalità di guasto diverse.
Una pipeline di product analytics come Segment inoltra gli eventi in pochi secondi, ma solo quelli che sono stati strumentati. Un webhook diretto dal backend è il più affidabile, perché parte dal percorso di codice che esegue il lavoro. La change data capture di Postgres vede tutto ciò che tocca la riga, comprese le modifiche fatte dagli script amministrativi, che può essere una funzionalità oppure un bug.
Scegliere una sola fonte di verità per l'evento di attivazione e documentarla accanto alla definizione del flusso, così il prossimo ingegnere non ne aggiunge una seconda. Due fonti che non concordano di qualche minuto producono email che contraddicono lo stato del prodotto. È così che un utente riceve «Completa la configurazione» dopo averla completata.
Anche l'idempotenza conta. Le pipeline di eventi ritentano, quindi lo stesso project.created può arrivare due volte. Se il sender non deduplica per chiave, l'utente riceve un doppio invio.
Customer.io è costruito su questo modello: riceve gli eventi tramite API, SDK o CDP e fa scattare i trigger da un workflow builder. Se si lavora su un altro stack, lo stesso schema funziona con qualsiasi sender che accetti un trigger e valuti le condizioni al momento dell'invio.
Transazionale o marketing: scegliere lo stream con consapevolezza
Alcune email di onboarding sono transazionali nei fatti. Un messaggio «la tua chiave API è pronta» o una verifica dell'indirizzo non dovrebbero attendere in coda dietro al marketing, né condividere la reputazione d'invio con una campagna promozionale.
Postmark fa di questa separazione un principio di design, mettendo gli stream di messaggi su infrastrutture diverse. Il ragionamento è solido anche se non si usa quel servizio: un cattivo invio promozionale non dovrebbe mai ritardare un reset della password.
La regola è semplice. Se l'utente non può andare avanti senza quell'email, va sullo stream transazionale. Se l'email è un incoraggiamento, va sullo stream lifecycle, con un link di disiscrizione che incide solo su quello stream.
Un sender orientato agli sviluppatori cambia la costruzione?
Cambia il punto di partenza. Con un sender API-first, la logica della sequenza vive nel codice o in un piccolo worker, e il provider si limita a consegnare. Si ottengono version control, test e code review per i flussi, ma si perde il builder visuale.
Resend segue questa strada, con una REST API, SDK ufficiali e template React Email. Per un team che tratta le email come componenti è una scelta coerente. Per un team growth che vuole modificare il copy senza un deploy è un attrito.
Chiedersi chi modifica davvero la sequenza. Se la risposta è «il growth, ogni settimana», un workflow builder è la scelta giusta, anche se agli ingegneri non piace. Se la risposta è «l'ingegneria, a ogni release», la sequenza resta nel codice.
Misurare il click-to-activate, non le aperture
Il tasso di apertura è un segnale debole per questo lavoro. Le funzioni di privacy delle mail lo gonfiano, e un'apertura non significa che l'utente abbia fatto qualcosa. Tre numeri dicono di più.
Click-to-activate: tra gli utenti che hanno cliccato una certa email, quanti hanno raggiunto l'evento di attivazione entro 24 ore.
Latenza del trigger: il tempo tra l'evento e l'invio. Per un'email di blocco, oltre pochi minuti il momento è già passato.
Attivazione rispetto a un holdout: trattenere un piccolo gruppo di registrazioni fuori dalla sequenza e confrontarne l'attivazione a 14 giorni con quella del resto.
L'holdout è l'unico modo per sapere se la sequenza funziona. Senza, si attribuiscono alle email delle attivazioni che sarebbero avvenute comunque.
Non citiamo un tasso di attivazione di riferimento, perché quelli pubblicati arrivano da fornitori con definizioni diverse. Misurare prima la propria baseline. Poi cambiare una email alla volta.
Una sequenza sola o più sequenze?
Dividere per condizione di ingresso, non per etichette di persona. Un utente registrato da un invito ha una prima azione diversa da chi si è registrato da solo. Chi ha importato dati ha già superato una soglia che gli altri non hanno ancora superato.
Di solito bastano due o tre percorsi di ingresso. Oltre, il costo di manutenzione supera il guadagno, perché ogni percorso richiede le proprie uscite e i propri test.
Una piattaforma tutto-in-uno può ridurre il lavoro di setup quando il team è piccolo. Brevo riunisce email, SMS e CRM sotto un solo accesso, adatto a chi non vuole ancora collegare una pipeline di eventi. Il compromesso è che la dashboard marketing sta al centro, e i trigger sotto il secondo non sono ciò per cui è ottimizzata.
Cosa rilasceremmo per primo
Scrivere su una sola riga l'evento di attivazione e la finestra di 14 giorni. Costruire l'email di benvenuto e la spinta a 24 ore con un controllo send_if e un'uscita pulita. Aggiungere un holdout dal 5 al 10 percento fin dal primo giorno.
Lasciare l'email di prova e l'ultimo passo finché non ci sono due settimane di dati. Aggiungere l'email di blocco appena si riesce a dare un nome al guasto più frequente nei log. Quale segnale di errore del prodotto collegheresti per primo?