Multi-sede: notificare il team quando arriva una nuova recensione con HighLevel

TL;DR: quando una nuova recensione arriva in un'attività con più sedi, il problema non è solo accorgersene: è fare in modo che l'alert raggiunga il team che può gestire quella specifica sede. La documentazione ufficiale di HighLevel indica che il trigger New Review Received avvia un workflow quando arriva una nuova recensione in Reviews/Reputation. Da qui si può progettare un flusso operativo per notificare e assegnare internamente l'evento, ma la fonte non descrive filtri per sede, azioni di notifica o regole di assegnazione: questi elementi vanno verificati nel proprio account prima della pubblicazione.

In sintesi

• Cosa cambia: invece di controllare manualmente Reviews/Reputation o inoltrare segnalazioni tra colleghi, un workflow può partire al ricevimento della recensione.
• A chi serve: titolari, responsabili operativi e team marketing/reputation di organizzazioni con più sedi e referenti distinti.
• Risultato operativo verificabile: ogni nuova recensione può diventare un evento visibile nel processo interno, con una regola definita per individuare il team responsabile.
• Punto da non saltare: HighLevel mette a disposizione il trigger; il collegamento tra recensione, sede e incaricato richiede una struttura dati e una verifica concreta delle opzioni disponibili nell'interfaccia.

La fonte ufficiale è l'articolo HighLevel Support Portal, A List of Workflow Triggers. I nomi dei menu, dei trigger e la loro disponibilità possono cambiare dopo la data di verifica della documentazione.

La situazione di partenza

Risposta breve: nelle attività multi-sede, una recensione non gestita è spesso una recensione che nessuno sapeva di dover prendere in carico.

Immaginiamo uno scenario ipotetico: un responsabile coordina diverse sedi, ciascuna con il proprio team. Arriva una nuova recensione. Se il controllo avviene a mano, il responsabile deve ricordarsi di entrare nell'area reputazione, capire a quale sede si riferisce l'evento, avvisare la persona competente e poi verificare che qualcuno abbia risposto.

Il lavoro manuale sembra lineare finché il volume è limitato. Con più sedi, però, le conseguenze operative sono ricorrenti: l'alert resta nella casella o nel canale sbagliato; più persone pensano che risponderà qualcun altro; il responsabile centrale diventa un passaggio obbligato; la sede che ha il contesto della recensione viene coinvolta tardi.

Non è un problema risolvibile semplicemente con una notifica generica. Il messaggio “è arrivata una recensione” non assegna una responsabilità. Per essere utile, l'evento deve entrare in un flusso che risponda a tre domande: quale sede è coinvolta, chi è incaricato di leggerla e dove il team deve trovare le istruzioni o la richiesta di gestione.

Qui è importante distinguere i fatti ufficiali dalla progettazione editoriale. La documentazione fornita non spiega come HighLevel identifichi o filtri una sede nel trigger recensioni, né quali dati della recensione siano disponibili nelle azioni successive. Descrive invece con chiarezza il fatto iniziale: New Review Received si attiva quando arriva una nuova recensione in Reviews/Reputation.

Cosa cambia con HighLevel

Risposta breve: HighLevel consente di usare la ricezione di una recensione come avvio di un workflow, non come promemoria da intercettare manualmente.

Nel Workflow Builder di HighLevel, i trigger sono eventi che avviano i workflow; le azioni seguono il trigger ed eseguono le attività previste, nell'ordine cronologico impostato. È questa la relazione da tenere a mente:

1. Reviews/Reputation è il contesto in cui arriva la recensione.
2. New Review Received è l'evento che può attivare il workflow.
3. Workflow Builder è il luogo in cui si definisce la sequenza successiva.
4. Il team della sede è il destinatario operativo che l'azienda deve associare all'evento secondo la propria organizzazione.

L'uso del trigger non equivale, da solo, a una risposta automatica pubblica alla recensione. La fonte non afferma che il trigger pubblichi risposte, selezioni un proprietario della sede o assegni automaticamente un utente. Affermare il contrario sarebbe improprio.

Il cambiamento concreto è quindi più circoscritto e più utile: la nuova recensione può diventare un segnale che entra in un processo ripetibile. Invece di dipendere da una persona che controlla, il team può definire in anticipo come ricevere, classificare e prendere in carico l'evento.

Per un'organizzazione multi-sede, il valore non nasce dal moltiplicare gli alert. Nasce dalla coerenza tra il criterio di instradamento e la responsabilità reale. Se una sede ha autonomia di risposta, la notifica dovrebbe arrivare al suo referente. Se esiste un reparto centrale di reputation management, la sede può essere inclusa solo quando serve il suo contesto. Questa è una scelta organizzativa editoriale, non una funzione specifica confermata dalla fonte.

Come configurare il flusso

Risposta breve: il passaggio ufficiale certo è selezionare il trigger New Review Received; l'instradamento per sede va progettato e verificato nel proprio ambiente.

1. Definire prima la regola di proprietà della recensione

Consiglio editoriale: prima di creare il workflow, documentate una regola semplice e leggibile. Per esempio: “ogni sede ha un referente recensioni e un sostituto”, oppure “il team centrale riceve tutte le recensioni e coinvolge la sede identificata”.

Non iniziate dal canale di notifica. Iniziate dalla responsabilità. Un alert inviato rapidamente alla persona sbagliata continua a generare rincorse manuali.

Definite anche il dato con cui riconoscerete la sede nel processo: nome della sede, codice interno, gruppo di utenti o altra convenzione effettivamente disponibile nella vostra configurazione. La fonte non indica quale campo o filtro usare, quindi non è possibile prescrivere una modalità unica.

2. Creare il punto di ingresso nel Workflow Builder

Secondo la documentazione ufficiale, i trigger sono organizzati per categorie per facilitarne la ricerca. Per trovarli, occorre entrare in Workflows, selezionare “add a trigger” e usare il menu Trigger che si apre.

Nel catalogo ufficiale compare il trigger New Review Received, descritto così: si attiva quando una nuova recensione arriva in Reviews/Reputation.

Questo è il punto di ingresso da selezionare per il caso d'uso. Non confondetelo con Product Review Submitted, che nel catalogo è indicato nella categoria Ecommerce Stores e riguarda le recensioni di prodotto: per la gestione reputazionale delle sedi, il trigger pertinente nella fonte è New Review Received.

3. Disegnare l'instradamento, senza presumere funzioni non documentate

Consiglio editoriale: rappresentate il flusso su carta prima di aggiungere azioni. Una struttura logica può essere:

• arriva una nuova recensione;
• il processo determina, secondo la vostra regola, la sede o il gruppo responsabile;
• il team riceve un alert interno;
• una persona prende in carico la risposta;
• il responsabile può controllare che il passaggio sia avvenuto.

La fonte stabilisce solo l'avvio tramite trigger e il principio generale per cui le azioni seguono il trigger. Non fornisce istruzioni sulle azioni da scegliere per inviare notifiche, creare attività, cambiare assegnatari, gestire rami condizionali o usare dati della recensione nel messaggio. Perciò questi passaggi vanno trattati come requisiti da verificare, non come clic garantiti.

Prima di pubblicare il workflow, controllate nell'interfaccia attuale quali azioni sono disponibili nel vostro piano e nella vostra configurazione, quali informazioni possono essere passate all'alert e se potete costruire una condizione affidabile per sede. Se un dato non è disponibile, non basate l'automazione su quel dato.

4. Rendere l'alert utile a chi deve agire

Consiglio editoriale: un alert interno dovrebbe consentire al destinatario di capire subito che esiste un evento e quale sia il prossimo passaggio previsto. Evitate di trasformarlo in una risposta precompilata o in una promessa di tempi, se il team non ha una procedura approvata.

Stabilite inoltre un punto di controllo: chi interviene se l'incaricato è assente? Come si registra la presa in carico? Quando la sede deve fornire informazioni al team centrale? Queste regole non sono automatismi di HighLevel descritti dalla fonte, ma impediscono che il workflow trasferisca soltanto il problema da una schermata a un'altra.

Se usate altri workflow per contatti o conversazioni, mantenete separato il processo reputazionale dalle automazioni commerciali. In particolare, quando un operatore entra in una conversazione, può essere utile conoscere il principio trattato nel nostro approfondimento su come fermare le automazioni e preservare la conversazione. La configurazione concreta deve comunque rispettare le opzioni presenti nel vostro account.

5. Verificare il processo con casi rappresentativi

Consiglio editoriale: testate la logica con esempi che coprano almeno una recensione per sede, una sede con referente assente e un evento non immediatamente attribuibile. Lo scopo non è certificare che l'interfaccia faccia qualcosa che la fonte non documenta, ma verificare che la vostra regola organizzativa sia comprensibile e che l'alert arrivi nel punto previsto.

Conservate una breve procedura interna per il team: chi riceve, chi risponde, chi supervisiona. L'automazione parte da un evento; la qualità della gestione resta una responsabilità umana.

Il risultato operativo

Risposta breve: il risultato verificabile è un processo in cui una nuova recensione attiva un workflow e viene portata all'attenzione del team definito dalla vostra regola di sede.

Il titolare non deve più affidarsi esclusivamente alla memoria di chi controlla Reviews/Reputation. Il team può lavorare su una responsabilità esplicita: una nuova recensione genera un evento, l'evento viene trattato secondo una mappa multi-sede e la presa in carico ha un proprietario.

Questo non dimostra né garantisce tempi di risposta migliori, più recensioni positive o effetti commerciali: la fonte non fornisce risultati di questo tipo. Dimostra invece una cosa che potete controllare internamente: il trigger selezionato è New Review Received, il workflow è pubblicato secondo le opzioni disponibili e il percorso di notifica/assegnazione corrisponde alla procedura definita.

La stessa disciplina di instradamento è utile anche in altri processi multi-sede. Ad esempio, nelle richieste che arrivano fuori area, la regola di responsabilità viene prima del messaggio: approfondite il tema in Servizi per la casa: gestire richieste fuori zona con Form Submitted.

Errori e limiti

Risposta breve: l'errore principale è scambiare un trigger per un sistema completo di assegnazione e risposta.

Ecco gli errori da evitare.

• Usare il trigger sbagliato. Product Review Submitted e New Review Received hanno descrizioni diverse nel catalogo ufficiale. Per l'arrivo di una recensione in Reviews/Reputation, la fonte indica New Review Received.
• Non decidere chi possiede l'evento. Se una recensione viene inviata a un gruppo indistinto, la notifica può generare ambiguità invece di eliminarla.
• Assumere che la sede sia sempre identificabile. La fonte non documenta filtri, campi o ramificazioni per sede. Verificate la disponibilità reale dei dati prima di costruire condizioni.
• Promettere risposte automatiche. Il trigger avvia un workflow; non è una prova che HighLevel risponda pubblicamente o assegni un addetto senza ulteriori configurazioni disponibili.
• Mescolare procedure e canali senza controllo. Se l'alert raggiunge un canale non presidiato, il flusso resta tecnicamente avviato ma operativamente inefficace.
• Ignorare il fuso orario e la reperibilità. Se il vostro workflow include messaggi o avvisi in orari sensibili, valutate le regole operative e consultate anche Fasce orarie dei workflow HighLevel.

Il limite centrale della fonte è altrettanto chiaro: è un catalogo dei trigger, non una guida completa alla configurazione di un sistema multi-sede per le recensioni. Offre il fatto iniziale affidabile — l'arrivo di una nuova recensione può attivare un workflow — ma non definisce l'architettura di assegnazione, i destinatari, le azioni o la governance interna.

In definitiva, il problema quotidiano non è soltanto “arriva una recensione”. È sapere chi la vede e chi se ne occupa. Usate New Review Received come punto di ingresso ufficiale e costruite attorno a quel punto una responsabilità verificabile, senza attribuire all'automazione decisioni che la vostra organizzazione non ha ancora definito.

Per altri materiali operativi su HighLevel, potete partire dal bonus WhatsApp GoHighLevel. I risultati variano in base a struttura multi-sede, configurazione disponibile, canali scelti e procedure del team.