Sequenze di onboarding SaaS: builder HTML e invio per email che portano al primo valore

Per una sequenza di onboarding SaaS con più rami (utente attivo, utente fermo, trial in scadenza) il miglior abbinamento è Customer.io come motore di invio, con un builder HTML come MJML o React Email per i template. Customer.io è costruito attorno a eventi e workflow visivi, e il piano Essentials parte da 100 $ al mese con fatturazione mensile; per 20.000 profili la fascia Essentials 20k costa 235 $ al mese.

Questa pagina non valuta i builder come prodotti in astratto. Guarda ciò che conta in una sequenza di cinque o sette messaggi nell'arco di circa due settimane: il template deve reggere nei client di posta più usati, l'automazione deve decidere chi riceve cosa e il team deve poter cambiare un messaggio senza rompere gli altri. I prezzi sono quelli pubblicati dai fornitori alla data indicata nel testo; dove un prezzo non è pubblicato, lo scriviamo esplicitamente.

Che cosa deve fare il builder in una sequenza di onboarding

Una sequenza di onboarding è un piccolo insieme di messaggi legati tra loro, ognuno con un compito preciso: confermare l'iscrizione, spingere la prima azione che porta al valore, mostrare un caso d'uso, rispondere all'obiezione più comune e segnalare la fine del trial. Il builder che scegli deve gestire quattro cose in modo ordinato.

• Blocchi condivisi. Intestazione, pulsante, firma e footer devono vivere in un punto solo. Se cambi l'indirizzo di supporto, non vuoi aprire cinque file una per una.
• Variabili dal profilo. Nome, piano o ultima azione completata devono entrare nel testo. Un "Ciao [nome]" rimasto vuoto danneggia più di un saluto generico, quindi ogni variabile va accompagnata da un testo di ripiego.
• Resa nei client. Outlook per Windows, Gmail con le immagini disattivate, i client in modalità scura e gli schermi stretti si comportano in modo diverso. Il builder deve permettere di vedere l'anteprima e di controllare il codice prodotto.
• HTML pulito. Codice gonfio e stili inline ridondanti rendono ogni modifica successiva più lenta e più rischiosa.

Un template può essere comodo in un editor e difficile da mantenere in un altro. Per questo il builder va valutato insieme al motore che lo invia, non da solo.

Le tre famiglie di strumenti

Nella pratica gli strumenti si dividono in tre gruppi. Non si escludono a vicenda: molti team usano un framework o un editor per il layout e un motore di automazione per decidere quando inviare cosa.

Framework da codice: MJML, React Email e Maizzle

Questi strumenti partono da sorgenti scritte a mano e le compilano in HTML compatibile con i client di posta. MJML usa un linguaggio a componenti pensato per le email; React Email permette di scrivere i template come componenti React; Maizzle lavora con utility in stile Tailwind CSS. Sono la scelta giusta quando nel team c'è chi vuole controllare ogni riga, versionare i template insieme al prodotto e far passare le modifiche da una revisione.

Il limite è che chi lavora sul marketing non cambia un testo senza passare dal codice, a meno che il contenuto non sia separato in file o in variabili documentate.

Editor visuali: Stripo, BEE e Unlayer

Gli editor visuali compongono le email con blocchi da trascinare. Sono utili quando il team di crescita deve produrre varianti del messaggio di benvenuto o del promemoria di trial senza aprire una richiesta allo sviluppo. Unlayer è pensato soprattutto per essere integrato dentro un prodotto proprio, mentre Stripo e BEE sono pensati per lavorare direttamente nell'editor.

Il rovescio della medaglia è la dipendenza dall'editor. Un template costruito lì non sempre esce pulito in HTML, e cambiare piattaforma può voler dire ricostruire i blocchi da capo.

Motori di invio con automazioni: Customer.io e Vero

Qui il template è solo una parte. Il motore decide quando inviare, a chi, con quale ritardo e in base a quali eventi. Un trial che entra negli ultimi due giorni o un utente che non completa l'azione chiave sono eventi, non date fisse. Customer.io e Vero lavorano su profili ed eventi, e la scelta tra loro dipende soprattutto dal modello di prezzo.

Tabella 1: confronto degli strumenti

Customer.io: il motore per i rami comportamentali

Customer.io è la scelta più naturale quando la sequenza di onboarding dipende dalle azioni dell'utente. Il workflow visivo collega eventi, attese e condizioni: se l'utente crea il primo progetto entro 24 ore salta il promemoria, altrimenti riceve un messaggio con un solo passo da completare. Il piano Essentials include il costruttore visivo dei workflow, le competenze base dell'agente AI, integrazioni dati di base e supporto via email e community.

Il prezzo segue il numero di profili. Nella pagina prezzi consultata il 7 ottobre 2026, Essentials per 10.000 profili costa 145 $ al mese, per 20.000 costa 235 $, per 30.000 costa 325 $, per 40.000 costa 415 $ e per 50.000 profili o più parte da 505 $. Le fasce sono fatturate mensilmente e ogni fascia di 10.000 profili aggiunge 90 $ al mese. Per una lista di 20.000 profili il conto annuo è quindi 12 × 235 $ = 2.820 $.

Dove scarseggia: il piano Premium, indicato a 1.000 $ al mese, è dimensionato su volumi di profili personalizzati e prevede limiti più alti per l'agente AI e un supporto prioritario. Se la sequenza è lineare e la lista è di medie dimensioni, Essentials basta; il salto a Premium ha senso quando servono più agenti AI o un supporto dedicato. Il fornitore indica anche un programma startup con 12 mesi gratuiti per le aziende early-stage idonee che hanno raccolto meno di 10 milioni di dollari. L'idoneità va verificata sulla pagina ufficiale.

Sul fronte dei template, Customer.io si abbina bene a MJML o React Email: il codice HTML compilato viene caricato come messaggio nel workflow e le variabili del profilo restano nel corpo dell'email. Il vantaggio è che il marketing può spostare un messaggio o cambiare un ritardo senza toccare il template.

Prezzi e condizioni: pagina prezzi di Customer.io.

Vero: il piano Starter per liste piccole

Vero usa un modello composabile. Il piano Starter costa 54 $ al mese e include 5.000 profili, 10.000 email al mese, 20.000 messaggi push e 160.000 eventi tracciati al mese. Per una startup con qualche migliaio di utenti e una sequenza lineare di cinque email è un punto di partenza economico: 12 × 54 $ = 648 $ l'anno, con la fatturazione mensile indicata nella pagina prezzi consultata il 7 ottobre 2026.

Il limite è la scala. Oltre i 5.000 profili lo Starter non basta e si passa al piano Professional, che ha volumi personalizzati di profili, email, push, eventi e SMS e un prezzo che va richiesto direttamente. Anche la complessità dei rami conta: una sequenza con molte condizioni consuma più eventi di una lineare, quindi il tetto di 160.000 eventi al mese va confrontato con i numeri reali del tuo prodotto.

Vero è adatto quando il lavoro delicato è la qualità dei dati del profilo, più della grafica del template. Le variabili arrivano dal profilo al momento dell'invio, quindi un'intestazione costruita in MJML o React Email funziona senza modifiche particolari.

Prezzi e condizioni: pagina prezzi di Vero.

MJML, React Email e Maizzle: quando il template è codice

MJML è pensato per chi vuole scrivere email con una sintassi a componenti. Colonne, pulsanti e intestazioni cambiano poco da un messaggio all'altro, quindi il team costruisce una piccola libreria e la riusa. Il limite è che il team deve integrare la compilazione nel proprio processo di sviluppo.

React Email è la scelta naturale se il prodotto è già scritto in React. I template diventano componenti con le stesse convenzioni di revisione del codice dell'applicazione, e le variabili arrivano come proprietà. Per chi non lavora in React, la curva di apprendimento pesa troppo per una sola sequenza.

Maizzle usa un approccio a utility, familiare a chi conosce Tailwind CSS, e mantiene uno stile unico su tutti i messaggi. È utile quando il frontend vuole un sistema di design anche per le email. Anche qui il marketing non modifica i testi senza il codice, a meno di separare il contenuto in file dedicati.

Per questi tre strumenti la voce di costo non è un listino da confrontare in questa pagina: è il tempo di sviluppo, di revisione e dell'infrastruttura di compilazione. Quando la sequenza cambia spesso, la manutenzione del codice può costare più di un editor visuale; quando cambia poco, il codice resta il modo più controllabile di gestire i template.

Stripo, BEE e Unlayer: editor per il team marketing

Il punto di forza comune dei tre editor è lasciare a chi non scrive codice il controllo di una sequenza completa. Un team può costruire cinque messaggi con la stessa intestazione, lo stesso pulsante e le stesse variabili, e cambiare un colore o un link in tutti i messaggi insieme. Per l'onboarding significa iterare sull'oggetto e sul testo della CTA senza coinvolgere lo sviluppo.

Il limite è l'esportazione. L'HTML prodotto va controllato nei client che contano per la tua base utenti, soprattutto Outlook e le modalità scure. Il secondo limite è la portabilità: i blocchi di un editor non si trasferiscono in un altro, quindi la scelta va fatta pensando a dove resteranno i template nei prossimi due anni.

Per Stripo, BEE e Unlayer il prezzo non è indicato in questa pagina. Chiedi un preventivo al fornitore indicando il numero di utenti del team e il volume di invii previsto, e confronta le condizioni di esportazione e di uscita dalla piattaforma prima di firmare.

Tabella 2: costo per dimensione della lista

La tabella riporta solo i prezzi pubblicati nelle pagine dei fornitori. Dove il prezzo non è pubblico, è scritto come tale. Gli importi annuali sono calcolati come dodici volte il prezzo mensile.

Il dato più utile non è il prezzo di partenza ma il punto in cui il costo sale. Con Customer.io ogni fascia di 10.000 profili aggiunge 90 $ al mese. Se una lista da 20.000 profili arrivasse a 30.000, il costo mensile passerebbe da 235 $ a 325 $, cioè 1.080 $ in più all'anno (12 × 90 $). Conviene calcolare la fascia futura prima di firmare un contratto.

Come scegliere: tabella decisionale

La scelta dipende da chi scrive i template, da quanto spesso cambiano le sequenze e da quanti profili hai. La tabella riassume le combinazioni più comuni.

Una regola pratica: se esiti tra motore e builder, parti dal motore. Il layout si può ricostruire con meno danni, mentre le regole di invio e lo storico dei profili sono più difficili da spostare.

Flusso di lavoro: dal template all'automazione

Un buon flusso separa il layout dal contenuto. Il layout (intestazione, colonne, footer, stili) si costruisce una volta sola nel builder scelto. Il contenuto (oggetto, testo, CTA, condizione di invio) vive nel motore di automazione, dove può cambiare senza generare una nuova versione del template.

Parti da una mappa scritta della sequenza. Per ogni messaggio annota l'obiettivo, l'evento o il ritardo che lo fa partire, l'azione che ti aspetti dall'utente e l'evento che lo ferma. Con più di due rami il motore visivo conta più del template, perché una condizione sbagliata fa più danni di un colore sbagliato.

Costruisci poi un set minimo di blocchi: intestazione, corpo a una colonna, pulsante CTA, firma e footer con disiscrizione. Ogni nuovo messaggio riusa questi blocchi. Quando un blocco cambia, la modifica deve arrivare a tutti i messaggi che lo usano, altrimenti dopo due mesi la firma avrà versioni diverse in ogni email.

Infine documenta ogni variabile: il nome del campo nel profilo, il formato atteso e il testo di ripiego. Una variabile senza ripiego è la causa più comune di messaggi con spazi vuoti.

Tabella 3: checklist di setup e migrazione

Se stai spostando una sequenza esistente da un altro strumento, o se stai avviando la prima, segui questi passaggi nell'ordine indicato.

Errori comuni nei template di onboarding

Il primo è avere più CTA nella stessa email. Con tre pulsanti verso destinazioni diverse l'utente spesso non ne sceglie nessuno. Una email, un'azione.

Il secondo è il testo alternativo mancante. Se l'immagine con la schermata del prodotto è disattivata, il messaggio perde il proprio argomento principale. Il testo alternativo deve descrivere l'azione mostrata, non limitarsi a dire che si tratta di un'immagine.

Il terzo è dimenticare la versione in testo semplice. Controlla che il motore di invio ne produca una, o che il builder la esporti insieme all'HTML, perché alcuni client la usano quando il codice principale non viene mostrato correttamente.

Il quarto è una colonna troppo larga per il telefono. Un blocco di 600 pixel che sullo schermo stretto si spezza in due colonne rende il pulsante difficile da toccare e il messaggio difficile da leggere.

Il quinto è inventare scadenze. Un messaggio sulla fine del trial deve riportare la data reale presa dal profilo. Se il dato manca, il messaggio non deve contenerlo.

Controlli prima dell'invio

Prima di attivare una sequenza fai una verifica in tre passaggi. Primo: invia ogni messaggio a un account di prova e controlla variabili, link e disiscrizione. Secondo: attiva il workflow con un utente per ramo e verifica che i tempi siano quelli previsti. Terzo: osserva i primi invii reali per qualche giorno, con attenzione a rimbalzi, reclami e disiscrizioni, e correggi per primo il messaggio che genera più problemi.

Per partire non servono metriche sofisticate. Bastano tre misure legate all'azione: quanti utenti completano l'azione chiave entro il trial, quanti passano da trial a pagamento e quanto tempo passa dall'iscrizione al primo valore. Le aperture aiutano a capire se l'oggetto è leggibile, ma non dicono se la sequenza porta le persone dove vuoi.

Mantenere la sequenza nel tempo

Rivedi la sequenza ogni trimestre. Guarda quale messaggio fa perdere più utenti, quale ramo viene scelto più spesso e quale CTA riceve meno clic. Cambia una variabile alla volta, altrimenti non saprai quale modifica ha avuto effetto.

Tieni un registro delle versioni con data, cambiamento e motivo. Con un editor visuale il registro va tenuto a mano; con i framework da codice è già nella cronologia del repository. In entrambi i casi evita di rifare dopo sei mesi una modifica che era già stata scartata.