Finanza agevolata: CRM e foglio allineati nei due sensi, email su Brevo con i consensi in ordine

Il contesto

Il cliente è una società di finanza agevolata: segue imprese che partecipano a bandi e chiedono contributi pubblici. Ha un team piccolo e circa 1.600 commesse, ognuna con le sue scadenze, i suoi stati e i suoi documenti.

Le opportunità vivevano nel CRM, TeamLeader. Il team però lavorava ogni giorno su un foglio di calcolo di monitoraggio delle commesse, più comodo per filtrare, ordinare e aggiornare molte righe insieme. L'email marketing partiva da una piattaforma collegata al CRM.

Il problema

All'avvio, a luglio 2026, le opportunità nel CRM erano 1.603, e lo stesso elenco esisteva nel foglio con dati diversi. I due strumenti si allineavano a mano, quando qualcuno ci pensava. L'analisi iniziale ha trovato circa 111 opportunità con più stati scritti nella stessa cella, 189 senza stato e circa 300 da bonificare. Con dati così, un report o una lista di invio non sono affidabili.

Il 21 luglio 2026 il problema è diventato visibile anche fuori: la piattaforma email ha bloccato una campagna e sospeso gli invii a un pubblico di circa 4.400 iscritti, perché il consenso dei contatti sincronizzati dal CRM non era verificabile. Due problemi in apparenza diversi, con la stessa radice: dati che passavano da un sistema all'altro senza una regola.

Cosa ho costruito

Ho lavorato in due tempi, sull'account Make del cliente. Prima l'allineamento fra CRM e foglio, poi il passaggio dell'email marketing a Brevo con i consensi in ordine.

CRM e foglio allineati nei due sensi

1. Una chiave unica. Ogni riga del foglio e ogni opportunità del CRM si riconoscono dal numero di contratto. Prima di partire ho verificato che fosse univoco su tutte le 1.603 opportunità.
2. Dal CRM al foglio, in tempo reale. Quando un'opportunità cambia nel CRM, un webhook avvisa Make, che aggiorna la riga corrispondente nel foglio.
3. Dal foglio al CRM, a pulsante. Uno script nel foglio segna le righe modificate. Quando il team ha finito, preme un pulsante e le modifiche partono verso il CRM in un unico lotto.
4. Niente eco. Senza una protezione, un aggiornamento dal foglio cambierebbe il CRM, il CRM avviserebbe Make e Make riscriverebbe il foglio, in un giro senza fine. Lo scenario che scrive nel CRM lascia un segnale in un archivio di Make; l'altro scenario lo trova, lo consuma e si ferma.
5. Cancellazioni e contabilità. Uno scenario a parte gestisce le opportunità cancellate, e i dati contabili stanno in un foglio separato.

Due scelte meritano una spiegazione. Il pulsante, invece della sincronizzazione automatica anche dal foglio, lascia al team il controllo: chi corregge cinquanta righe di seguito non vuole cinquanta chiamate al CRM mentre lavora, e decide lui quando le modifiche sono pronte. E lo script prepara già il contenuto della chiamata, così Make la spedisce con un solo modulo: meno moduli vuol dire meno operazioni consumate a ogni lotto, e quindi un costo mensile più basso.

Sul collaudo ho una regola: ogni prova parte da un valore diverso da quello atteso. Una risposta “200, tutto ok” dice che la chiamata è arrivata, non che il dato giusto sia finito nel posto giusto; l'unico modo di saperlo è vedere il valore cambiare. Ho dovuto sistemare anche un difetto piccolo ma fastidioso, segnalato dal titolare con un video: la colonna del numero di contratto ordinava i valori come testo, così il 530 finiva accanto al 53. La formula che crea il collegamento al CRM restituiva una stringa; l'ho corretta perché restituisca un numero.

L'email marketing su Brevo, con i consensi in ordine

1. Account e dominio. Ho aperto un account Brevo intestato al cliente e autenticato il suo dominio di invio.
2. Censimento dei consensi. Nel CRM ogni contatto ha ora registrata la base giuridica su cui può ricevere email.
3. Tre liste. Consenso al marketing, relazione commerciale in corso, quarantena per chi non ha una base chiara. Chi è in quarantena non riceve nulla.
4. Sincronizzazione. Make porta i contatti dal CRM a Brevo, ciascuno nella sua lista.
5. Riscaldamento. Prima di scrivere a tutti, otto campagne piccole e settoriali fra il 31 agosto e il 14 settembre 2026, per costruire la reputazione del nuovo mittente.

I risultati

La sincronizzazione regge. All'8 agosto 2026 lo scenario dal CRM al foglio risultava con 2.504 esecuzioni e 3 errori, quello dal foglio al CRM con 42 esecuzioni e 1 errore. Sono numeri di affidabilità: dicono che il sistema funziona, non quanto tempo fa risparmiare.

Su Brevo, dieci campagne fra il 31 agosto e il 16 ottobre 2026 hanno spedito 835 email: 771 consegnate (92,3%), 362 aperture uniche (47,0% delle consegnate), 29 clic unici (3,8%), 4 disiscrizioni e nessun reclamo per spam. Il dato di apertura che uso è il più prudente: 33,3%, escluse le aperture automatiche dei programmi di posta che scaricano le immagini da soli.

Il dato sfavorevole va detto. Gli indirizzi inesistenti (hard bounce) sono stati 50, il 6,0% degli invii, tre volte la soglia del 2% oltre la quale i provider cominciano a diffidare di un mittente. Nel riscaldamento, su contatti già presenti nel CRM, erano il 5,0%: la base conteneva indirizzi non più validi che nessuno aveva mai pulito. Nella campagna del 16 ottobre sono saliti al 10,0%, perché la lista veniva da una fonte esterna di aziende e non era stata verificata prima dell'invio.

Cosa rifarei diversamente

C'era una regola di stop scritta: se una campagna supera la soglia di indirizzi inesistenti, ci si ferma e si pulisce la lista. Non ha funzionato. Dopo una campagna del riscaldamento al 6,06% ne sono partite altre tre, già programmate. Non è stata una distrazione di qualcuno: la regola esisteva solo sulla carta, e una campagna programmata parte da sola. La lezione che mi sono annotato è che una regola di stop esiste solo se il blocco successivo richiede un gesto per partire. Dopo il 10% del 16 ottobre se n'è aggiunta un'altra: nessun invio a contatti presi da fonti esterne senza una verifica degli indirizzi.

Il secondo errore riguarda i costi di Make. Intorno all'11 settembre un aggiornamento di massa e i tentativi ripetuti dopo gli errori hanno consumato circa 14.700 operazioni in un giorno solo, il 69% delle 21.303 contate in 48 esecuzioni. Ho ridotto la finestra di lavoro dello scenario da 48 a 26 ore, ma il risparmio non l'ho ancora misurato. Oggi metterei da subito un limite ai tentativi ripetuti e un avviso sui consumi anomali, prima che il conto arrivi a fine mese.

Per chi ha senso

Ha senso per studi e società di servizi che hanno un CRM ma lavorano davvero su un foglio di calcolo, e non vogliono rinunciare a nessuno dei due: consulenti, studi tecnici, società che gestiscono pratiche con molti stati. Ha senso anche per chi ha avuto un blocco della piattaforma email e deve ripartire con i consensi documentati. Il confronto fra gli strumenti che ho usato è nella guida su Make o n8n.

Non serve se il team usa già solo il CRM, o se le pratiche sono poche decine: in quel caso basta decidere quale strumento comanda e smettere di usare l'altro.

Strumenti usati

MakeTeamLeaderGoogle SheetsGoogle Apps ScriptBrevo

Numeri letti dal CRM e dal registro degli scenari di automazione (8 agosto 2026) e dalle statistiche dell'account email del cliente il 25 ottobre 2026, senza modificarli.