Immagina una richiesta ricevuta da un modulo: una persona chiede una risposta su un prodotto e l'AI prepara una bozza. Il rischio non è generare il testo, ma trasformarlo automaticamente in una promessa o in un'attività assegnata. Disegna quindi quattro stati espliciti: ricevuta, bozza pronta, in approvazione, approvata o rifiutata. Solo l'ultimo stato positivo può attivare un'azione esterna.
Perché è importante
- La bozza generata resta un dato intermedio, non un'azione autorizzata.
- Gmail Send and Wait può attendere un'approvazione semplice nel workflow n8n.
- Una chiave di richiesta e uno stato salvato evitano che un retry produca due azioni.
Disegna prima il punto in cui il flusso deve fermarsi
In n8n puoi partire da un Form Trigger o da un Webhook, secondo il canale di ingresso. Raccogli solo i campi necessari: identificativo, richiesta, contatto e orario. Verifica che il contatto sia presente e che il testo non sia vuoto prima di chiamare il modello AI. Se manca un dato, manda la richiesta a una coda di correzione anziché produrre una bozza apparentemente completa.
Assegna una chiave stabile all'evento, per esempio l'ID del modulo o dell'ordine. Salvala insieme allo stato del flusso in un archivio persistente prima delle azioni esterne. Quando lo stesso evento rientra per un retry o un doppio clic, cerca la chiave: se esiste già, continua dalla fase registrata. Un timestamp generato a ogni tentativo non funziona come chiave di deduplicazione.
Produci una bozza che si possa giudicare
Il nodo AI dovrebbe restituire campi separati, non un messaggio indistinto: riassunto della richiesta, proposta di risposta, fatti da verificare e livello di incertezza. Nel prompt specifica di non inventare prezzi, disponibilità o garanzie. In questo modo chi approva può leggere il punto critico senza dover ricostruire tutto il contesto dalla conversazione originale.
Aggiungi una verifica deterministica sui campi prima dell'approvazione. Se manca la proposta o compaiono dati personali non necessari, il workflow passa a revisione manuale. Anche una bozza grammaticalmente corretta può attribuire al cliente un'esigenza che non ha espresso. La struttura aiuta a scoprire questo errore prima di creare un ticket o inviare una comunicazione.
Prepara nel messaggio di revisione tre elementi: richiesta originale ridotta al necessario, bozza AI e pulsanti di decisione. Mantieni l'identificativo della richiesta visibile. Chi riceve la notifica deve capire quale azione avverrà se approva, ad esempio ‘crea attività per il team’ oppure ‘invia risposta al contatto’. Non chiedere un sì generico per un'azione ambigua.
Cosa puoi farci concretamente
- Definisci un identificativo univoco per ogni richiesta in ingresso.
- Inserisci il nodo di approvazione prima di creare l'attività o inviare messaggi esterni.
- Prova approvazione, rifiuto, timeout e invio duplicato con dati fittizi.
Aggiungi la decisione umana nel punto giusto
La documentazione n8n descrive nell'operazione Gmail ‘Send and Wait for Approval’ una risposta con approvazione o rifiuto. Usala per una decisione semplice e collega l'uscita approvata al nodo che crea l'attività. Collega il rifiuto a una registrazione dello stato e, se utile, a una richiesta di revisione. Per percorsi più complessi, la documentazione indirizza al nodo Wait.
L'approvazione deve riferirsi a una bozza precisa. Se la bozza cambia mentre qualcuno ha l'email aperta, la decisione potrebbe autorizzare una versione diversa. Salva quindi testo e identificativo della revisione prima dell'invio, e controlla che coincidano quando la risposta torna. Se non coincidono, richiedi una nuova approvazione invece di interpretare quella vecchia come valida.
Imposta anche una scadenza operativa: dopo un tempo ragionevole, la richiesta resta in attesa o passa a una persona sostitutiva. Non trasformare il silenzio in approvazione. Registra data, esito e identità dell'approvatore secondo le regole del tuo contesto. Queste informazioni servono a capire perché un'attività è nata, senza dover ispezionare i log tecnici.
Prova il flusso prima di usarlo davvero
Con dati fittizi, invia una richiesta valida e approvala: deve nascere una sola attività, con un riferimento alla decisione. Ripeti la stessa richiesta con lo stesso ID: non deve nascere un secondo oggetto. Poi rifiuta una bozza: l'attività non deve essere creata. Questi tre casi verificano la proprietà centrale del flusso molto meglio di una dimostrazione che mostra solo il percorso felice.
Simula anche un errore del modello e una risposta tardiva. Se la generazione fallisce, conserva la richiesta e segnala il problema a chi la gestisce; se l'approvazione arriva dopo un annullamento, non eseguire l'azione. Nel registro salva le transizioni di stato, l'ID dell'azione finale e l'errore, così puoi riprendere una richiesta senza reinviarla alla cieca.
Quando i test passano, abilita il workflow per un piccolo gruppo e misura quanti testi vengono corretti, quante approvazioni scadono e quante esecuzioni duplicate sono intercettate. Se ogni bozza richiede una riscrittura totale, migliora i dati di ingresso o il prompt prima di aumentare il volume. L'obiettivo è aiutare chi decide, non nascondere il lavoro dietro un pulsante.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
