Ristorante: recuperare una prenotazione segnata come no-show con HighLevel

TL;DR: quando una prenotazione viene segnata come No-show, il responsabile di un ristorante rischia di accorgersene troppo tardi o di gestirla insieme a cancellazioni e presenze. In HighLevel, il trigger Appointment Status può avviare un workflow quando cambia lo stato dell’appuntamento e può essere filtrato sul solo stato No-show. Il risultato operativo verificabile è semplice: un contatto associato a una prenotazione marcata come no-show entra nel workflow previsto, senza confondere quel caso con una cancellazione o con una visita effettuata.

In sintesi

Un no-show non è una cancellazione e non è una presenza. Per un ristorante, trattare questi tre esiti nello stesso processo rende più difficile capire quale prenotazione richieda un ricontatto e quale, invece, non debba ricevere ulteriori comunicazioni.

HighLevel mette a disposizione il trigger di workflow Appointment Status, che si attiva quando un appuntamento viene programmato o quando il suo stato viene aggiornato. Tra gli stati filtrabili ci sono New, Confirmed, Cancelled, Showed, No-show e Invalid. Nel caso descritto, il filtro sullo stato No-show è l’elemento che separa il recupero di una mancata presentazione dagli altri percorsi.

Questo tutorial è rivolto a titolari, responsabili di sala e team che gestiscono prenotazioni attraverso i calendari di GoHighLevel. Lo scenario è ipotetico: immaginiamo un ristorante che voglia predisporre un flusso distinto per le prenotazioni segnate come no-show, senza attribuire questo processo o risultati a un cliente reale.

La fonte ufficiale non descrive il testo, il canale o la sequenza esatta del ricontatto. Descrive però come impostare il trigger e i suoi filtri. Di conseguenza, qui distinguiamo i passaggi documentati da HighLevel dai consigli editoriali per progettare un recupero misurato.

La situazione di partenza

Risposta breve: il problema nasce quando il no-show viene gestito come una semplice nota da ricordare, anziché come uno stato operativo distinto.

Alla fine del servizio, chi coordina le prenotazioni può avere davanti una lista di appuntamenti con esiti diversi: chi ha confermato e si è presentato, chi ha cancellato, chi ha cambiato programma e chi non si è presentato. Se il controllo è manuale, il team deve individuare i no-show, decidere se ricontattarli, farlo nel momento adatto e annotare ciò che è stato già gestito.

Il processo manuale produce almeno tre conseguenze pratiche. La prima è la discontinuità: il recupero dipende dal tempo disponibile di una persona. La seconda è la confusione tra stati diversi: una cancellazione può richiedere un trattamento differente rispetto a un no-show, mentre una presenza non dovrebbe entrare nel percorso di recupero. La terza è il rischio di comunicazioni incoerenti, per esempio se più persone lavorano sullo stesso elenco senza un criterio condiviso.

Il punto non è inviare più messaggi. È fare in modo che il processo inizi solo dopo un aggiornamento di stato pertinente. Nel linguaggio di HighLevel, il calendario registra l’appuntamento; il trigger Appointment Status osserva la creazione o il cambiamento di stato; il workflow accoglie il contatto definito dalla configurazione. Per un ristorante, il risultato operativo è poter associare il recupero alla condizione precisa di mancata presenza.

Prima di lavorare sul no-show, conviene distinguere questo flusso da quello che segue la prenotazione appena acquisita. Per quella fase può essere utile il nostro approfondimento su conferma automatica e istruzioni dopo la prenotazione: la conferma iniziale e il recupero dopo no-show rispondono a momenti diversi del rapporto con il contatto.

Cosa cambia con HighLevel

Risposta breve: HighLevel consente di usare lo stato dell’appuntamento come condizione di ingresso, invece di cercare manualmente i no-show dopo il servizio.

Secondo la documentazione ufficiale di HighLevel sul trigger Appointment Status, il trigger avvia workflow quando un appuntamento è programmato oppure quando il suo stato cambia. I filtri permettono di circoscrivere il comportamento dell’automazione.

Nel caso di un ristorante, la distinzione fondamentale è il filtro Appointment Status impostato su No-show. La stessa funzionalità elenca anche gli stati Cancelled e Showed: questo permette di configurare percorsi differenti per prenotazioni cancellate, presenze e mancate presentazioni, anziché farle confluire tutte nello stesso workflow.

La fonte indica inoltre che si può scegliere chi iscrivere al workflow:

• Contact only, impostazione predefinita, iscrive solo il contatto principale dell’appuntamento;
• Contact and Guests iscrive sia il contatto principale sia tutti gli ospiti, con un’esecuzione separata per ciascuna persona;
• Guests only esclude il contatto principale e iscrive soltanto gli ospiti.

Questa scelta non è un dettaglio tecnico secondario. Se la prenotazione contiene ospiti, l’opzione selezionata determina chi entra effettivamente nel flusso. La documentazione conferma che ogni esecuzione è indipendente quando vengono inclusi contatto e ospiti.

Un ulteriore cambiamento è la possibilità di limitare il trigger al calendario o al gruppo di calendari rilevante. Un ristorante che usa più calendari può così evitare, in linea di principio, che una regola destinata a una specifica tipologia di prenotazione si attivi su appuntamenti non pertinenti. HighLevel offre i filtri In Calendar, In Calendar Group e Only for Grouped Calendar proprio per delimitare l’ambito del trigger.

Come configurare il flusso

Risposta breve: create o modificate un workflow, aggiungete Appointment Status, scegliete chi iscrivere e filtrate lo stato su No-show prima di salvare e pubblicare.

Di seguito sono riportati i passaggi esplicitamente indicati dalla documentazione ufficiale. I nomi delle voci e la loro disponibilità possono cambiare dopo la data di verifica riportata nella fonte; verificate quindi l’interfaccia del vostro account prima della pubblicazione.

1. Accedete al Workflow Builder. In HighLevel, andate nella sezione Automation, selezionate Workflows e scegliete + Create Workflow oppure aprite un workflow esistente.

2. Aggiungete il trigger. Fate clic su Add New Trigger, cercate Appointment Status e selezionatelo.

3. Assegnate un nome descrittivo al trigger. La fonte suggerisce di evitare il nome predefinito quando non è sufficientemente chiaro. Per questo scenario, un nome come “Ristorante – no-show – ingresso recupero” rende leggibile lo scopo della regola. Questo è un consiglio di organizzazione editoriale, non un requisito tecnico dichiarato dalla piattaforma.

4. Scegliete chi entra nel workflow. Valutate se il recupero debba coinvolgere solo il contatto principale, contatto e ospiti, oppure solo gli ospiti. La scelta deve rispecchiare il vostro obiettivo e le vostre procedure di gestione della prenotazione. Se selezionate Contact and Guests, ricordate che il workflow viene eseguito separatamente per ogni persona.

5. Impostate il filtro sullo stato. Nel filtro Appointment Status, selezionate No-show. Questo è il passaggio che rende il workflow dedicato alla mancata presentazione, separandolo da Cancelled e Showed.

6. Applicate altri filtri solo se servono al perimetro. La fonte elenca i filtri per tipo di evento (Any, Normal, Recurring), tag del contatto, calendario, gruppo di calendari, calendari raggruppati e soggetto che ha modificato lo stato. I filtri possono essere combinati con condizioni AND/OR.

   In particolare, Modified By può distinguere modifiche effettuate da API, cliente, utente o altro workflow. Se scegliete l’opzione utente, la documentazione indica che potete selezionare il singolo utente CRM che deve aver effettuato la modifica. Non aggiungete questa condizione per abitudine: usatela solo se il vostro criterio operativo richiede di distinguere l’origine dell’aggiornamento.

7. Salvate e attivate. Fate clic su Save per memorizzare il trigger, quindi salvate e pubblicate il workflow per attivare l’automazione. La documentazione raccomanda di testare prenotando un appuntamento e verificando che il workflow venga eseguito come previsto.

La fonte non dettaglia le singole azioni successive al trigger. Perciò non è corretto presentare una particolare sequenza di messaggi o di attività interne come configurazione ufficiale. Il consiglio editoriale è definire prima, con il team, cosa debba significare “recuperare”: una richiesta di risposta, un invito a riprenotare oppure una presa in carico interna. Solo dopo potete costruire nel workflow azioni coerenti con quella decisione e con le vostre regole di contatto.

Se il recupero prevede una conversazione, è utile predisporre anche chi la gestisce quando arriva una risposta. Il tutorial su Customer Replied e passaggio della conversazione al team aiuta a collegare l’automazione iniziale alla presa in carico umana. Se invece sono previsti follow-up, valutate con attenzione come interromperli alla risposta: vedere Stop on Response in HighLevel.

Il risultato operativo

Risposta breve: quando una prenotazione pertinente viene aggiornata a No-show, HighLevel può iscrivere nel workflow il soggetto scelto nella configurazione.

Questo è il risultato verificabile promesso dal trigger: non la certezza che la persona torni al ristorante, non un tasso di recupero, ma l’avvio ordinato di un processo collegato a uno stato specifico dell’appuntamento.

Il responsabile non deve quindi partire dall’elenco generale delle prenotazioni per identificare ogni mancata presentazione. Il workflow crea una separazione operativa tra:

• prenotazioni cancellate, per cui può esistere un percorso distinto;
• prenotazioni showed, che possono alimentare attività diverse dal recupero, come la richiesta di recensione dopo la visita;
• prenotazioni no-show, che entrano nel flusso progettato per quel caso.

Questa separazione rende più leggibile il processo e può migliorare il coordinamento, perché i team lavorano su criteri di stato espliciti. Il trigger supporta anche appuntamenti con più partecipanti, ma il team deve essere consapevole che l’inclusione di ospiti genera esecuzioni indipendenti.

Errori e limiti

Risposta breve: il trigger è preciso quanto lo sono lo stato registrato, i filtri scelti e la definizione interna del processo.

Il primo errore è configurare un workflow senza filtrare Appointment Status = No-show. In quel caso, il trigger può reagire ad altri stati dell’appuntamento e non soltanto alla mancata presenza.

Il secondo è trattare una riprogrammazione come se fosse automaticamente un no-show. La FAQ ufficiale chiarisce che, quando un appuntamento viene riprogrammato, viene trattato come nuovo e il contatto rientra nel workflow dall’inizio. Questa logica va considerata nella progettazione per evitare interpretazioni errate del comportamento del flusso.

Il terzo errore è includere contatto e ospiti senza valutare l’effetto operativo: HighLevel esegue il workflow una volta per il contatto principale e una volta per ciascun ospite. Se il recupero deve riguardare una sola persona di riferimento, Contact only potrebbe essere la scelta più adatta; è una valutazione di processo, non una prescrizione universale.

Il quarto limite riguarda l’origine del dato. L’automazione si basa sull’aggiornamento dello stato dell’appuntamento. Se il no-show non viene segnato nel calendario o viene assegnato uno stato diverso, il trigger filtrato su No-show non avrà quella condizione da intercettare.

Infine, non confondete automazione e qualità della relazione. HighLevel può rendere il passaggio più coerente e tempestivo, ma non definisce da solo tono, consenso, frequenza dei contatti o modalità di presa in carico. Tornando al problema iniziale, l’obiettivo non è eliminare il giudizio del responsabile di sala: è evitare che una prenotazione segnata correttamente come no-show resti invisibile in un processo manuale.

Per approfondire l’uso operativo di GoHighLevel e ricevere risorse dedicate, potete consultare il bonus WhatsApp GoHighLevel. I risultati variano in base al contesto, alla qualità dei dati e alla configurazione del team.