In breve
- Ai clienti non serve sapere come funziona. Serve sapere quanto costa, quanto tempo ci vuole, qual è il rischio e cosa cambia per loro.
- Mostra l'effetto sullo schermo, come la pagina lenta o il checkout che non funziona, invece di descriverlo.
- Un'analogia presa dal mondo del cliente aiuta; di' dove smette di funzionare.
- Proponi due o tre opzioni con costo, tempi e rischio, e consigliane una.
- Non mostrare mai codice che il cliente non ha chiesto, e mai credenziali.
Per spiegare le scelte tecniche ai clienti che non sono tecnici, parla di cosa cambia per loro, non di come funziona: quanto costa, quanto tempo ci vuole, cosa succede se non lo fai e cosa cambia per il loro team. Mostra il problema sullo schermo invece di descriverlo, proponi due o tre opzioni con i loro compromessi e consigliane una. Una breve registrazione dello schermo è un buon formato per farlo, perché il cliente vede con i suoi occhi la pagina lenta o il pulsante che non funziona.
Questa guida è pensata per sviluppatori freelance e team di agenzia che hanno bisogno di una decisione del cliente su qualcosa che il cliente non può valutare da solo.
Parla di risultati e compromessi
Al tuo cliente non interessano il framework, il database o il plugin. Gli interessano quattro cose:
- Il costo: quanto adesso, e quanto ogni mese dopo.
- I tempi: quanto ci vuole, e se il lancio si sposta.
- Il rischio: cosa succede se non lo facciamo.
- Il cambiamento: cosa cambia dopo per lui e per il suo team.
Traduci ogni punto tecnico in questi termini prima di spiegarlo:
| Cosa diresti a un collega | Cosa deve sentirsi dire il cliente |
|---|---|
| “Il plugin delle prenotazioni non è più mantenuto.” | “Il sistema di prenotazione non riceverà più aggiornamenti di sicurezza. Oggi funziona, ma ogni mese che resta lì il rischio aumenta.” |
| “Dovremmo aggiungere la cache.” | “Le pagine si caricheranno più in fretta. Quando modifichi una pagina, la modifica potrebbe metterci qualche minuto a comparire.” |
| “Passiamo a un CMS headless.” | “Più libertà nel design, ma due sistemi da mantenere invece di uno, e un costo mensile più alto.” |
| “C’è parecchio debito tecnico.” | “Le scorciatoie prese in passato rendono ogni nuova funzione più lenta e più cara da sviluppare.” |
Se una frase ha ancora bisogno di una parola tecnica per stare in piedi, spiega la parola una volta, di passaggio, e vai avanti.
Mostra, non descrivere
“La pagina è lenta da mobile” è un’opinione. Una registrazione della pagina che ci mette una vita a mostrare le foto dei prodotti in una finestra grande come un telefono è un fatto che il cliente può vedere. Il video è il modo più semplice per mostrare un problema tecnico a chi non è davanti al tuo schermo:
- Il problema come lo vede il cliente finale: il pulsante del checkout che su Safari non fa niente, il modulo che perde quello che hai scritto.
- Il prima e il dopo: la vecchia pagina e quella più veloce, affiancate.
- La schermata che userà: il pannello di amministrazione dopo la modifica, così “un nuovo editor” smette di essere astratto.
Mentre parli, cerchia la parte che conta. Disegnare sullo schermo durante la registrazione funziona bene; leggi come disegnare sullo schermo mentre registri su Mac.
Usa le analogie con attenzione
Una buona analogia presa dal mondo del cliente fa scattare la comprensione. Alcune che di solito funzionano:
- Manutenzione e aggiornamenti sono come il tagliando della macchina: se lo salti, la macchina va lo stesso, finché non si ferma.
- Il debito tecnico è come la cucina di un ristorante che non viene pulita tra un servizio e l’altro: ogni servizio è più lento del precedente.
- I backup sono come un’assicurazione, solo che conviene controllare che funzionino prima di averne bisogno.
Usane una per decisione, non una per frase. E di’ dove non regge: “a differenza di una macchina, una falla di sicurezza può essere sfruttata da qualcun altro prima che si noti qualcosa”. Un’analogia che nasconde un costo o un rischio è peggio di nessuna analogia.
Proponi opzioni con i loro costi
Quasi tutte le scelte tecniche hanno più di una risposta. Presentane due o tre, compreso il “non fare niente” quando è un’opzione reale, e mettile una accanto all’altra:
| Opzione | Tempi | Costo continuativo | Rischio |
|---|---|---|---|
| Lasciarlo com’è | Nessuno ora | Nessuno | Cresce ogni mese senza aggiornamenti |
| Sostituirlo con un plugin mantenuto | Circa due giorni | Una licenza annuale | Basso; le prenotazioni vengono trasferite |
| Sviluppare un modulo di prenotazione su misura | Circa due settimane | Il nostro tempo di manutenzione | Basso, ma c’è più da seguire |
Un esempio ipotetico: tempi e costi dipendono dal progetto.
Poi consigliane una e spiega perché, in una frase: “Noi lo sostituiremmo con il plugin mantenuto: due giorni di lavoro e il rischio sparisce.” I clienti decidono prima quando il ragionamento l’hai già fatto tu e a loro resta solo da dire sì. Per la parte economica, presentare un preventivo al cliente con un video segue lo stesso approccio.
Una struttura per la spiegazione
Che tu registri un video o scriva un’email, quest’ordine funziona:
- La decisione in una frase. “Dobbiamo decidere cosa fare con il sistema di prenotazione.”
- Perché adesso. Cosa succede se aspetti, nei suoi termini.
- Fallo vedere. Il problema sullo schermo, in trenta secondi o meno.
- Le opzioni, con tempi, costi e rischi.
- Il tuo consiglio e il motivo.
- La richiesta, con una data. “Mi fai sapere entro venerdì quale opzione preferisci?”
Scelta tecnica: un plugin non più mantenuto
Da sviluppatore freelance al cliente di una piccola attività · Circa 3 minuti
Ciao Giulia, mi serve una tua decisione sul sistema di prenotazione. Oggi non c’è niente di rotto, ma il plugin che lo fa funzionare non è più mantenuto, quindi non riceverà più aggiornamenti di sicurezza.
Questa è la pagina delle prenotazioni come la vedono i tuoi clienti. Le opzioni sono tre: lasciarlo così, che adesso non costa niente ma ogni mese diventa più rischioso; sostituirlo con un plugin mantenuto, circa due giorni di lavoro più una licenza annuale; oppure sviluppare un modulo nostro, circa due settimane. Io sceglierei la seconda: elimina il rischio e il tuo team non si accorgerà nemmeno del cambio. Mi fai sapere entro venerdì?
Mandalo con la richiesta anche per iscritto, così Giulia può rispondere dal telefono senza riguardare il video:
Cosa non mostrare
Una registrazione dello schermo per un cliente non è una code review. Lascia fuori:
- Il codice. A meno che il cliente non l’abbia chiesto, il codice comunica solo “è complicato”.
- Le credenziali. Password, chiavi API, file di ambiente, cronologia del terminale con dei token. Gli accessi mandali con un password manager, mai in un video.
- Log con dati dei clienti. I log degli errori contengono spesso nomi, email e dettagli degli ordini.
- Progetti di altri clienti. La barra laterale dell’editor e le schede del browser possono mostrarli.
- Le chat interne sul cliente o sul problema.
Quando spiegarlo dal vivo
Alcune scelte tecniche sono troppo grandi per un video da solo: un rifacimento, un cambio di piattaforma, qualsiasi cosa che sposti molto il budget. Manda il video come materiale da guardare prima, poi decidete in una breve call. Spieghiamo dove passa il confine tra le due cose in quando non mandare un video a un cliente.
E tieni da parte le spiegazioni per dopo. A fine progetto, lo stesso approccio diventa una buona consegna: i video di consegna del sito mostrano al cliente come funzionano le cose senza una sola riga di codice. La guida completa ai video asincroni per comunicare con i clienti mette tutto insieme, e la nostra pagina per i freelance mostra come JustRec si adatta a chi lavora da solo.
Domande frequenti
Come si spiega una scelta tecnica a un cliente non tecnico?
Parti da cosa cambia per lui: costi, tempi, rischi e lavoro di tutti i giorni. Mostra il problema sullo schermo, proponi due o tre opzioni con i loro compromessi, consigliane una e chiedi una decisione con una data.
Devo mostrare il codice a un cliente?
Quasi mai. A un cliente non tecnico il codice dice che qualcosa è complicato, non perché è importante. Mostra invece la pagina, l'errore o la schermata di amministrazione che userà.
Le analogie sono una buona idea per spiegare argomenti tecnici?
Sì, una alla volta e prese dal mondo del cliente. Di' dove l'analogia smette di funzionare, così non nasconde un costo o un rischio.
E se il cliente chiede i dettagli tecnici?
Daglieli, in breve, dopo il risultato. Alcuni clienti hanno un tecnico dalla loro parte che li vorrà; proponi una breve nota scritta per quella persona.
Le scelte tecniche vanno spiegate in video o in riunione?
Per la maggior parte delle decisioni basta un breve video, perché il cliente può vedere il problema e riguardare le opzioni. Per le scelte grandi o costose, manda prima il video e decidete in call.



