Guida rapida: automatizzare il follow-up clienti con i Goal Event Task Status di GoHighLevel

TL;DR: quando il follow-up dipende dal fatto che un collega abbia davvero completato una task, il processo manuale crea attese e passaggi dimenticati. Nei Workflow di HighLevel, l’opzione Task Status nei Goal Event consente di far raggiungere un obiettivo al contatto quando una task collegata viene creata o completata, con filtri per nome o assegnatario. Il risultato operativo verificabile è un workflow che può indirizzare il contatto al ramo previsto in seguito allo stato della task configurata. Nomi, opzioni e disponibilità dell’interfaccia possono cambiare dopo la data di verifica della fonte, 9 giugno 2026.

In sintesi

Il responsabile di un team commerciale, di un’agenzia o di un’azienda di servizi conosce bene questa situazione: una comunicazione al cliente deve partire solo dopo un’attività interna. Qualcuno deve preparare un report, pianificare una sessione, completare un passaggio di onboarding o chiudere una verifica. Se il controllo avviene a mano, il team deve ricordarsi sia di completare la task sia di far avanzare il contatto nel processo.

L’aggiornamento di HighLevel descritto nel changelog ufficiale sui Goal Event e Task Status aggiunge lo stato delle task all’azione Goal Event dei Workflow. In pratica, la creazione o il completamento di una task può diventare il segnale che fa proseguire un contatto in un flusso già avviato.

Questa possibilità è utile ad agenzie di marketing, PMI con team di vendita e aziende di servizi che rappresentano fasi operative con task. Non promette risultati commerciali automatici: serve a rendere il passaggio tra attività interna e follow-up più aderente al progresso reale registrato nel CRM.

La situazione di partenza

Risposta breve: il problema nasce quando il workflow conosce il contatto, ma non sa che l’attività interna è stata conclusa.

In uno scenario ipotetico, un nuovo cliente entra in un processo di onboarding. Il team crea alcune task: configurare un account, raccogliere materiale, preparare un report iniziale oppure pianificare un appuntamento. Il cliente dovrebbe ricevere una comunicazione solo dopo una specifica attività.

Senza un collegamento diretto tra task e avanzamento del workflow, il responsabile può ritrovarsi a chiedere aggiornamenti, a verificare manualmente le attività o a costruire passaggi intermedi. Il rischio non è soltanto il ritardo: una comunicazione può partire troppo presto, non partire affatto oppure essere affidata alla memoria di una persona.

Prima dell’aggiornamento indicato dalla fonte, gli eventi del ciclo di vita della task — creazione e completamento — erano disponibili come trigger per avviare un workflow. Non potevano però essere usati come Goal per far avanzare un contatto dentro un flusso già in corso. La distinzione è importante: un trigger apre un processo; un Goal Event può invece rappresentare una condizione di progresso nel processo esistente.

Per chi costruisce onboarding, gestione progetti o follow-up post-vendita, questa differenza incide sulla struttura del workflow. Se l’obiettivo è continuare una sequenza solo dopo il completamento di un’attività, la logica deve riflettere quel fatto operativo, non una previsione sul momento in cui l’attività potrebbe essere stata svolta.

Cosa cambia con HighLevel

Risposta breve: Task Status porta gli eventi “task creata” e “task completata” dentro il Goal Event, così il workflow può reagire al progresso dell’attività.

HighLevel supporta ora Task Status come tipo di Goal Event. La fonte ufficiale indica che il Goal può riconoscere lo stato di una task associata al contatto, sia quando viene creata sia quando viene completata.

Quando una task collegata a un contatto viene contrassegnata come completata, il contatto può essere indirizzato verso il ramo designato dal Goal Event. In questo modo, il workflow può basarsi su un evento CRM reale: il completamento dell’attività configurata.

Il cambiamento è particolarmente rilevante quando un processo ha due livelli distinti:

• il team interno svolge e chiude una task;
• il workflow HighLevel esegue la fase successiva prevista per il contatto.

Per esempio, in un caso ipotetico di azienda di servizi, la task “Prepara report iniziale” può rappresentare una fase interna. Quando viene completata, il Goal Event può portare il contatto nel ramo che contiene la comunicazione relativa al report. La fonte cita anche l’esempio di una palestra: dopo la registrazione di un nuovo iscritto, una task assegnata a un istruttore può riguardare la pianificazione di una sessione di prova; al suo completamento, il workflow può proseguire con email, SMS di promemoria e richiesta di feedback.

Il punto non è il singolo canale di comunicazione, ma la relazione tra quattro elementi espliciti: HighLevel conserva task e workflow; lo strumento Goal Event con Task Status osserva lo stato scelto; il settore definisce quale attività rappresenta una fase reale; il risultato operativo è l’instradamento del contatto nel ramo previsto dopo quell’evento.

La possibilità di filtrare per nome della task o assegnatario aggiunge precisione. Secondo la fonte, questi filtri replicano le opzioni disponibili nei trigger basati su task. È quindi possibile progettare un Goal che non reagisca a qualunque attività, ma soltanto a quella pertinente al processo o al team indicato.

Per altri aspetti di organizzazione dei contatti e dei dati operativi, può essere utile anche questa guida interna sulla sincronizzazione tra Xero e GoHighLevel.

Come configurare il flusso

Risposta breve: nel workflow aggiungi o modifica un Goal Event, seleziona Task Status, scegli l’evento desiderato e applica i filtri coerenti con la task che deve far avanzare il contatto.

Di seguito sono riportati i passaggi indicati dalla fonte ufficiale. L’interfaccia di GoHighLevel può essere aggiornata nel tempo: verifica etichette e opzioni nel tuo account prima di pubblicare il workflow.

1. Apri un workflow esistente oppure creane uno. Il caso d’uso è un flusso che è già iniziato e che deve proseguire quando si verifica una condizione legata a una task.

2. Aggiungi o modifica l’azione Goal Event. La novità riguarda questa specifica azione all’interno dei Workflow, non la sola impostazione di un trigger iniziale.

3. Seleziona “Task Status” tra i tipi di Goal. La fonte descrive Task Status come la nuova opzione che abilita la gestione dello stato della task nel Goal Event.

4. Scegli l’evento di stato da usare. Le opzioni indicate sono Task Created e Task Completed. Nel follow-up successivo a un’attività interna, la fonte segnala il completamento come l’uso più comune; la scelta corretta dipende comunque dalla fase che si vuole rappresentare.

5. Applica i filtri disponibili. Puoi filtrare la task per Nome o Assegnatario. Un filtro per nome aiuta a distinguere una task chiave dalle altre attività del contatto; un filtro per assegnatario permette di collegare il Goal al lavoro di una persona o di un team specifico, secondo le opzioni descritte nella fonte.

6. Definisci il ramo che segue il raggiungimento del Goal. È qui che collochi le azioni successive previste dal tuo processo: per esempio una comunicazione al contatto o un passaggio interno. La fonte non prescrive un messaggio, una tempistica o un canale standard; questi elementi vanno decisi in base al caso d’uso e controllati prima dell’attivazione.

Un consiglio editoriale è partire da una sola task che abbia un significato inequivocabile. Prima di automatizzare più percorsi, scrivi in una frase la regola: “quando la task X, assegnata a Y, è completata, il contatto deve passare al ramo Z”. Se la frase è ambigua, lo sarà anche il workflow.

Se il ramo successivo include email con contenuti informativi, puoi approfondire la gestione delle creatività in questa guida su come inserire video YouTube nelle email GoHighLevel. È un tema complementare: non modifica la logica del Goal Event, ma può aiutare a preparare il contenuto che il workflow invierà dopo il progresso della task.

Il risultato operativo

Risposta breve: il follow-up può dipendere dal completamento registrato di una task specifica, anziché da un controllo manuale separato.

La configurazione non sostituisce il lavoro del team: una task deve comunque essere creata e, quando appropriato, contrassegnata come completata. Ciò che cambia è il collegamento tra quell’azione nel CRM e la fase successiva del workflow.

In un onboarding, questo consente di fare in modo che il contatto venga indirizzato verso il ramo stabilito quando la task filtrata raggiunge lo stato configurato. In un processo di vendita, la stessa logica può essere usata per orchestrare un follow-up sulla base dell’avanzamento delle task assegnate ai commerciali. In un’azienda di servizi, può collegare il completamento di una fase interna all’avvio di una comunicazione o di un ulteriore passaggio operativo.

Il beneficio indicato dalla fonte è una maggiore precisione del workflow e una minore necessità di passaggi aggiuntivi o logiche condizionali macchinose. Non significa che ogni processo diventi automaticamente semplice: la qualità dell’automazione dipende da task nominate in modo chiaro, responsabilità coerenti e criteri condivisi per segnare un’attività come completata.

Errori e limiti

Risposta breve: Task Status funziona bene solo se la task scelta rappresenta davvero l’avanzamento che vuoi usare come condizione.

Il primo errore da evitare è usare un filtro troppo generico. Se un Goal Event deve reagire al completamento di una particolare attività, configurarlo senza distinguere nome o assegnatario può rendere il percorso meno controllabile. La fonte mette a disposizione questi filtri proprio per aumentare la granularità.

Il secondo errore è confondere Task Created con Task Completed. Una task creata dimostra che l’attività è stata inserita nel processo; una task completata indica invece lo stato concluso. Non sono segnali intercambiabili: scegli quello che corrisponde al risultato operativo richiesto dal workflow.

Il terzo errore è trattare il Goal come se sostituisse il disegno dell’intero processo. Il Goal Event consente al contatto di raggiungere un ramo quando avviene l’evento configurato, ma non definisce da solo chi crea la task, chi la chiude o quale comunicazione sia appropriata. Queste decisioni restano organizzative.

Un limite da considerare è che la fonte descrive filtri per nome e assegnatario, oltre agli eventi di creazione e completamento. Non attribuire al Goal Event condizioni, canali, tempi o comportamenti non documentati. Prima della pubblicazione, controlla anche che ogni task sia effettivamente collegata al contatto interessato, poiché la logica descritta dalla fonte riguarda task legate a un contatto.

Infine, non presentare l’automazione come garanzia di risposta, vendita, puntualità del team o soddisfazione del cliente. Il risultato verificabile è il passaggio del contatto nel ramo impostato al verificarsi dello stato della task configurata. I risultati complessivi variano in base al contesto, all’impegno e al modello di business.

Così si torna al problema iniziale: il responsabile non deve fondare il follow-up sulla memoria di un controllo manuale separato. Può progettare il workflow affinché la fase successiva dipenda dal completamento dell’attività che il team ha registrato. Per estendere il follow-up conversazionale, scopri il bonus WhatsApp per GoHighLevel.