Quando si parla di automazione dei processi aziendali, la conversazione tende a partire dagli strumenti. È l’ordine sbagliato.
Nella nostra esperienza, i progetti che funzionano partono sempre da una frase detta da qualcuno che fa quel lavoro tutti i giorni, e che suona più o meno così: “ogni mattina esporto questa cosa da qui e la incollo là”. Quella frase vale più di qualunque software di automazione, perché identifica un processo che esiste davvero, che qualcuno sta già pagando in ore di lavoro, e per cui esiste già un criterio di successo condiviso.
Maia Management
Manager senior a ore per la tua PMI.
IT Manager, Marketing Manager, CDO, Odoo, HubSpot. Solo professionisti senior — 0 junior nel team. Risposta entro 24h.
Raccontiamo quattro progetti che sono nati esattamente così. I nomi dei clienti sono omessi, i dettagli tecnici sono generalizzati, ma i problemi e le soluzioni sono quelli veri, inclusi gli errori che abbiamo fatto lungo la strada.
Caso 1: dal form del sito all’opportunità nel CRM, senza passaggi manuali
Il contesto. Un’azienda B2B con un sito ricco: sezione e-commerce, landing page per ogni linea di prodotto, versione italiana e inglese di ogni pagina. In tutto, più di dodici form di contatto attivi.
Il problema reale. Non era la mancanza di lead: quelli arrivavano. Era che arrivavano via email in una casella condivisa, e qualcuno doveva leggerli, capire da quale form venissero, cercare se l’azienda esistesse già nel gestionale, crearla se non c’era, creare il contatto, creare l’opportunità e assegnarla al commerciale giusto. Tra i venti e i quaranta minuti al giorno, con un tempo di reazione che nei fine settimana superava le quarantotto ore.
La complicazione che non ci aspettavamo. I dodici form erano stati costruiti in momenti diversi, da persone diverse. Il campo del nome si chiamava nome su alcuni, first_name su altri, e su un form della versione inglese lo stesso campo era stato riciclato per contenere un dato completamente diverso, gli ettari di terreno gestiti. Il campo della partita IVA a volte c’era e a volte no.
Il lavoro vero non è stato collegare i sistemi. È stato scrivere un normalizzatore che, per ogni form, sapesse tradurre il caos in ingresso in una struttura unica e prevedibile. Da lì in poi tutto è banale.
La soluzione. Webhook dal sito verso il motore di automazione, normalizzazione dei campi, poi in sequenza: ricerca dell’azienda per partita IVA, creazione se assente, creazione del contatto, creazione dell’opportunità, creazione di un’attività assegnata al commerciale competente con scadenza in giornata. I dettagli tecnici lato ERP, come filtri, follower e attività, li abbiamo raccolti nell’articolo su Odoo, n8n e JSON-RPC.
Due dettagli che hanno fatto la differenza:
La ricerca dell’azienda si fa solo sulla partita IVA, mai sul nome. Avevamo iniziato cercando anche per somiglianza sul nome, ed è stato un errore: “Rossi Srl” e “Rossi Costruzioni Srl” venivano associate alla stessa anagrafica. Meglio un duplicato da sistemare a mano che un’opportunità attaccata all’azienda sbagliata. E se non ci sono né nome né partita IVA, non si cerca affatto: una ricerca senza criteri restituisce il primo record del database, che è la peggiore risposta possibile.
L’utente tecnico dell’integrazione va rimosso dai follower. Quando un’automazione crea un’opportunità, l’utente con cui si autentica resta agganciato come osservatore e riceve tutte le notifiche di quella trattativa per sempre. Su decine di opportunità al mese diventa rumore che nasconde le notifiche vere.
Il risultato. Tempo di reazione passato da ore a secondi, ventiquattro ore su ventiquattro. Il commerciale trova l’attività già assegnata quando apre il gestionale la mattina.
Caso 2: notifiche automatiche ai clienti su un sistema legacy
Il contesto. Un’azienda di servizi con un sistema gestionale interno sviluppato in casa, in produzione da anni, che governa la pianificazione degli interventi presso i clienti.
Il problema. I clienti chiamavano il centralino per sapere se e quando sarebbe passato l’operatore. Ogni chiamata occupava una persona per qualche minuto, moltiplicato per decine di clienti al giorno.
Il vincolo. Il gestionale non si poteva riscrivere. Funzionava, conteneva anni di logica di business, e nessuno aveva intenzione di rimetterci mano.
La soluzione. Un processo che legge i dati degli interventi programmati e li invia al motore di automazione, che si occupa dell’invio: WhatsApp per chi ha un numero di cellulare, email per chi non ce l’ha. Sul rapporto tra WhatsApp e CRM, abbiamo scritto anche come tracciare la provenienza dei lead WhatsApp.
La distinzione tra fisso e cellulare non è un dettaglio: mandare un WhatsApp a un numero fisso è un messaggio perso in silenzio. Il riconoscimento si fa con una regex sul prefisso, con una segnalazione automatica al back office per i contatti che hanno solo il fisso, così qualcuno può chiedere il cellulare alla prossima occasione.
L’errore che abbiamo trovato in corsa. Il processo era pensato per girare una volta al giorno a orario fisso. Quando abbiamo aggiunto la possibilità di lanciarlo a richiesta, è emerso un bug latente: la query che estraeva gli interventi non escludeva quelli già notificati. Al secondo lancio della giornata, tutti i clienti già avvisati ricevevano un secondo messaggio identico.
È il tipo di problema che non si manifesta mai finché il processo gira una volta sola, e che esplode il giorno in cui cambi il modo di lanciarlo. Vale la pena dirlo esplicitamente: quando rendi manuale un processo automatico, ricontrolla tutte le assunzioni che l’automatismo nascondeva.
Una nota architetturale. Per il pulsante di lancio manuale abbiamo valutato tre strade: eseguire il processo direttamente dal backend web, costruire un servizio dedicato in ascolto, oppure far scattare dal backend un’attività pianificata già configurata sul server. Abbiamo scelto la terza, che è la meno elegante delle tre.
Il motivo è concreto: il processo schedulato girava già sotto un’utenza di sistema che aveva i permessi giusti e le credenziali configurate. Il backend web girava sotto un’identità diversa, priva di quelle credenziali. Lanciarlo da lì avrebbe funzionato per la parte database e si sarebbe rotto silenziosamente sull’invio delle email, comprese le email di notifica degli errori, che è il peggior modo possibile di rompersi.
La soluzione architetturalmente pulita, cioè estrarre la logica in un servizio condiviso richiamabile da entrambi i lati, resta l’obiettivo. Ma richiede un refactoring vero, e il cliente aveva bisogno del pulsante quella settimana. Segnalare la strada giusta e consegnare quella praticabile fa parte del lavoro, purché la si dica.
Caso 3: le trascrizioni delle chiamate che nessuno poteva usare
Il contesto. Un’azienda con centralino VoIP che trascriveva automaticamente le chiamate commerciali. Le trascrizioni arrivavano via email, una per chiamata.
Il problema. Erano tecnicamente disponibili e praticamente inutilizzabili. Cercare “tutte le chiamate del commerciale X di marzo” significava scorrere una casella di posta. Nessuna analisi aggregata, nessun collegamento al CRM.
La soluzione. Un workflow che intercetta le email, estrae i campi strutturati e li scrive su database relazionale: commerciale, numero chiamante, numero chiamato, data e ora della chiamata, testo della trascrizione.
Il dettaglio che ci ha fatto perdere mezza giornata. L’oggetto dell’email conteneva i due interlocutori, ma in ordine invertito a seconda della direzione della chiamata. In uscita era numero × nome commerciale, in entrata nome commerciale × numero. La prima versione dell’estrattore prendeva sempre il primo valore, e per metà delle chiamate salvava un numero di telefono nel campo del nome.
La soluzione non è distinguere la direzione della chiamata, che non era sempre desumibile: è una funzione che riconosce quale dei due valori è un numero di telefono e quale no. Robusta a prescindere dalla direzione.
Altri due inciampi, per chi dovesse ripercorrere la stessa strada. Il campo con i parametri della query veniva spezzato sulle virgole contenute dentro il testo della trascrizione, risolto passando un array JavaScript unico invece di una lista separata da virgole. E la colonna chiave primaria era stata creata come intero semplice, senza auto-incremento: ogni inserimento falliva con un errore di chiave duplicata poco leggibile.
Il risultato. Un archivio interrogabile. Da lì in avanti si può fare analisi delle obiezioni ricorrenti, verifica della qualità delle chiamate, ricerca full-text sulle conversazioni.
Caso 4: la dashboard che ha sostituito l’export manuale
Il contesto. Un’azienda che invia documenti da firmare ai clienti attraverso una piattaforma dedicata, e che gestisce le anagrafiche su un CRM separato.
Il problema. Per sapere quali documenti erano ancora in attesa di firma e chi contattare, bisognava incrociare a mano due sistemi: la lista dei documenti da una parte, l’anagrafica e il responsabile dall’altra. Un’ora abbondante alla settimana, e comunque una fotografia già vecchia nel momento in cui veniva prodotta.
La soluzione. Un microservizio web che ricostruisce la tabella in tempo reale interrogando entrambe le API, con autenticazione, cache e log degli accessi. Questo progetto lo abbiamo raccontato per intero nell’articolo sulla dashboard aziendale su misura.
Il problema tecnico interessante è stato il rate limit. Ogni riga della tabella richiede una chiamata di dettaglio sul documento più una lettura sul CRM. Con centinaia di documenti aperti, un caricamento ingenuo esaurisce la quota di chiamate in pochi secondi.
La prima versione aveva una cache che si svuotava a ogni cambio di filtro sulle date. Restringere il periodo da un mese a una settimana rigenerava tutte le chiamate, anche se quei dati erano appena stati scaricati.
La versione definitiva tiene traccia dell’intervallo già coperto. Se la richiesta cade dentro la copertura, i dati si filtrano in memoria senza toccare le API. Se la estende, si scaricano solo i giorni mancanti. La cache non si svuota mai per un cambio di date: solo su richiesta esplicita dell’utente o allo scadere di una durata di sicurezza.
Una precisazione che vale un paragrafo. La dashboard ha un pulsante di eliminazione dei documenti. Avevamo detto al cliente che l’eliminazione via API finiva in un archivio recuperabile. Era sbagliato: l’API cancella in modo definitivo, e il recupero passa solo dal supporto della piattaforma. Ce ne siamo accorti perché il cliente è andato a controllare l’archivio e non ha trovato nulla.
Il pulsante ora ha una doppia conferma, e la seconda dice esplicitamente che l’operazione è definitiva. Un’automazione che cancella dati deve essere più esplicita di quanto sembri necessario, perché chi la usa il centesimo giorno non ha in testa quello che gli è stato spiegato il primo.
Cosa hanno in comune questi quattro progetti
Nessuno ha richiesto di sostituire un sistema. In tutti e quattro i casi i software esistenti sono rimasti dove stavano: CRM, ERP, gestionale interno, piattaforma documentale, centralino. L’automazione ha costruito i collegamenti mancanti tra sistemi che avevano già i dati giusti nei posti sbagliati.
Il problema tecnico difficile non era mai quello atteso. Non è stato collegare le API, che è la parte meccanica. È stato normalizzare dati incoerenti, gestire i limiti di chiamata, distinguere i casi anomali, evitare le duplicazioni.
Il valore misurabile è quasi sempre il tempo di reazione, non le ore risparmiate. Le ore risparmiate sono la voce che si mette nel business case. Ma il cambiamento che le persone notano è un altro: il lead a cui si risponde in due minuti invece che il lunedì mattina, il cliente che non chiama il centralino perché ha già ricevuto il messaggio.
Ogni automazione ha bisogno del suo controllo. Un processo che si ferma in silenzio è peggio di un processo che non esiste, perché tutti continuano a fidarsi di un dato che non si aggiorna più. Su ogni progetto abbiamo aggiunto un monitoraggio che verifica l’esecuzione e avvisa quando manca: il pattern è descritto nella nostra guida a n8n self-hosted.
Esiste un processo, nella vostra azienda, che qualcuno rifà a mano tutte le settimane? È da lì che si parte, non dal software. Guardate come lavoriamo su AI e automazione dei processi, oppure raccontatecelo e vi diciamo con franchezza se vale la pena automatizzarlo.
