# Sequenza email per convertire le prove SaaS con gli eventi di prodotto

URL canonico: https://brew.new/it/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Autore: Thomas Park
Pubblicato: 2026-09-26
Aggiornato: 2026-09-29

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

| Messaggio | Quando è utile | Idoneità verificata al momento dell’invio |
| --- | --- | --- |
| Benvenuto | Dopo la registrazione o la verifica | L’account esiste e può ricevere questo messaggio |
| Aiuto con la configurazione | Circa due giorni dopo, da adattare al tuo prodotto | Non ha completato l’attivazione |
| Prossima azione utile | Dopo l’attivazione | Ha completato l’attivazione ma non quell’azione |
| Fine della prova | Prima della scadenza effettiva della prova | La prova è ancora attiva e l’account non è a pagamento |
| Ultimo follow-up | Dopo la fine della prova, se opportuno | Ancora non pagante, idoneo e autorizzato a ricevere email di marketing |

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ì:

```text
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](https://docs.brew.new/create-emails/build-an-automation) e la documentazione sui [contratti tipizzati del payload](https://docs.brew.new/api-reference/guides/typed-payload-contracts). 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](/it/browse/integrations/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](/it/blog/welcome-email-sequence) per gli esempi e [MCP o API REST](/it/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) per come dividere il lavoro di implementazione.