Campagne Email
Aggiornato 2026

Beta di un’app o di un software: come scrivere ai tester senza perderli

Un programma beta ha pochi destinatari e molte occasioni di scrivere: l’invito, il link alla versione di prova, il promemoria del primo uso, la richiesta di un parere dopo ogni novità. Qui, a differenza di quasi tutte le altre attività, l’email nasce da eventi dell’app, come registrazione, prima azione completata o nessun accesso da una settimana. Per questo Loops è il punto di partenza naturale per una startup software: riceve gli eventi del prodotto e fa partire i messaggi. È uno strumento in inglese e va valutato per dati e contratto. Prima di invitare chiarisci l’accordo di riservatezza.

Strumenti consigliati

01

Loops

Loops è la scelta più coerente per una beta di un prodotto software, perché riceve eventi dall’app (registrazione, funzione provata, ultimo accesso) e li trasforma in messaggi, con un costo che resta basso con pochi tester. Secondo loops.so/pricing il piano gratuito ammette fino a 4.000 invii in 30 giorni verso i 1.000 contatti più recenti, con una dicitura «Powered by Loops» nelle email. Il limite: interfaccia e assistenza in inglese, e prima di inviare dati dei tester serve un accordo di trattamento (DPA) e la verifica di dove risiedono i dati.

Scelta migliore

loops.so

02

ActiveCampaign

Se la beta ha più fasi (chiusa, aperta, anteprima per i clienti) e ogni gruppo di tester riceve istruzioni diverse, i campi e le automazioni condizionali di ActiveCampaign tengono ordine. Non offre un piano gratuito e, secondo activecampaign.com/pricing, il livello d’ingresso limita le azioni per automazione. Lavora bene sui contatti ma riceve gli eventi dell’app solo se li colleghi tu, con un connettore, un servizio di collegamento o una chiamata alle sue interfacce.

Ideale per beta a fasi con coorti diverse

activecampaign.com

03

Mailchimp

Se i tester sono qualche decina e il lavoro è soprattutto manuale (un invito, due aggiornamenti, un questionario), Mailchimp basta e il piano gratuito, secondo mailchimp.com/pricing, ammette 250 contatti e 500 invii al mese. Non reagisce a ciò che fanno i tester dentro l’app: i messaggi legati agli eventi richiedono altri strumenti o un collegamento da sviluppare.

Ideale per una beta con pochi tester e poco tempo

mailchimp.com

04

Customer.io

Customer.io è pensato per team di prodotto che hanno già eventi, attributi e più canali (email, push, messaggi nell’app). Secondo customer.io/pricing il livello Essentials costa, per 5.000 profili, 100 $ al mese; il piano gratuito non esiste, ma c’è un programma per startup eleggibili. È più strumento di quanto serva a una beta di poche decine di tester, e richiede uno sviluppatore per integrarlo.

Ideale per un prodotto con molti eventi e dati

customer.io

05

Drip

Drip è il nome dello strumento: nato per negozi online, segue visite, carrelli e ordini. Ha senso se la beta riguarda una funzione del tuo negozio, come un nuovo checkout o un programma fedeltà, e vuoi vedere chi compra. Secondo drip.com/pricing offre 14 giorni di prova e nessun piano gratuito; per testare un’app mobile o un software gestionale non è la scelta più naturale.

Ideale per una beta di un’app di e-commerce

drip.com

06

HubSpot

Se i tester sono aziende clienti o potenziali clienti e ogni feedback si lega a una trattativa, HubSpot tiene insieme scheda, referente e storico dei messaggi. Le pagine americane su hubspot.com/pricing/marketing mostrano un forte divario tra i livelli e un tetto di azioni per le automazioni nei piani bassi. Per una beta consumer con molti tester è eccessivo.

Ideale per beta con clienti aziendali

hubspot.com

07

Brevo

Brevo manda email e SMS dallo stesso account e può essere utile quando la beta coinvolge anche persone che rispondono meglio a un messaggio sul telefono. Il piano gratuito, secondo brevo.com/pricing, ammette 300 email al giorno e automazioni fino a 2.000 contatti. Ricorda che l’SMS vuole un consenso a parte e si paga a messaggio.

Ideale per tester anche via SMS

brevo.com

Cosa valutare prima di scegliere

Invito, accesso alla versione di prova e prima settimana

L’invito deve contenere tutto ciò che serve per cominciare: che cosa si testa, quanto tempo richiede, come installare la versione di prova e chi contattare. Per le app mobili la distribuzione passa di solito da TestFlight di Apple o dai test chiusi di Google Play: spiega i passaggi con schermate, perché gran parte dei tester si ferma lì. Controlla che lo strumento permetta una breve sequenza per i primi sette giorni, con un promemoria a chi non ha ancora aperto l’app.

Messaggi attivati dagli eventi dell’app

Il vero vantaggio di una beta software è sapere che cosa fa il tester: ha completato la registrazione, ha provato la funzione nuova, non entra da cinque giorni. Chiedi se lo strumento riceve eventi dal tuo prodotto e come: un connettore, una libreria per gli sviluppatori o un file importato a mano. Concorda con chi sviluppa quali eventi inviare e per quanto tempo conservarli: raccogli solo quelli che userai per scrivere un messaggio.

Richieste di feedback brevi e specifiche

Un questionario di venti domande a fine beta non serve a nulla. Meglio una domanda sola dopo ogni funzione provata, con una risposta da cliccare e un campo libero opzionale. Verifica che lo strumento consenta di mandare il messaggio dopo l’evento e non a una data fissa, e che le risposte si salvino sulla scheda del tester. Per i moduli di raccolta più lunghi puoi usare un servizio dedicato, ma controlla dove finiscono i dati e chi può leggerli.

Riservatezza e accordo con i tester

Una beta spesso mostra funzioni non ancora pubbliche. Se vuoi che restino riservate, un accordo di riservatezza firmato dal tester è lo strumento giusto, e un messaggio email non lo sostituisce: fallo scrivere o rivedere da un legale. Nell’email, ricorda in una riga le regole (niente schermate sui social, niente condivisione del link) e conserva la prova dell’accettazione. Lo strumento email serve a ricordare, non a far valere il patto.

Dati dei tester e fornitore straniero

Molti strumenti pensati per prodotti software sono di aziende fuori dall’Unione. Prima di caricare nomi, indirizzi ed eventi dei tester chiedi un accordo di trattamento (DPA), dove sono conservati i dati e quali garanzie esistono per il trasferimento. Scrivi nell’informativa della beta quali dati raccogli e perché. Se i tester sono minorenni o l’app tocca la salute, le regole sono più rigorose: parlane con il tuo DPO prima di raccogliere qualcosa.

Costo che sale con gli eventi e i profili

Con una beta i contatti sono pochi ma i dati possono essere tanti. Controlla se paghi per profili, per invii o per eventi, se esiste un piano gratuito che copra la fase di prova e che cosa succede quando passi al pubblico: un prodotto che arriva a migliaia di utenti cambia fascia di prezzo da un mese all’altro. Verifica anche se il piano gratuito inserisce una dicitura del fornitore nelle email, e se ti va bene mostrarla ai tester.

Per approfondire

Domande frequenti

Come trovo tester che usano davvero la beta?

Parti da chi ha già un problema che il tuo prodotto risolve: clienti attuali, iscritti alla lista d’attesa, una community di settore. Scrivi un invito che dica quanto tempo serve alla settimana, per quante settimane e che cosa ricevono in cambio. Fai compilare un breve modulo con il caso d’uso e seleziona tu: meglio venti persone che lo useranno che duecento curiosi. Chi si candida deve poter scegliere se ricevere solo messaggi sulla beta o anche altre comunicazioni.

Che cosa metto nell’email di benvenuto a un tester?

Entro poche ore dall’accettazione: un ringraziamento breve, il link per scaricare o accedere, tre passaggi numerati per la prima prova, dove segnalare un problema e a chi rispondere. Aggiungi la durata prevista della beta e che cosa succederà alla fine, per esempio un accesso gratuito per un periodo o uno sconto di partenza, solo se lo hai deciso. Richiama in una riga l’accordo di riservatezza. Evita un messaggio lungo: chi non riesce a cominciare in cinque minuti spesso non comincia più.

Ogni quanto scrivo ai tester durante la beta?

Dipende dal ritmo delle versioni: un messaggio per ogni build o funzione nuova da provare, più un riepilogo settimanale breve con ciò che hai corretto in base ai loro commenti. Se non c’è nulla di nuovo, non scrivere per riempire. La cosa che i tester ricordano di più è la risposta ai problemi che hanno segnalato, più delle newsletter. Lascia un modo semplice per sospendere i messaggi senza uscire dalla beta, per chi ha una settimana piena.

Come rendo semplice lasciare un parere?

Una domanda precisa per volta: «Sei riuscito a completare il pagamento?» con tre risposte da cliccare e uno spazio per spiegare. Mandala subito dopo l’evento, quando il ricordo è fresco, e permetti di rispondere direttamente al messaggio. Ringrazia entro il giorno e, quando correggi qualcosa, scrivi a chi lo aveva segnalato. Tieni un solo canale principale per le segnalazioni: se i commenti arrivano in email, in chat e nell’app, finisci per perderne metà.

Posso premiare chi partecipa alla beta?

Sì, con attenzione. Un accesso gratuito per un periodo, uno sconto alla partenza o un nome nei ringraziamenti sono scelte comuni e semplici. Se invece prometti premi assegnati per estrazione o per classifica, in Italia entra la normativa su concorsi e operazioni a premio: controllala o chiedi a un consulente prima di annunciarli. Se il compenso è in denaro, ha un trattamento fiscale e contrattuale proprio. Scrivi nelle condizioni della beta che cosa ricevono i tester e a quali requisiti.

Come rispondo a un tester che critica il prodotto?

Ringrazia, ripeti con parole tue ciò che hai capito e di’ che cosa farai, anche se è «non lo cambieremo, ecco perché». Una risposta scritta da una persona, non da un modello automatico, conta più del contenuto. Quando il problema è risolto, scrivi a chi lo aveva segnalato prima che compaia nelle note di versione. Non discutere in pubblico e non chiedere di togliere una recensione negativa: un tester arrabbiato che si sente ascoltato continua a usare il prodotto più di uno che non ha mai criticato.

Come divido i tester in gruppi?

Con tre dati semplici, raccolti nel modulo di candidatura: dispositivo o sistema usato, ruolo (privato o azienda) e la funzione che gli interessa di più. Aggiungi lo stato della beta: invitato, attivo, silenzioso. Con questi campi mandi la build per Android solo a chi ha Android e le domande sul modulo di fatturazione solo a chi lo usa. Non servono dieci gruppi: con meno di cento tester tre o quattro bastano e restano gestibili senza strumenti complicati.

Che cosa scrivo ai tester quando la beta sta per finire?

Dì con anticipo che cosa succede: la data di chiusura, se l’accesso resta aperto, quale prezzo o condizione avranno e che cosa cambia nei dati salvati durante la prova. Se i dati dei tester verranno cancellati o conservati, indicalo con precisione, perché è una scelta che riguarda la loro privacy. Ringrazia con un messaggio personale e, se hai il loro permesso, cita chi ha contribuito. Per chi vuole restare, un passaggio chiaro al prodotto vero; per chi no, un modo semplice di uscire.

Che cosa faccio se i tester smettono di usare l’app?

Guarda prima i dati: l’ultimo accesso dice più di un questionario. A chi non entra da una settimana manda un messaggio semplice, con una domanda aperta: che cosa ti ha fermato? Spesso è un problema di installazione o di tempo, non di interesse. Se due messaggi non ricevono risposta, lascia stare e sostituisci quel posto con un altro candidato, scrivendo a chi era in attesa. Non usare lo strumento per insistere: un tester stanco non dà feedback utile, anche se continua a ricevere inviti.

Come capisco se la beta ha prodotto risultati?

Conta quanti tester hanno completato l’azione che per il tuo prodotto significa «ha funzionato», per esempio un primo documento creato o un primo ordine inserito. Poi guarda quanti problemi segnalati sono stati corretti e quanti tester sono rimasti dopo il periodo di prova. Mettiti una domanda prima di cominciare: che cosa dovrei scoprire per dire che la beta è servita? Se alla fine non sai rispondere, i messaggi sono stati solo un modo di tenere occupati i tester.