Un’automazione marketing si giudica spesso dal percorso ideale: il contatto compila un modulo, riceve il messaggio giusto, entra nel segmento corretto e arriva al passaggio successivo senza attriti. È una rappresentazione utile, ma incompleta. Nella realtà una mail può non partire, un evento può essere registrato due volte, un consenso può mancare, un pagamento può restare sospeso o un responsabile può dover intervenire. Se il flusso non sa cosa fare in questi casi, l’automazione non sta risparmiando lavoro: lo sta soltanto spostando, spesso nel punto meno visibile.
Per questo considero il fallback parte della promessa. Non è un piano B aggiunto alla fine, ma la risposta progettata in anticipo quando il percorso principale non è più affidabile. Un buon fallback protegge la persona, conserva il contesto, rende leggibile l’errore e permette al team di capire se il sistema ha recuperato oppure no.
Il percorso ideale non è il vero workflow
Quando si disegna un workflow marketing, la prima domanda è quasi sempre: “Qual è il trigger?”. È il momento in cui accade qualcosa: un download, una richiesta di contatto, una visita a una pagina, una risposta a una campagna. La domanda successiva dovrebbe essere: “Quale condizione deve essere vera perché il passaggio seguente sia legittimo?”.
Un contatto che scarica una guida non è automaticamente pronto per una proposta commerciale. Un indirizzo presente nel CRM non dimostra da solo il consenso a ogni tipo di messaggio. Un evento chiamato form_submit non prova che il dato sia arrivato al gestionale, né che una persona abbia ricevuto la conferma. L’automazione ha bisogno di precondizioni, non solo di azioni.
La documentazione di Google Analytics sugli eventi li descrive come interazioni o occorrenze misurabili e distingue gli eventi importanti per il business, chiamati key event. La distinzione è utile anche fuori da Analytics: un evento tecnico racconta che qualcosa è successo; un evento chiave dovrebbe raccontare che si è verificato un passaggio rilevante per la decisione. Confondere i due livelli porta a costruire automazioni su segnali fragili.
Quattro fallback che conviene progettare subito
1. Il fallback del dato mancante
Se manca un campo indispensabile, il sistema non dovrebbe inventarlo né proseguire in silenzio. Può chiedere il dato con un messaggio chiaro, sospendere il contatto in una coda di revisione o inviare una conferma neutra che non presupponga un’intenzione commerciale. La scelta dipende dal contesto, ma deve essere esplicita.
Il principio di protezione dei dati fin dalla progettazione e per impostazione predefinita, richiamato dall’articolo 25 del GDPR e dalle linee guida dell’EDPB, aiuta a porre la domanda giusta: quali dati sono davvero necessari per completare questo passaggio e quali, invece, stiamo raccogliendo solo perché il sistema li consente? Un fallback sobrio riduce sia il rischio operativo sia la raccolta eccedente.
2. Il fallback del consenso
Una campagna promozionale non dovrebbe partire perché un indirizzo è stato trovato in una tabella. Il flusso deve sapere da quale modulo o interazione proviene il contatto, quale finalità è stata spiegata, quando è stata espressa la preferenza e come può essere ritirata. Se una di queste informazioni manca, il percorso commerciale va fermato, non interpretato a favore dell’invio.
Le linee guida di Gmail per le liste di invio distinguono i messaggi di abbonamento, tra cui newsletter e comunicazioni marketing, dai messaggi transazionali come reset della password e ricevute. Per le comunicazioni promozionali chiedono un modo semplice per disiscriversi; per i mittenti che superano determinate soglie, il one-click unsubscribe è un requisito esplicito. La FAQ per i mittenti chiarisce inoltre che la richiesta di disiscrizione va rispettata in tempi ragionevoli. Anche un’azienda che invia volumi inferiori dovrebbe leggere questa indicazione come una regola di esperienza: lo stop deve essere più facile dell’iscrizione.
3. Il fallback del canale
Quando il canale principale fallisce, la tentazione è replicare subito lo stesso messaggio altrove. Ma un SMS, una telefonata o una nuova email non sono equivalenti. Prima di cambiare canale occorre capire se esiste una preferenza valida, se il messaggio è urgente e se il nuovo contatto aggiunge valore o soltanto pressione.
Il fallback può quindi essere un’attesa controllata, una notifica interna oppure una pagina dove la persona ritrova il contesto e sceglie come continuare. La continuità non significa bombardare tutti i canali: significa non lasciare la persona senza spiegazione quando l’automazione si interrompe.
4. Il fallback dell’approvazione
Alcuni passaggi meritano una revisione umana: un lead con una richiesta insolita, una comunicazione con implicazioni reputazionali, una modifica di prezzo, una risposta generata automaticamente o una condizione che il flusso non sa classificare. In questi casi il fallback deve consegnare a una persona il contesto minimo per decidere: cosa è successo, quale regola è stata attivata, cosa è già stato inviato e qual è la scadenza.
Un alert senza contesto non è una presa in carico: è un altro lavoro da ricostruire. La coda di revisione deve avere priorità, responsabile e stato, altrimenti ogni eccezione torna a essere una dimenticanza.
Misurare il recupero, non soltanto l’invio
Molti report mostrano quanti messaggi sono stati inviati, quanti clic sono arrivati e quante conversioni sono state attribuite. Sono segnali utili, ma un’automazione affidabile richiede anche eventi di controllo: workflow avviato, condizione verificata, errore rilevato, fallback attivato, recupero completato, passaggio preso in carico, stop rispettato.
In Google Analytics ogni evento può diventare un key event, ma questo non significa che debba diventarlo. Se si marca come importante ogni passaggio tecnico, il report perde la gerarchia. Preferisco definire pochi eventi chiave e mantenere gli altri come segnali diagnostici. La documentazione di Analytics sulla creazione e modifica degli eventi chiave ricorda inoltre che gli eventi possono essere controllati in tempo reale e tramite DebugView: questa verifica va fatta durante la progettazione, non quando una campagna è già stata giudicata.
La domanda non è soltanto “quanti lead ha generato il workflow?”, ma anche: quanti contatti hanno incontrato un errore? Quanti sono stati recuperati senza duplicazioni? Quanto tempo è passato prima della presa in carico? Quanti hanno ricevuto un messaggio dopo aver chiesto di fermarsi? Questi indicatori trasformano il fallback da eccezione invisibile a componente misurabile della qualità.
L’errore deve essere comprensibile anche per chi lo subisce
Quando l’automazione coinvolge un modulo, la qualità del fallback è anche una questione di accessibilità. Le WCAG spiegano che, se viene rilevato un errore di inserimento, il campo deve essere identificato e l’errore descritto in testo. Un colore rosso o un messaggio generico come “qualcosa è andato storto” non restituiscono abbastanza informazioni per correggere il problema.
La stessa logica vale per email e pagine di conferma: dire che la richiesta è stata ricevuta quando non lo è stata crea una falsa sicurezza; dire soltanto che c’è un errore scarica tutta l’incertezza sulla persona. Un messaggio utile indica cosa è successo, cosa può fare l’utente e cosa farà l’azienda, se è previsto un intervento.
Una checklist minima prima di attivare il flusso
Prima di pubblicare un’automazione, verifico almeno questi punti:
- Quale dato o consenso abilita ogni passaggio?
- Cosa succede se il dato è assente, duplicato o incoerente?
- Qual è il canale di recupero e quale canale non deve essere usato?
- Chi riceve l’eccezione, con quale contesto e con quale scadenza?
- Quali eventi misurano errore, fallback, recupero e stop?
- Come si prova il flusso con un contatto reale ma controllato, senza inviare comunicazioni indesiderate?
Non tutte le automazioni devono avere la stessa complessità. Un promemoria interno può avere un fallback molto semplice; una sequenza commerciale o una comunicazione che tratta dati personali richiede più controlli. La proporzione è importante, ma il principio resta uguale: ogni promessa automatica deve avere una risposta credibile quando la condizione iniziale non è più vera.
Nel mio lavoro considero l’automazione un sistema di responsabilità distribuita, non una scorciatoia per fare più invii. Se il flusso è chiaro anche quando qualcosa va storto, il marketing diventa più misurabile, più rispettoso e più facile da migliorare. È da qui che partirei: mappare le eccezioni di un solo workflow, scegliere il fallback per ciascuna e misurare se il recupero funziona davvero.
Nota di trasparenza: questo articolo è stato elaborato con l'aiuto dell'intelligenza artificiale e con supervisione e responsabilità editoriale umana.