Mail ai clienti dal CRM: si invia con un clic, gli avvisi arrivano dopo

Scrivere ai clienti è una delle cose che facciamo più spesso, e una di quelle in cui è più facile perdere tempo. Per questo, quando abbiamo costruito il compositore delle mail dentro il nostro CRM, gli abbiamo chiesto due cose: proporre una bozza scritta con l'AI e controllare la qualità del testo prima che parta. La prima richiesta è andata liscia. La seconda ci ha costretti a una scelta di progetto che vale la pena raccontare, perché va contro l'istinto di chiunque costruisca strumenti: i controlli di qualità non fermano mai l'invio.

Cosa fa il compositore

Quando qualcuno del team deve scrivere a un cliente, il CRM propone una bozza. Non è una bozza uguale per tutti: il sistema impara lo stile di ciascuna persona del team. Chi scrive in modo asciutto riceve proposte asciutte, chi tende a essere più discorsivo le trova più distese. L'obiettivo è che la mail, una volta inviata, suoni come la persona che la firma e non come un modulo.

La seconda cosa che il compositore sa fare è ricordare. Per ogni cliente e per ogni immobile tiene traccia di cosa gli è già stato mandato. Sembra un dettaglio, ma è quello che evita la mail che ripete le stesse informazioni già spedite, o che ripresenta come novità qualcosa che il cliente conosce da tempo. Chi riceve una mail ripetitiva capisce subito che dall'altra parte nessuno si ricorda di lui. Con la memoria per immobile, la bozza parte da dove eravamo rimasti.

Poi c'è il controllo di qualità: il compositore rilegge il testo e segnala quello che, secondo lui, si potrebbe migliorare.

La decisione: il clic vince

La domanda vera era: cosa succede quando il controllo trova qualcosa che non gli piace? La risposta più ovvia, quella che viene in mente a chi scrive software, è fermare tutto finché il problema non è risolto. Un pulsante grigio, un messaggio rosso, «correggi prima di inviare».

La decisione del nostro responsabile è stata l'opposto. Si invia con un clic, sempre. Gli avvisi arrivano dopo, e arrivano come suggerimenti, non come ordini. Chi ha scritto la mail li legge, ne tiene conto per la prossima volta, oppure li ignora se pensa di avere ragione.

All'inizio la scelta può sembrare un passo indietro. Abbiamo uno strumento che sa riconoscere un testo migliorabile, e lo lasciamo partire lo stesso? Sì, e il motivo è più interessante della scelta in sé.

Perché un blocco di stile fa danni

Un sistema che blocca per ragioni di stile insegna alle persone ad aggirarlo. Funziona così con qualsiasi strumento: se il controllo si mette di traverso quando hai fretta e sei sicuro di quello che stai scrivendo, impari in fretta come farlo stare zitto. Riscrivi la frase in modo che passi, togli la parola che lo fa scattare, apri un altro programma e mandi la mail da lì. Il risultato è peggiore di prima: il testo non è migliorato, e in più hai imparato che il sistema è un ostacolo da scavalcare.

C'è poi un effetto meno visibile, e secondo noi più grave. Se tutto blocca, niente blocca davvero. Quando una persona si abitua a vedere il messaggio rosso per una virgola o per una frase troppo lunga, smette di distinguere tra un avviso che conta e uno che non conta. I blocchi veri perdono valore, perché vengono trattati con la stessa insofferenza di quelli inutili.

Un controllo di stile, per quanto ben fatto, resta un'opinione. Può avere ragione molte volte, ma non ha il contesto di chi conosce il cliente. E un'opinione non dovrebbe mai avere il potere di fermare il lavoro.

L'unico blocco che resta

Di tutti i blocchi possibili, ne è rimasto uno solo: il consenso revocato. A chi ha chiesto di non essere più contattato non si scrive. Qui il compositore non suggerisce e non avvisa dopo: semplicemente non lascia partire la mail.

La differenza con i controlli di qualità è netta. Lo stile è una questione di giudizio, e il giudizio spetta a chi scrive. Il rispetto di una richiesta esplicita del cliente non è una questione di giudizio. Non c'è una buona ragione per scrivere a qualcuno che ha chiesto di non ricevere più nostre mail, e non c'è fretta che lo giustifichi.

Proprio perché è l'unico, questo blocco ha un peso che non avrebbe in mezzo a dieci altri. Quando il compositore si ferma, chi sta scrivendo sa che non è un capriccio dello strumento. Non c'è niente da aggirare e nessuno ha la tentazione di farlo.

Avvisi dopo, non prima

Spostare gli avvisi a dopo l'invio cambia anche il modo in cui vengono letti. Prima dell'invio, un avviso è un intralcio: si legge con l'ansia di togliercelo di torno. Dopo, a mail partita, è un commento su qualcosa che abbiamo fatto, e si legge con più calma. È la differenza tra un collega che ti strappa il foglio di mano e uno che, a cose fatte, ti dice «la prossima volta proverei così».

Il compositore, insomma, fa il collega che rilegge, non il guardiano che decide. Le bozze aiutano a partire, la memoria evita le ripetizioni, gli avvisi aiutano a migliorare nel tempo. Nessuna di queste tre cose sta tra la persona e il pulsante di invio.

Cosa ci portiamo via

La lezione va oltre le mail, e la applichiamo ormai a ogni strumento che costruiamo:

• Separare le regole dai consigli. Una regola è qualcosa che non si fa mai, per nessun motivo. Un consiglio è qualcosa che di solito conviene fare. Mescolarli nello stesso meccanismo rovina entrambi.
• Tenere pochissimi blocchi. Ogni blocco in più toglie forza a quelli che contano. Se ne resta uno, tutti lo prendono sul serio.
• Non far pagare all'utente l'insicurezza dello strumento. Se il sistema non è certo di avere ragione, non deve comportarsi come se lo fosse.
• Fidarsi di chi scrive. Le persone del team conoscono i clienti meglio di qualsiasi controllo automatico. Lo strumento deve renderle più veloci e più attente, non sostituirne il giudizio.

Se state costruendo qualcosa di simile, la tentazione di mettere un controllo bloccante su tutto sarà forte, perché sembra la scelta più prudente. Nella nostra esperienza è il contrario: la prudenza vera sta nel decidere con cura le poche cose che non si devono mai fare, e lasciare libero tutto il resto.