Flussi di lavoro GoHighLevel: come automatizzare le risposte del team con Wait Step

TL;DR: quando una nuova conversazione entra in GoHighLevel, il problema non è solo assegnarla: è capire se qualcuno del team ha risposto entro il tempo previsto. L’aggiornamento del blocco Wait Step introduce la condizione User Replied, che mette in pausa un workflow fino alla risposta di un utente interno o fino a un timeout configurato. Il risultato operativo verificabile è una biforcazione chiara del flusso: prosecuzione dopo la risposta del team oppure azione di escalation alla scadenza.

In sintesi

La novità documentata da HighLevel riguarda i workflow e, nello specifico, il blocco di attesa Wait Step. Oltre all’attesa di una risposta del contatto esterno, il blocco può ora attendere la risposta di un utente interno, cioè di un membro del team che interviene nella conversazione associata al contatto.

È una funzione utile ad agenzie, team commerciali e team di assistenza che vogliono gestire SLA di prima risposta, passaggi di consegna e escalation senza dover controllare manualmente ogni conversazione. Secondo la nota ufficiale di HighLevel sul Wait Step con supporto alle risposte degli utenti, il workflow può riprendere appena un utente invia una risposta oppure seguire un percorso alternativo quando scade il tempo impostato.

Questo tutorial separa i comportamenti dichiarati nella fonte dai consigli editoriali di progettazione. La fonte è datata 8 luglio 2026: nomi delle opzioni, posizione dei comandi e disponibilità possono cambiare dopo tale data.

La situazione di partenza

Risposta breve: assegnare un lead o un ticket non prova che il team abbia risposto; senza un controllo del tempo di prima risposta, il responsabile deve verificare manualmente le conversazioni aperte.

Il titolare di un’agenzia o il responsabile di un reparto vede spesso lo stesso schema: arriva una richiesta, il contatto viene assegnato a un commerciale o a un operatore, parte una notifica e il processo sembra concluso. In realtà, da quel momento si apre un punto cieco. La conversazione può ricevere una risposta in pochi minuti, restare ferma perché l’assegnatario è impegnato oppure passare inosservata fino a quando il contatto sollecita di nuovo.

Il processo manuale produce conseguenze operative concrete: controllo ripetuto delle inbox, messaggi interni per chiedere aggiornamenti, verifiche a posteriori sui tempi di reazione e interventi tardivi del responsabile. Non serve attribuire questo scenario a un cliente reale: è un caso ipotetico, ma coerente con la gestione quotidiana di lead e assistenza.

Prima dell’aggiornamento descritto da HighLevel, il Wait Step poteva sospendere un workflow in attesa di una risposta o di un’azione del contatto. La nuova condizione sposta l’attenzione anche sul comportamento interno: il flusso può attendere che un utente del team risponda nella conversazione.

La distinzione è importante. Il contatto è il cliente o lead esterno; l’utente è il membro del team che opera in HighLevel. Il Wait Step non sostituisce l’assegnazione della conversazione, le regole di responsabilità o la formazione degli operatori. Aggiunge invece un punto di controllo nel workflow per verificare se avviene la risposta interna attesa.

Cosa cambia con HighLevel

Risposta breve: con User Replied, il Wait Step può attendere il messaggio di un membro del team e far proseguire il workflow; se esiste un timeout e questo scade, il flusso può attivare un ramo di escalation.

Nella configurazione riportata dalla fonte ufficiale, tra le condizioni di attesa del Wait Step compare User Replied. Quando un utente interno invia un messaggio nella conversazione associata al contatto, il workflow può riprendere immediatamente. Il comportamento riguarda quindi una risposta del team, non la risposta del cliente.

HighLevel indica anche la possibilità di combinare la condizione con un timeout. I due esiti dichiarati sono:

1. Il team risponde prima della scadenza: il contatto prosegue nel workflow.
2. Il timeout scade prima della risposta: il workflow può essere indirizzato a un percorso alternativo, cioè un ramo di escalation.

Per un’agenzia, questo meccanismo è adatto a monitorare la prima risposta su lead gestiti per conto dei clienti oppure sulle proprie richieste di supporto. Per una PMI, può servire a controllare che una conversazione riceva un intervento del personale nei tempi scelti dall’organizzazione. Il risultato non è una garanzia di conversione, di risoluzione del ticket o di soddisfazione del cliente: è la possibilità di rendere tracciabile nel flusso la presenza o l’assenza di una risposta del team entro una finestra definita.

La fonte precisa inoltre che, senza timeout, il workflow resta in attesa a tempo indeterminato finché un utente non risponde. Questa scelta può essere coerente con processi che dipendono obbligatoriamente da una supervisione umana, ma non è adatta a ogni scenario.

In termini di progettazione, la funzione si collega bene a ruoli e responsabilità definite. Prima di automatizzare un’escalation, è utile verificare chi possa intervenire sulle conversazioni e chi debba ricevere gli avvisi. Per questo può essere pertinente anche la guida sulla gestione degli accessi e dei permessi granulari in GoHighLevel.

Come configurare il flusso

Risposta breve: nel workflow, inserisci o modifica un Wait Step, seleziona la condizione User Replied, definisci se usare un timeout e collega i due possibili esiti alle azioni successive previste dal tuo processo.

Di seguito riportiamo i passaggi supportati dalla fonte. Poiché l’interfaccia può cambiare, considerali come logica di configurazione da verificare nel tuo account HighLevel, non come riproduzione certificata della UI.

1. Parti da un workflow che rappresenti un evento reale

La fonte cita due casi: apertura di un ticket di supporto e acquisizione di un nuovo lead tramite form. In entrambi, il workflow viene attivato dopo l’evento iniziale e può assegnare il contatto a un operatore o venditore, oltre a inviare una notifica interna.

Consiglio editoriale: definisci prima che cosa conta come “prima risposta” per il tuo team. Non basta dire “contattare il lead”: serve allineare il processo sul fatto che la risposta deve essere inviata nella conversazione associata al contatto, perché è questo l’evento che la fonte collega a User Replied.

2. Inserisci il Wait Step con l’attesa della risposta interna

Quando crei o modifichi il blocco di attesa nel workflow, la fonte indica che è disponibile l’opzione User Replied. Impostando questa condizione, il workflow resta sospeso finché un membro del team non invia un messaggio nella conversazione del contatto.

Questo è il passaggio ufficiale centrale dell’aggiornamento. Non va confuso con Contact Replied, la condizione dedicata alla risposta del cliente o lead esterno. Se l’obiettivo è monitorare il tempo di reazione del commerciale o dell’assistenza, la condizione da valutare è la risposta dell’utente interno.

3. Decidi se impostare un timeout

La fonte dichiara che il timeout è configurabile. Se l’utente risponde entro il limite, il workflow prosegue; se non risponde e il limite viene raggiunto, il flusso può dirigersi verso un percorso alternativo.

In un esempio della fonte, il supporto attende 30 minuti prima dell’escalation. In un altro, un flusso per nuovi lead attende 15 minuti. Non sono tempi universali né raccomandazioni valide per ogni attività: sono esempi illustrativi presenti nell’annuncio.

Consiglio editoriale: scegli il timeout in base a orari, carico del team e promessa di servizio effettivamente sostenibile. Un limite troppo breve può generare molte escalation non utili; uno troppo lungo può rendere il controllo poco rilevante. Se non imposti alcun timeout, ricorda il comportamento indicato dalla fonte: l’attesa rimane attiva senza scadenza fino alla risposta dell’utente.

4. Progetta l’esito “risposta ricevuta”

Quando l’operatore risponde, il workflow prosegue subito. La fonte propone, a titolo di esempio, azioni successive come un SMS o una notifica di follow-up al cliente nel caso del supporto, oppure automazioni post-contatto nella gestione dei lead.

Consiglio editoriale: mantieni questo ramo essenziale. Prima verifica che la ripresa del flusso sia coerente con la risposta effettiva del team; solo dopo aggiungi eventuali azioni di follow-up. Se il vostro processo usa attività operative, una possibile estensione da valutare è l’integrazione di Todoist con GoHighLevel nei workflow, tenendo presente che non è descritta come requisito della funzione Wait Step.

5. Progetta l’esito di timeout come escalation

Alla scadenza, la fonte indica che il ramo alternativo può inviare una notifica via email o SMS al responsabile, riassegnare il ticket a un altro operatore oppure creare un’attività urgente nel CRM. Nel caso dei lead, cita anche un’attività ad alta priorità e la notifica al responsabile vendite.

Queste sono possibilità riportate dalla fonte, non una sequenza obbligatoria. L’azione più appropriata dipende dalla struttura del team. In alcuni flussi sarà sufficiente avvisare un responsabile; in altri, la riassegnazione potrà essere prevista dalle procedure interne.

6. Verifica il disegno prima di estenderlo

Consiglio editoriale: prima di applicare il workflow a tutte le conversazioni, documenta su un diagramma semplice evento iniziale, assegnazione, Wait Step, risposta interna, timeout e escalation. Serve a evitare che due automazioni agiscano sulla stessa conversazione con logiche incompatibili. Se stai riorganizzando workflow esistenti, può aiutare approfondire come ottimizzare i Workflow GoHighLevel con AI Builder; la funzione User Replied resta comunque quella descritta dalla fonte ufficiale.

Il risultato operativo

Risposta breve: il responsabile ottiene un workflow che distingue automaticamente tra conversazione presa in carico dal team e conversazione senza risposta entro il tempo definito.

Torniamo al problema iniziale: non sapere se l’assegnazione abbia prodotto un’azione concreta. Con il Wait Step basato su User Replied, il flusso non deve più limitarsi a inviare una notifica iniziale e poi lasciare il controllo al monitoraggio manuale. Può attendere il messaggio dell’operatore e, in alternativa, far partire un percorso di escalation alla scadenza.

Questo rende verificabili due condizioni operative: l’utente ha risposto nella conversazione oppure non ha risposto entro il timeout impostato. È un supporto alla gestione degli SLA di prima risposta e alla prevenzione delle conversazioni dimenticate, non un sostituto del giudizio umano sul contenuto della risposta.

La funzione può convivere con altri strumenti di automazione conversazionale. Per esempio, chi valuta un bot per canali specifici può leggere la guida per configurare l’AI Conversazionale di GoHighLevel e assegnare un bot a ogni canale. Sono però piani diversi: l’AI conversazionale riguarda l’assegnazione di un bot ai canali; User Replied nel Wait Step monitora la risposta di un utente interno in un workflow.

Errori e limiti

Risposta breve: la funzione misura l’evento di risposta dell’utente nel flusso, non la qualità del servizio; un timeout mal definito o un’escalation senza responsabile rischiano di spostare il problema invece di risolverlo.

Il primo errore è scegliere User Replied quando si vuole invece attendere il cliente. La fonte distingue esplicitamente tra risposta del contatto e risposta dell’utente: il tipo di attesa deve corrispondere al soggetto da monitorare.

Il secondo è attivare un timeout senza stabilire che cosa debba accadere dopo. Un ramo di escalation efficace deve avere un destinatario o un’azione coerente con le procedure interne; altrimenti il workflow crea solo un nuovo avviso da gestire manualmente.

Il terzo è interpretare una risposta come prova di risoluzione. La fonte afferma che il flusso riprende quando un utente invia una risposta. Non dichiara che il messaggio risolva il ticket, qualifichi il lead o soddisfi il cliente. Questi risultati dipendono da contesto, persone e modello operativo.

Il quarto è omettere il timeout senza esserne consapevoli. Secondo la fonte, in assenza di timeout il workflow resta in attesa a tempo indeterminato fino alla risposta di un utente. Può essere una scelta intenzionale, ma può anche lasciare contatti bloccati nel flusso se il processo non prevede un controllo alternativo.

Infine, evita di trattare nomi e schermate come immutabili. La disponibilità, la terminologia e l’interfaccia di HighLevel possono cambiare dopo la data di verifica della fonte, l’8 luglio 2026. Consulta sempre l’annuncio ufficiale e testa il comportamento nel tuo ambiente prima di estendere l’automazione.

Se il problema quotidiano è rincorrere conversazioni assegnate ma non gestite, il valore del Wait Step con User Replied è riportare quel controllo dentro il workflow: risposta del team, prosecuzione; mancata risposta entro la soglia, escalation. Per valutare ulteriori strumenti di follow-up su WhatsApp, puoi consultare il bonus WhatsApp GoHighLevel. I risultati variano in base al contesto, al team e al processo configurato.