Ristorante: chiedere una recensione dopo la visita senza essere invadenti

TL;DR: quando la richiesta di recensione viene gestita a mano, il ristorante rischia due estremi: dimenticarsene oppure contattare l’ospite nel momento sbagliato. In HighLevel, l’azione Review Request consente di inviare una richiesta di feedback o recensione a un contatto via canale selezionato, come email e, dove disponibile, SMS. Per un ristorante, il risultato operativo verificabile è semplice: dopo un evento che rappresenta la visita conclusa, il workflow può inviare un solo invito configurato nelle Reputation Settings. Il tono, il momento effettivo e le regole interne restano decisioni del locale.

In sintesi

La richiesta funziona meglio quando arriva come naturale seguito della visita, non come sollecito ripetuto. HighLevel mette a disposizione la Workflow Action Review Request per chiedere a un contatto feedback o una recensione. La documentazione ufficiale indica che l’azione può essere configurata scegliendo il tipo di richiesta — per esempio E-mail e potenzialmente altri canali, come SMS — mentre il testo del messaggio viene impostato nelle Reputation Settings.

Questo tutorial riguarda uno scenario ipotetico: un responsabile di ristorante vuole sostituire il promemoria manuale post-visita con un flusso coerente. Non descrive un caso cliente né promette un aumento di recensioni, punteggi o prenotazioni. Serve invece a chiarire la relazione tra i quattro elementi: il servizio concluso nel ristorante, un’attesa decisa dal team, il workflow di HighLevel e un solo invito alla recensione.

La fonte di riferimento è la guida ufficiale HighLevel, Workflow Action – Review Request, indicata come modificata il 4 settembre 2024. La data della fonte di partenza non è indicata separatamente; nomi delle voci, canali e disponibilità possono cambiare dopo la data di verifica.

La situazione di partenza

Il problema quotidiano non è scrivere “lasciaci una recensione”, ma ricordarsi a chi inviarlo e quando. A fine servizio, il titolare o il responsabile può essere impegnato tra sala, cassa, prenotazioni e richieste dell’ultimo minuto. Se la raccolta delle recensioni dipende da un gesto manuale, alcuni ospiti non ricevono nulla, altri possono essere contattati in modo non uniforme e il team non ha un passaggio ripetibile da seguire.

In un ristorante, questa frammentazione ha una conseguenza pratica: il messaggio post-visita non è collegato con chiarezza a un evento concluso. Può partire troppo presto, molto tempo dopo, oppure essere inviato più volte da persone diverse. Nessuno di questi esiti è automaticamente evitato dalla tecnologia: occorre prima definire cosa, nel processo del locale, segnala davvero che la visita è terminata.

Lo scenario ipotetico è quindi questo: il ristorante dispone di contatti registrati e di un processo che può generare un evento utilizzabile in un workflow. Il responsabile vuole che, dopo tale evento e dopo un’attesa appropriata stabilita internamente, parta un solo invito chiaro. Non si tratta di trasformare ogni messaggio in una campagna: l’obiettivo è rendere eseguibile un’operazione già scelta dal locale.

Cosa cambia con HighLevel

HighLevel separa l’invio della richiesta dal contenuto del messaggio: il workflow esegue l’azione, mentre le Reputation Settings ospitano il template. Secondo la documentazione ufficiale, la Review Request action invia a un contatto una richiesta di recensione. L’azione ha un nome, predefinito come “Send Review Request”, e richiede la selezione del Review Type.

Per il ristorante questo significa poter modellare un flusso lineare: un trigger rappresenta il servizio concluso; l’eventuale attesa colloca la comunicazione nel momento deciso dal team; l’azione Review Request invia la richiesta. La guida ufficiale mostra, come esempio, il trigger Appointment Completed, seguito dall’azione configurata per email.

È importante distinguere l’esempio dalla configurazione certa per ogni ristorante. La fonte non afferma che “Appointment Completed” sia necessariamente il trigger giusto per una visita al tavolo, né descrive come un gestionale di sala o di prenotazione alimenti HighLevel. Se quel trigger nel proprio account rappresenta effettivamente una visita conclusa, può essere valutato come riferimento; altrimenti il responsabile deve individuare, nel proprio processo, l’evento equivalente e verificare le integrazioni disponibili.

La guida indica E-mail tra le opzioni del Review Type e cita la possibilità di altri canali, per esempio SMS. Non è una conferma della disponibilità di ogni canale in ogni account o configurazione. In particolare, la fonte non descrive l’invio WhatsApp tramite questa specifica azione: non va quindi presentato come un passaggio confermato da questo tutorial.

Il beneficio operativo non è l’automazione indiscriminata. È avere un punto definito in cui l’invito viene preparato e inviato, con una formulazione controllata dal ristorante. Per impostare trigger, condizioni e azioni con maggiore metodo, può essere utile anche la nostra guida alle anteprime dei campi in trigger e azioni di HighLevel.

Come configurare il flusso

La configurazione ufficiale documentata è: scegliere un trigger, aggiungere Review Request, selezionare il tipo di richiesta e definire il messaggio nelle Reputation Settings. L’attesa tra visita e invito è una scelta editoriale e operativa del ristorante: la fonte non prescrive una durata specifica.

1. Definire l’evento di partenza. Il workflow deve iniziare da un trigger che il locale considera affidabile per identificare il servizio concluso. La documentazione propone “Appointment Completed” come esempio. Prima di adottarlo, il team dovrebbe verificare cosa significhi quell’evento nel proprio processo: una prenotazione conclusa non coincide automaticamente con una visita effettivamente terminata.

2. Decidere internamente se inserire un’attesa. Il tema dell’attesa appropriata è centrale per non risultare invadenti, ma HighLevel non impone un intervallo nella fonte disponibile. Il consiglio editoriale è documentare una regola semplice: l’invito non parte durante il servizio e non viene lasciato senza una logica temporale. La durata precisa dipende dall’organizzazione del ristorante e non viene indicata qui come prescrizione ufficiale.

3. Aggiungere l’azione Review Request. Nella guida ufficiale, il nome dell’azione può essere impostato; il valore predefinito è “Send Review Request”. Un nome descrittivo interno può aiutare il team a riconoscere lo scopo dell’azione quando il workflow viene aggiornato, ma non modifica il contenuto inviato al contatto.

4. Selezionare il Review Type. La fonte indica di scegliere il tipo di richiesta dal menu a discesa. L’esempio ufficiale seleziona “E-mail”; la documentazione cita anche canali potenzialmente ulteriori, come SMS. La scelta va effettuata soltanto tra le opzioni effettivamente visibili e disponibili nel proprio account.

5. Configurare il messaggio nelle Reputation Settings. Questo è il passaggio che la fonte collega esplicitamente al contenuto della richiesta. La guida suggerisce un template con tre elementi: un ringraziamento per l’appuntamento, una richiesta di feedback e un link alla piattaforma di recensioni. Nel caso del ristorante, il principio editoriale è adattare il ringraziamento alla visita, mantenere una sola richiesta e indicare con precisione la destinazione del link.

6. Mantenere un solo invito chiaro. Non è una funzione dichiarata della Review Request, ma una regola di comunicazione consigliata per questo scenario. Evitare di sovraccaricare il messaggio con altre offerte, domande o inviti diversi dalla recensione rende lo scopo riconoscibile. Prima di attivare il flusso, il team dovrebbe rileggere il template e verificare che il link previsto sia quello corretto.

Se il ristorante prevede in futuro altri messaggi di follow-up, è utile progettare con cautela la gestione delle risposte. Per il tema generale dell’interruzione delle sequenze quando un contatto risponde, rimandiamo a Stop on Response in HighLevel. Quella guida riguarda un’altra configurazione e non dimostra che la Review Request si comporti nello stesso modo: le logiche vanno controllate nel workflow effettivo.

Il risultato operativo

Il risultato verificabile è un flusso in cui la richiesta di recensione è associata a un evento concluso e inviata con il tipo selezionato e il template configurato. In pratica, il responsabile non deve ricordare manualmente ogni singolo invito dopo la visita, purché il trigger scelto venga alimentato correttamente e il workflow sia attivo secondo le impostazioni dell’account.

Il ristorante ottiene così un processo più leggibile: sa quale evento avvia il percorso, dove è definito il testo e quale azione invia la richiesta. Questo aiuta soprattutto nella gestione interna, quando più persone si occupano di prenotazioni, reputazione e comunicazioni.

Non è possibile dedurre dalla fonte quanti contatti riceveranno il messaggio, quanti lasceranno una recensione o quale sarà il suo contenuto. La Review Request raccoglie una richiesta di feedback o recensione; non garantisce la risposta del destinatario né un giudizio positivo. Anche la consegna dipende dal canale scelto e dalla configurazione concreta, aspetti che questa documentazione non dettaglia.

Errori e limiti

L’errore più comune è confondere una struttura di workflow con la garanzia che il messaggio sia opportuno, consegnato e accolto. Per evitare che il processo manuale iniziale venga semplicemente sostituito da un’automazione poco curata, considerate questi limiti.

• Usare un trigger non verificato. “Appointment Completed” è un esempio ufficiale, non una definizione universale di visita al ristorante. Se l’evento non corrisponde al servizio concluso, l’invito può arrivare fuori contesto.
• Inventare una tempistica standard. La fonte non prescrive minuti, ore o giorni di attesa. Il locale deve definire la propria regola e valutarne la coerenza con l’esperienza dell’ospite.
• Scrivere il messaggio nell’azione invece che nelle Reputation Settings. La guida attribuisce alle Reputation Settings la configurazione del template. Separare correttamente i due ruoli evita modifiche nel punto sbagliato.
• Dare per disponibili tutti i canali. Email è esplicitamente citata; SMS è menzionato come esempio di possibile altro canale. Le opzioni reali vanno controllate nel menu dell’account, senza assumere disponibilità ulteriori.
• Inviare più richieste senza una regola. La fonte descrive l’invio di una review request, non una strategia di ripetizione. Per l’obiettivo di non essere invadenti, la scelta editoriale più prudente è definire un solo invito nel flusso illustrato.
• Trascurare l’infrastruttura email. Se viene scelto l’invio via email, la configurazione del dominio è un tema separato dalla Review Request. Consulta la guida alla verifica dei domini GoHighLevel per evitare blocchi nell’invio email.

FAQ

La Review Request di HighLevel invia automaticamente una recensione?

No. Secondo la fonte ufficiale, invia al contatto una richiesta di feedback o recensione. La pubblicazione della recensione dipende dal destinatario.

Quale trigger deve usare un ristorante dopo la visita?

La fonte mostra “Appointment Completed” come esempio. Non stabilisce quale evento rappresenti la visita conclusa in ogni ristorante: questa corrispondenza va verificata nel processo e nelle integrazioni del singolo account.

Posso scegliere l’email per la richiesta di recensione?

Sì. L’email è indicata dalla documentazione come esempio di Review Type. Altri canali possono comparire tra le opzioni, ma la disponibilità va verificata nel proprio account.

Dove si modifica il testo dell’invito?

La fonte indica le Reputation Settings per configurare il contenuto del messaggio o template della review request.

HighLevel decide dopo quanto tempo inviare il messaggio?

La guida fornita non indica una tempistica obbligatoria. L’attesa appropriata deve essere stabilita dal ristorante in base al proprio processo.

Tornando al problema iniziale, il valore del flusso non è chiedere recensioni a tutti senza criterio: è impedire che una fase già delicata dipenda dalla memoria del responsabile durante il servizio. Se vuoi approfondire l’uso operativo di HighLevel per le comunicazioni, trovi risorse aggiuntive nel nostro bonus WhatsApp GoHighLevel. I risultati variano in base al contesto, ai dati disponibili, al canale e alla configurazione effettiva.