Quando un’attività ricorrente entra in un software, la parola “automazione” porta con sé una promessa di velocità. Un contatto viene classificato, un messaggio parte, un’attività compare nel CRM e il team può occuparsi di altro. Un workflow marketing non è affidabile perché esegue molti passaggi: lo è quando rende chiaro quale decisione sta supportando, che cosa può fare da solo e quando deve fermarsi.
Questa distinzione è ancora più importante quando nel flusso entra un sistema di intelligenza artificiale. La generazione di un testo, la sintesi di una richiesta o la previsione di una probabilità possono aiutare il lavoro, ma non trasformano automaticamente un’ipotesi in un fatto.
La velocità non è ancora un risultato
Un’automazione può essere tecnicamente corretta e produrre comunque un esito mediocre. Può inviare il messaggio previsto a un destinatario che ha cambiato esigenza, duplicare una comunicazione già ricevuta, trattare un’informazione incompleta come se fosse certa oppure assegnare una richiesta al gruppo sbagliato. In tutti questi casi il sistema ha “funzionato” secondo il suo algoritmo, ma non secondo l’obiettivo del marketing.
Per questo partirei dal risultato che voglio rendere più semplice, non dal connettore da attivare. Se l’obiettivo è aiutare una persona a scegliere una risorsa, il workflow dovrebbe ridurre il tempo per trovare la risposta. Se l’obiettivo è dare continuità a una richiesta commerciale, dovrebbe migliorare il passaggio di consegne. Se l’obiettivo è produrre una bozza, dovrebbe lasciare visibile che si tratta di una bozza e indicare chi la approva.
Disegnare il workflow a partire dalla decisione
1. Definire trigger e promessa
Il trigger deve essere un evento comprensibile: una richiesta ricevuta, un contenuto scaricato, una modifica volontaria a un profilo, una scadenza operativa. Eviterei trigger vaghi come “utente interessato” se non so da quale evidenza deriva l’etichetta. Accanto al trigger scriverei la promessa: “entro un giorno lavorativo riceverai una risposta pertinente” oppure “la bozza sarà pronta per la revisione”. La promessa diventa il riferimento per capire se l’automazione sta creando utilità.
2. Separare regole, inferenze e generazione
Non tutti i passaggi hanno lo stesso grado di certezza. Una regola esplicita, come smistare un modulo in base alla lingua scelta, è diversa da un’inferenza, come stimare l’urgenza da una frase, ed entrambe sono diverse dalla generazione di una risposta. Nel disegno del flusso metterei queste tre categorie su piani distinti, con una traccia visibile dell’origine.
Questo aiuta anche a scegliere il livello di controllo. Una regola stabile può eseguire un’azione semplice. Un’inferenza può suggerire una priorità, ma richiedere una conferma quando l’impatto è rilevante. Un testo generato può accelerare la prima stesura, ma dovrebbe passare da un controllo su fatti, tono, destinatario e promessa. La domanda non è se l’AI sia “brava” in astratto: è quale errore può produrre in quel punto del percorso.
3. Stabilire soglie e stop
Ogni workflow dovrebbe avere condizioni che impediscono l’invio o l’avanzamento. Dati mancanti, informazioni contraddittorie, richiesta fuori perimetro, importo elevato, destinatario non identificato o contenuto che riguarda una situazione delicata sono esempi di segnali per una coda manuale. Non sono fallimenti dell’automazione: sono parti deliberate del suo comportamento.
Inserirei inoltre un arresto semplice e comprensibile. Deve essere possibile sospendere la campagna, bloccare un singolo percorso e annullare gli invii in attesa senza ricostruire a mano ciò che è successo. Un pulsante di stop è utile solo se qualcuno sa chi può usarlo, in quali casi e quale stato sicuro viene ripristinato.
La supervisione umana deve essere operativa
“C’è un umano nel processo” non basta. Una persona che riceve migliaia di suggerimenti senza tempo, contesto o possibilità di intervenire sta soltanto ratificando l’automazione. La supervisione deve avere un compito preciso: controllare i casi ambigui, correggere l’azione, rifiutare un output, chiedere dati aggiuntivi o interrompere il flusso.
Il NIST AI Risk Management Framework organizza il lavoro in quattro funzioni continue: governare, mappare, misurare e gestire. Non lo interpreto come una checklist da compilare una volta, ma come un ciclo che ritorna quando cambiano dati, obiettivi, modello o destinatari. Per un piccolo team significa almeno assegnare un responsabile, definire il perimetro, osservare gli errori e avere una procedura per correggere il comportamento.
Il riferimento europeo è altrettanto utile come criterio di progettazione, anche se gli obblighi concreti dipendono dalla classificazione e dal contesto del sistema. L’articolo 14 del Regolamento europeo sull’intelligenza artificiale, per i sistemi ad alto rischio, parla di persone abilitate a comprendere limiti e anomalie, evitare l’eccessiva fiducia nell’output, ignorarlo o sovrascriverlo e interrompere il sistema in sicurezza. Sono requisiti pensati per un perimetro specifico, ma descrivono bene che cosa dovrebbe significare “controllo umano” quando un’automazione può incidere su una persona.
Dal 2 agosto 2026 l’AI Act è nella fase di applicazione generale prevista, con eccezioni e scadenze differenziate. Se un percorso usa un chatbot o presenta contenuti generati o alterati dall’AI, verificherei gli obblighi pertinenti e renderei chiaro il ruolo della tecnologia.
Mettere i casi limite nel disegno
Il test più importante non è quello in cui tutto va bene. Prima del rilascio preparerei esempi normali e casi al limite: un campo vuoto, due segnali discordanti, un messaggio ironico interpretato alla lettera, una lingua non prevista, un contatto che chiede di non essere più raggiunto, un contenuto che contiene istruzioni estranee al compito. Per ciascun caso definirei l’azione attesa: completare, chiedere conferma, passare a una persona o fermarsi.
Log e revisioni sono parte del prodotto
Quando un messaggio parte, voglio poter ricostruire perché è partito. Terrei quindi un log proporzionato al rischio: evento che ha attivato il flusso, dati essenziali utilizzati, regola o modello coinvolto, versione del prompt o della configurazione, output, eventuale modifica umana, momento dell’invio e risultato noto.
Programmarei una revisione dopo il lancio: cambiare una fonte, un campo del CRM, una regola o un modello può modificare il comportamento del sistema. Una data di controllo e un proprietario sono più efficaci di un documento perfetto che nessuno riapre.
Misurare qualità, non soltanto volume
Il numero di messaggi inviati o di attività completate è una misura di throughput, non di qualità. Accanto a quel dato osserverei il tasso di correzione manuale, le eccezioni, gli invii duplicati, le risposte fuori contesto, le richieste di modifica, le disiscrizioni e il tempo necessario per recuperare da un errore. Se l’automazione riduce cinque minuti di lavoro ma crea una conversazione da ricostruire, il bilancio non è positivo.
Non userei neppure la conversione iniziale come unica sentenza. Un percorso può generare più clic e peggiorare la fiducia; può inviare meno messaggi e aumentare la qualità delle richieste. La metrica più importante è quella collegata alla promessa del workflow, integrata da segnali che mostrano attrito e danno. Misurare significa anche decidere in anticipo quali risultati autorizzano a estendere l’automazione e quali impongono una pausa.
La scheda minima prima di attivare un flusso
Prima di pubblicare un’automazione, preparerei una scheda breve con quattro risposte:
- Quale evento la attiva e quale beneficio concreto promette?
- Quali dati osserva, quali passaggi interpreta e quali contenuti genera?
- Quali casi richiedono conferma, esclusione o arresto?
- Chi può correggere, sospendere e revisionare il flusso, e quali segnali controllerà?
Se non riesco a rispondere in linguaggio semplice, rimanderei l’attivazione. Non per diffidenza verso l’automazione, ma perché la chiarezza è una forma di affidabilità. Un sistema piccolo, osservabile e reversibile può crescere meglio di un sistema complesso che nessuno sa fermare.
La regola che seguo
Automatizzare il marketing non significa trasferire ogni decisione a un software. Significa togliere attrito alle attività ripetitive e conservare attenzione umana dove contano contesto, ambiguità e responsabilità. Io partirei da un flusso circoscritto, definirei la promessa, inserirei soglie e stop, misurerei gli errori e allargherei il perimetro solo dopo aver capito che cosa succede davvero.
È un metodo utile per una sequenza email, una qualificazione, un chatbot o una bozza prodotta con l’AI. Se vuoi confrontarti su un workflow concreto, puoi scrivermi: per me il punto non è automatizzare di più, ma rendere più leggibili le decisioni che il marketing prende ogni giorno.
Fonti e riferimenti
- NIST, AI Risk Management Framework Core, funzioni Govern, Map, Measure e Manage.
- EUR-Lex, Regolamento (UE) 2024/1689 sull’intelligenza artificiale, in particolare articolo 14.
- Commissione europea, AI Act: quadro normativo e calendario di applicazione.
- Commissione europea, AI talent, skills and literacy, informazioni sull’articolo 4.
Nota di trasparenza: questo articolo è stato elaborato con l'aiuto dell'intelligenza artificiale e con supervisione e responsabilità editoriale umana.