Opportunità persa in HighLevel: usare il motivo di perdita per un follow-up pertinente

TL;DR: quando una trattativa viene chiusa come persa, il problema non è solo non averla convertita: è continuare a inviare lo stesso nurture a contatti che hanno indicato un ostacolo preciso. Il trigger Pipeline Stage Changed di HighLevel può avviare un workflow al cambio di fase e restringerlo con filtri come pipeline, fase, stato e Lost Reason. Il risultato operativo verificabile è questo: il workflow parte soltanto per le opportunità che passano a Lost e hanno il motivo di perdita configurato, invece di coinvolgere indistintamente ogni contatto non convertito.

In sintesi

Un titolare o un responsabile commerciale conosce bene la scena: una trattativa si chiude negativamente, il commerciale annota a voce che il budget non c’era, che è stato scelto un concorrente o che il contatto non rispondeva più. Poi il CRM resta poco strutturato e parte una sequenza standard: la stessa email, la stessa notifica o lo stesso task per casi molto diversi.

La conseguenza del processo manuale è duplice. Da una parte il team deve ricordare perché una trattativa è stata persa e scegliere ogni volta cosa fare; dall’altra, quando questa informazione non guida l’automazione, il follow-up rischia di essere generico o fuori contesto.

HighLevel mette a disposizione il trigger di workflow Pipeline Stage Changed, pensato per eseguire azioni quando un’opportunità si sposta da una fase a un’altra della pipeline. La documentazione ufficiale indica che il trigger può essere filtrato per pipeline, fase, assegnatario, valore del lead, tag, stato e motivo di perdita. In questo tutorial lo usiamo in uno scenario ipotetico: un team vuole distinguere le opportunità perse per vincoli di budget da quelle perse per altri motivi, senza attribuire questa procedura a un cliente reale.

Il perimetro è importante: la fonte descrive il trigger e le azioni disponibili, non una strategia universale di recupero. Le scelte su messaggio, frequenza e destinatari sono quindi consigli editoriali, da adattare a consenso, processo commerciale e contesto. Per capire quando adottare questo evento rispetto ad altri, può essere utile la nostra guida ai trigger HighLevel.

La situazione di partenza

Risposta breve: se tutte le opportunità perse ricevono lo stesso flusso, il motivo della chiusura resta un dato raccolto ma non utilizzato.

Immaginiamo una pipeline commerciale con una fase finale di perdita. Il responsabile controlla periodicamente le opportunità chiuse senza vendita, ma l’operatività quotidiana segue un’altra strada: si esportano liste, si chiedono chiarimenti ai commerciali, si aggiungono tag manuali oppure si inseriscono contatti in campagne di nurture indistinte.

Non tutte le perdite hanno però lo stesso significato operativo. La fonte ufficiale di GoHighLevel riporta esempi di motivi come “Price Too High”, “Competitor Chosen” e “No Response”. Un vincolo di budget, la scelta di un concorrente e l’assenza di risposta non giustificano necessariamente la medesima comunicazione né lo stesso compito interno.

Qui la relazione tra elementi è lineare:

• HighLevel è il CRM e ambiente di automazione in cui vivono opportunità, pipeline e workflow;
• lo strumento centrale è il trigger Pipeline Stage Changed;
• il settore non è vincolato: lo schema si applica dove una pipeline registra opportunità e ragioni di perdita;
• il risultato operativo è una regola di ingresso più precisa: entrano nel workflow solo le opportunità coerenti con pipeline, stato, fase e motivo selezionati.

Questo approccio può essere pertinente anche per chi gestisce più processi. Per esempio, un’attività con pipeline differenti per richieste, preventivi o altri percorsi non dovrebbe far partire automaticamente un recupero da una pipeline non coinvolta. Lo stesso principio di separazione dei processi è utile quando si progettano pipeline per ristoranti, dalle richieste evento alla conferma finale.

Cosa cambia con HighLevel

Risposta breve: il cambio di fase diventa l’evento che avvia il workflow, mentre i filtri stabiliscono quali opportunità meritano davvero quell’automazione.

Secondo la documentazione ufficiale di HighLevel sul trigger Pipeline Stage Changed, il trigger si attiva quando un’opportunità passa da una fase a un’altra in una pipeline di vendita. Può intercettare avanzamenti, regressioni e riassegnazioni a una nuova fase.

Nel caso di un’opportunità persa, non basta quindi dire “avvia qualcosa quando cambia la pipeline”. La precisione arriva dalla combinazione dei filtri descritti nella fonte:

• In Pipeline limita l’automazione a una pipeline specifica;
• Pipeline Stage la vincola al passaggio verso una fase definita;
• Status consente di scegliere lo stato corrente, tra Open, Won, Lost e Abandoned;
• Lost Reason entra in gioco quando l’opportunità è segnata come Lost e ha uno specifico motivo assegnato;
• Assigned To, Tag e Lead Value permettono ulteriori segmentazioni quando rilevanti per il processo.

Il cambiamento pratico non è la promessa di recuperare automaticamente una trattativa. È poter costruire una regola del tipo: “quando un’opportunità della pipeline selezionata passa alla fase di perdita, ha stato Lost e motivo Budget Constraints, esegui queste azioni”. La fonte usa proprio l’esempio di un follow-up email che propone un piano tariffario flessibile per il motivo “Budget Constraints”.

Consiglio editoriale: prima di automatizzare, definite internamente una lista di motivi di perdita che il team possa applicare con coerenza. Se la stessa condizione viene registrata talvolta come “budget”, talvolta come “prezzo” e talvolta non viene indicata, il filtro non può offrire segmentazione affidabile. Questo non richiede di creare nuove funzioni: richiede una convenzione operativa nell’uso della pipeline.

Per chi assegna attività e responsabilità commerciali, il filtro Assigned To può inoltre evitare che le notifiche arrivino a persone non coinvolte. Il tema si collega alla gestione ordinata della presa in carico descritta in Agenzia: assegnare i lead in round-robin con Assign To User.

Come configurare il flusso

Risposta breve: create o modificate un workflow, selezionate Pipeline Stage Changed, restringete l’ingresso con i filtri disponibili, definite le azioni e pubblicate solo dopo un test controllato.

I passaggi seguenti riprendono le indicazioni della fonte ufficiale. Non costituiscono una verifica diretta dell’interfaccia: menu, etichette, nomi e disponibilità delle opzioni possono cambiare dopo la data di consultazione della documentazione.

1. Accedere a Workflow Builder. Nella dashboard CRM, la fonte indica il percorso Automation > Workflows. Da qui è possibile creare un nuovo workflow oppure modificare uno esistente.

2. Aggiungere il trigger. Selezionate + Add New Trigger, cercate Pipeline Stage Changed nell’elenco e sceglietelo come trigger del workflow.

3. Dare un nome descrittivo al trigger. HighLevel raccomanda un nome chiaro che ne renda riconoscibile la funzione durante la gestione di più automazioni. Un nome operativo potrebbe richiamare pipeline, stato e motivo, senza pretendere che esista una nomenclatura obbligatoria.

4. Impostare il perimetro della pipeline. Applicate il filtro In Pipeline e selezionate la pipeline a cui deve essere limitata l’automazione. Questo passaggio riduce il rischio che il flusso intervenga in processi estranei.

5. Indicare fase e stato di perdita. Usate il filtro Pipeline Stage per definire la fase coinvolta nel passaggio e il filtro Status scegliendo Lost. La documentazione chiarisce che Lost identifica una trattativa non convertita in vendita.

6. Selezionare il Lost Reason. Configurate Lost Reason con il motivo per cui volete rendere pertinente il follow-up. L’esempio ufficiale è “Budget Constraints”: il workflow viene attivato quando l’opportunità è marcata Lost e viene assegnata quella ragione specifica.

7. Aggiungere filtri soltanto se servono. Se il processo lo richiede, potete combinare più filtri. La fonte conferma che i filtri possono essere usati insieme, per esempio pipeline, fase e assegnatario. Tag e valore del lead sono ulteriori condizioni disponibili. Consiglio editoriale: aggiungete una condizione solo quando sapete chi la valorizza e con quale regola; un filtro non popolato correttamente può escludere casi che volevate gestire.

8. Definire le azioni successive. La fonte elenca varie azioni possibili: inviare una notifica, aggiornare dettagli dell’opportunità come stato, priorità o tag, creare un’attività di follow-up, attivare un altro workflow o inviare un’email al contatto. Per il caso “vincoli di budget”, l’esempio ufficiale è un’email automatica su un piano flessibile. Consiglio editoriale: scegliete un’azione compatibile con il motivo registrato; una notifica interna o un task possono essere più appropriati di una comunicazione automatica quando serve una valutazione umana.

9. Salvare, pubblicare e testare. La guida indica di fare clic su Save Trigger, verificare gli step del workflow e poi su Publish. Suggerisce di testare spostando manualmente un’opportunità tra le fasi per confermare il comportamento atteso. Il test è rilevante perché anche un movimento manuale attiva il workflow se le condizioni configurate sono soddisfatte.

Il risultato operativo

Risposta breve: l’automazione non tratta “persa” come un’unica categoria, ma esegue le azioni previste solo alla corrispondenza delle condizioni impostate.

Dopo la pubblicazione e il test, un’opportunità della pipeline scelta che passa alla fase selezionata, ha stato Lost e riceve il Lost Reason configurato può attivare il workflow. In base alle azioni definite, HighLevel può inviare un’email, creare un task, aggiornare dati dell’opportunità, notificare il team o avviare un altro workflow.

Questo è il risultato che si può verificare nel flusso: controllare che una transizione con le condizioni corrette avvii l’automazione e che una transizione priva del motivo richiesto non vi entri. Non è invece possibile dedurre dalla configurazione un tasso di recupero, una risposta del contatto o un risultato economico: tali esiti dipendono da fattori che la fonte non misura.

La documentazione precisa anche che il trigger è indipendente da altri trigger legati alle opportunità, quali Opportunity Status Changed e Opportunity Created. Se il processo richiede più eventi, possono essere configurati workflow con trigger diversi. In caso di ritorno a una fase precedente, il trigger può attivarsi di nuovo se le condizioni corrispondono; non serve invece per tracciare lo storico dei cambi di fase, che può essere consultato nel registro attività dell’opportunità.

Errori e limiti

Risposta breve: il filtro Lost Reason migliora la selezione, ma dipende dalla qualità dei dati e non sostituisce una decisione commerciale.

Il primo errore è costruire un workflow per tutte le opportunità perse senza combinare almeno il motivo di perdita con il contesto di pipeline e stato. Il risultato può essere un follow-up generico, cioè esattamente il problema iniziale.

Il secondo è aspettarsi che il trigger distingua da solo le perdite. La fonte afferma che un motivo deve essere assegnato quando l’opportunità passa a Lost: se il team non lo registra, non esiste la condizione specifica che il filtro deve intercettare.

Il terzo è ignorare le regressioni. Poiché il trigger può scattare nuovamente quando un’opportunità torna a una fase precedente e le condizioni coincidono, consiglio editoriale: valutate il flusso anche in questi percorsi, soprattutto prima di aggiungere comunicazioni al contatto.

Infine, non confondete visibilità in tempo reale con storico completo. Il trigger reagisce alle transizioni in tempo reale; la fonte indica che i movimenti storici vanno consultati nell’activity log dell’opportunità. Se il responsabile continua a rincorrere manualmente trattative e motivazioni, l’automazione può ridurre l’inseguimento solo nella misura in cui pipeline, stato e Lost Reason vengono mantenuti con disciplina. I risultati variano quindi in base al contesto, alla qualità dei dati e alle azioni decise dal team.

Per approfondire l’uso operativo di HighLevel e ricevere materiali aggiuntivi, visita il bonus WhatsApp GoHighLevel.