Come chiedere feedback ai clienti in un prodotto software
7 min di lettura
Per chiedere feedback ai clienti in un prodotto software, fai una domanda specifica su qualcosa che l’utente ha appena fatto, nel punto in cui l’ha fatto. “Com’è andata l’esportazione di quel report?” subito dopo un export ottiene una risposta. “Dicci cosa pensi del nostro prodotto” in un footer ottiene silenzio. Il resto di questa pagina sono i momenti, i canali e le formulazioni esatte.
La maggior parte dei consigli su questo tema è scritta per negozi e sportelli di assistenza. Un team software sa esattamente cosa ha fatto l’utente un secondo fa, quindi la domanda può riguardare quello.
| Momento | Dove chiedere | Domanda pronta all’uso |
|---|---|---|
| Subito dopo che un’attività finisce | Nell’app, accanto al risultato | “Quell’export ha fatto quello che ti serviva?” |
| Dopo il primo uso di una nuova funzionalità | Nell’app, una sola volta | “Cosa stavi cercando di fare con Bulk Edit?” |
| Dopo la risoluzione di un ticket di supporto | Nel thread di supporto | “Ha risolto, o c’è ancora qualcosa che non va?” |
| Dopo che un utente si ferma o abbandona un flusso | Email, un giorno dopo | “Ti sei fermato al passo 3 della configurazione. Cosa ti ha bloccato?” |
| Dopo 30 giorni di uso regolare | Email da una persona con nome e cognome | “Qual è l’unica cosa che cambieresti?” |
| Quando un utente disdice | Nel flusso di disdetta | “Cosa ti ha fatto decidere di andare via oggi?” |
| Dopo aver rilasciato qualcosa che avevano chiesto | Dove l’avevano chiesto | “Avevi chiesto l’import CSV. È online. Copre il tuo caso?” |
Qual è il momento giusto per chiedere feedback?
Il momento giusto è subito dopo che l’utente ha finito qualcosa, mentre i dettagli sono ancora freschi. Una domanda che segue un’azione ottiene una risposta su quell’azione. Una domanda che arriva dal nulla ottiene una risposta sull’umore della persona in quel momento, oppure nessuna.
Non chiedere alla registrazione, perché nessuno ha ancora usato niente. Non chiedere nel mezzo di un’attività, perché interrompi proprio ciò che vuoi capire. Quando una persona ha risposto, lasciala in pace finché non hai qualcosa da comunicarle.
Dove si dovrebbe chiedere feedback ai clienti?
Chiedi nel posto in cui è avvenuta l’esperienza. Una richiesta nell’app va bene per una domanda su una schermata. Il thread di supporto va bene per una domanda su una correzione. L’email va bene per una domanda su una settimana di uso, o su un flusso che la persona ha abbandonato. Una chiamata va bene per le domande che non puoi prevedere.
Ogni canale dà un tipo diverso di risposta:
- Nell’app: risposte brevi, immediate e specifiche, ma solo da chi è presente. Da chi se n’è andato non senti nulla.
- Thread di supporto: da persone già abbastanza frustrate da scrivere. Ottimo per trovare cose rotte, scarso per giudicare il resto del prodotto.
- Email: risposte più lunghe da meno persone, e l’unico modo per raggiungere gli utenti che si sono fatti silenziosi. Scrivila come una breve nota da una persona con un nome, con una sola domanda dentro.
- Intervista: il modo per capire perché le persone fanno ciò che fanno. Chiedi loro di mostrarti come lavorano, e stai zitto mentre lo fanno.
Qualità del segnale nel feedback spiega come valutare ciò che ogni canale ti dice.
Come si chiede un feedback in modo professionale?
Sii specifico sull’oggetto, spiega perché lo chiedi e fai in modo che rispondere costi meno di un minuto. Una richiesta professionale nomina il momento, chiarisce che una persona leggerà la risposta e non si scusa per l’interruzione.
Nomina l’azione esatta (“l’export che hai appena lanciato”), chiedi una cosa sola, usa una casella di testo libero senza campi obbligatori e firma con un nome di battesimo.
Qual è una buona frase per chiedere un feedback?
Una buona frase è una domanda su un momento specifico a cui si può rispondere in poche parole. Confronta le due colonne qui sotto. Quelle a sinistra si possono liquidare con una scrollata di spalle. Quelle a destra obbligano la persona a ricordare qualcosa di reale.
| Richiesta debole | Richiesta più forte |
|---|---|
| “Feedback?” | “Qual è stata la parte più difficile della configurazione?” |
| “Ti piace il nostro prodotto?” | “Per cosa l’hai usato la settimana scorsa?” |
| “Valuta la tua esperienza da 1 a 10.” | “Oggi sei riuscito a fare quello per cui eri venuto?” |
| “Dicci come possiamo migliorare.” | “Qual è una cosa che ti ha rallentato questa settimana?” |
| “Ci consiglieresti?” | “A chi l’hai mostrato l’ultima volta, e cosa hai detto?” |
Un’altra che funziona quasi ovunque: “Cosa usi al posto nostro quando questo non fa per te?” Fa emergere il vero concorrente, che spesso è un foglio di calcolo.
Quali sono i modi peggiori di chiedere feedback?
Le richieste peggiori sono generiche, premature, lunghe o tendenziose. Hanno un problema in comune: la persona non può rispondere senza fare il lavoro di riflessione che avresti dovuto fare tu.
- “Compila il nostro sondaggio di 20 domande.” Chi arriva in fondo è chi ha più tempo libero o le opinioni più forti.
- Un popup nella prima pagina dopo il login. L’utente era venuto per fare qualcosa e glielo hai impedito. Chiuderlo è l’unica risposta sensata.
- “Ci farebbe piacere il tuo feedback!” senza nessuna domanda. Chiede all’utente di inventarsi l’argomento.
- Una domanda tendenziosa: “Quanto ami la nuova dashboard?” Ottieni un sì e non impari niente.
- Una valutazione senza seguito. Un 6 su 10 ti dice l’umore. Non ti dice cosa cambiare.
- Chiedere e poi tacere. Ti costa il giro successivo, come spieghiamo più avanti.
Come si chiama il feedback dei clienti su un prodotto?
Il feedback su un prodotto si chiama di solito feedback di prodotto, e si divide in due tipi. Una segnalazione di bug dice che qualcosa non funziona come previsto. Una richiesta di funzionalità dice che manca qualcosa. La distinzione decide chi se ne occupa per primo, e richiesta di funzionalità o bug traccia quel confine. Un terzo tipo, gli elogi, vale la pena di conservarlo e citarlo con il permesso.
Un modulo di feedback che offre “Bug” e “Richiesta di funzionalità” come prima scelta fa questa prima smistata al posto tuo.
Cosa si fa con le risposte?
Metti ogni risposta dove il team già lavora, con le parole della persona intatte. Una riga di testo citato vale più del tuo riassunto. Etichettala per tipo e urgenza approssimativa, unisci i duplicati e decidi: costruirla, metterla da parte o rifiutarla.
Anche rifiutare è una risposta. “Non la costruiremo, ed ecco perché” mette fine all’attesa, e rifiutare le richieste di funzionalità ha delle formulazioni per farlo. Per l’infrastruttura, tracciare le richieste di funzionalità descrive come portare le richieste da cinque canali in un’unica lista. Se raccogli le richieste per iscritto, un template di richiesta di funzionalità le rende confrontabili.
Il widget di Changeloop registra ogni invio come un issue di GitHub, così il feedback finisce accanto al codice che lo risolverà. Con qualsiasi strumento la regola è la stessa: una lista, un responsabile, nessuna risposta dimenticata nella casella di qualcuno.
Perché dire alle persone cosa è stato rilasciato?
Mostra alla persona che rispondere è valsa il suo tempo. Un utente che ti ha detto qualcosa e poi sente “è stato rilasciato, grazie” ha un motivo per rispondere ancora. Chi non sente niente conclude che la casella non viene letta.
Quindi l’ultimo passo del chiedere è una risposta. Di’ a ciascuno che ha chiesto quando la sua richiesta viene rilasciata, con le sue parole, sul canale che ha usato. Chiudere il ciclo di feedback del cliente descrive il meccanismo: la voce di changelog pubblicata è ciò che fa partire il messaggio, così chi ha chiesto viene avvisato solo quando la modifica è online. In Changeloop, quando il feedback del widget è diventato un issue GitHub e la pull request unita lo chiude, approvare la voce pubblica un commento “Shipped” su quell’issue e mostra a chi l’ha inviata la voce nel widget; gli issue aperti a mano e i repository GitLab o Bitbucket non ricevono nessun commento. La nostra documentazione elenca la configurazione di widget e feed.
Una risposta può essere breve: “A marzo avevi chiesto l’import CSV. Oggi è online, ed ecco come funziona.” Ti regala anche la domanda successiva migliore: copre quello che ti serviva?
Un piano per cominciare
Scegli un momento dalla tabella in alto, quello in cui gli utenti più spesso riescono o rinunciano. Scrivi una domanda per quel momento, mettila in un solo canale e leggi ogni risposta per due settimane prima di aggiungere una seconda richiesta. Rispondi a chiunque ti abbia dato qualcosa di concreto.
FAQ
Con che frequenza si dovrebbe chiedere feedback ai clienti? Lega le richieste agli eventi, non al calendario. Un utente dovrebbe vedere al massimo una richiesta a settimana, e nessuna subito dopo averne risposto a una. Il messaggio successivo al feedback dovrebbe essere una risposta su cosa ne è stato.
Come si chiede feedback senza infastidire gli utenti? Chiedi dopo un’attività, mai nel mezzo, limitati a una domanda e rendi facile chiuderla. Rispetta una chiusura per qualche settimana.
Conviene offrire un incentivo per il feedback? Di solito non serve. Una domanda specifica e una risposta visibile pesano più di un buono regalo, e gli incentivi attirano chi vuole il premio. Tienili per le interviste, dove chiedi 20 minuti del tempo di qualcuno.
E se nessuno risponde? Restringi la domanda e avvicinala al momento, per esempio a una sola schermata, chiesta subito dopo averla usata. Se resta silenzio, scrivi direttamente a una manciata di utenti e usa quelle conversazioni per scrivere richieste migliori.
Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.