GoHighLevel: come aprire e gestire ticket di supporto per le app Marketplace

TL;DR: quando un’app di terze parti installata dal Marketplace crea un problema, inseguire email, form esterni e conversazioni separate rende difficile ricostruire cosa sia stato segnalato e quale sia lo stato della richiesta. HighLevel introduce ticket di supporto integrati per le app Marketplace: l’account agenzia principale può aprire una segnalazione dall’app installata, aggiungere dettagli e allegati, quindi seguire la conversazione in piattaforma e via email. Il risultato operativo verificabile è una cronologia centralizzata del ticket tra agenzia e sviluppatore. Non è una funzione disponibile agli utenti o agli amministratori dei sub-account.

In sintesi

La gestione ticket integrata riguarda il rapporto fra agenzia HighLevel, app di terze parti installata dal Marketplace e sviluppatore dell’app. Invece di usare canali di supporto separati, l’agenzia può inviare la richiesta dal contesto dell’app; lo sviluppatore la gestisce nel Developer Portal, nella sezione dedicata ai ticket.

Secondo il changelog ufficiale di HighLevel, il flusso include comunicazione bidirezionale, allegati, visibilità centralizzata dello stato e notifiche email per gli aggiornamenti. La funzione è utile soprattutto a chi, in agenzia, amministra le app installate e deve fornire allo sviluppatore informazioni ordinate sul malfunzionamento o sulla richiesta.

Questa guida distingue i passaggi dichiarati ufficialmente dai consigli editoriali per preparare segnalazioni più leggibili. Nomi delle voci, permessi e disponibilità possono cambiare dopo la data di verifica della fonte, 4 giugno 2026: prima di procedere, è opportuno confrontare la propria interfaccia con la documentazione e con il listing dell’app interessata.

La situazione di partenza

Risposta breve: il problema nasce quando il supporto dell’app è fuori dal luogo in cui l’agenzia la usa e la gestisce.

Immaginiamo uno scenario ricorrente, non riferito a un cliente reale: il responsabile di un’agenzia ha installato un’app Marketplace in GoHighLevel e deve segnalare un comportamento inatteso. Senza un punto di contatto integrato, la richiesta può finire in una casella email, in un form dello sviluppatore o in un altro sistema di assistenza. Nel frattempo screenshot, descrizione del caso e risposte successive rimangono distribuiti fra strumenti diversi.

La conseguenza pratica non è soltanto dover cambiare applicazione. Diventa più difficile capire se la segnalazione sia stata inviata, quale sia l’ultimo aggiornamento e quali file siano già stati condivisi. Anche lo sviluppatore riceve un contesto potenzialmente incompleto o separato dalla relazione con l’app Marketplace.

La fonte ufficiale descrive proprio questa precedente frammentazione: le interazioni di supporto per le app Marketplace avvenivano spesso tramite email o sistemi esterni, con visibilità limitata sullo stato delle richieste. Il nuovo sistema non stabilisce che ogni problema venga risolto entro un determinato tempo, né sostituisce le politiche di assistenza del singolo sviluppatore. Centralizza invece il percorso della richiesta.

Per questo il pubblico corretto non è qualunque utente di un sub-account. È l’agenzia che ha installato un’app Marketplace e ha bisogno di comunicare con chi la sviluppa. Se il tema riguarda un’integrazione esterna da sottoporre a verifica prima della segnalazione, può essere utile anche la guida su come testare le azioni esterne con Test Action: il ticket resta però il canale per dialogare con lo sviluppatore dell’app.

Cosa cambia con HighLevel

Risposta breve: il ticket viene aperto dal Marketplace in HighLevel e la conversazione resta tracciata nello stesso ecosistema.

La novità collega tre elementi espliciti. HighLevel mette a disposizione il punto di apertura e la visibilità della conversazione; l’app Marketplace è il contesto da cui parte la richiesta; lo sviluppatore riceve e gestisce i ticket nel Developer Portal. Il sistema di ticket è basato su Freshdesk, come indicato dalla fonte.

Per l’agenzia, il cambiamento ufficiale consiste nella possibilità di accedere a un’app installata o al suo listing nel Marketplace e usare l’opzione per aprire un ticket di supporto. Dopo l’invio, ticket e comunicazioni successive sono visibili direttamente in HighLevel. Gli aggiornamenti o le risposte dello sviluppatore generano inoltre notifiche via email per l’agenzia.

Per lo sviluppatore, il canale centralizzato è il Developer Portal: dalla sezione Support Tickets può consultare i ticket in arrivo, rispondere alle agenzie e gestire le conversazioni. Questa è comunicazione bidirezionale, non un semplice modulo di contatto senza seguito.

I benefici descritti dalla fonte sono concreti ma circoscritti: meno dipendenza da canali esterni, maggiore organizzazione della conversazione, disponibilità di screenshot o documenti come contesto e stato della richiesta concentrato in un unico luogo. È ragionevole aspettarsi un processo più lineare; non è corretto dedurre automaticamente tempi di risposta, priorità, SLA o supporto continuativo per ogni app.

Un limite fondamentale è di autorizzazione: amministratori e utenti dei sub-account non possono creare direttamente ticket di supporto. La funzione è riservata agli account agenzia principali. Se un team opera soprattutto nei sub-account, il responsabile deve quindi predisporre un passaggio interno per raccogliere dati e inoltrarli tramite l’account abilitato.

Come configurare il flusso

Risposta breve: non serve configurare un sistema esterno di ticket; il flusso ufficiale parte dall’app installata e richiede un account agenzia principale.

La fonte non dettaglia impostazioni aggiuntive, schermate di autorizzazione o campi obbligatori oltre a descrizione e allegati. Di seguito, quindi, i primi cinque passaggi sono quelli indicati ufficialmente; le indicazioni sulla preparazione della richiesta sono consigli editoriali e non istruzioni di prodotto.

Passaggi ufficiali per l’agenzia

1. Accedi a un’app installata nel Marketplace di HighLevel. La fonte indica anche il listing dell’app come possibile punto di accesso.
2. Seleziona l’opzione per aprire un ticket. Il nome riportato è “Apri un ticket di supporto” o “Raise a support ticket”; la dicitura nella UI può variare.
3. Descrivi il problema in modo dettagliato.
4. Allega file pertinenti, per esempio screenshot o documenti, se servono a chiarire il caso.
5. Invia la richiesta. Dopo l’invio, la conversazione e il ticket risultano visibili in HighLevel; gli aggiornamenti vengono notificati all’agenzia via email.

Passaggi ufficiali per lo sviluppatore

1. Aprire il Developer Portal.
2. Andare alla sezione Support Tickets.
3. Esaminare i ticket ricevuti.
4. Rispondere direttamente alle agenzie e gestire la conversazione del ticket.

Come rendere la segnalazione più utilizzabile: consiglio editoriale

Prima di inviare, chi apre il ticket può organizzare le informazioni in un formato semplice: cosa si stava facendo nell’app, cosa è accaduto, quale evidenza è disponibile e quali allegati accompagnano il caso. Questo non aggiunge funzionalità a HighLevel, ma evita che una descrizione vaga costringa le persone coinvolte a ricostruire il contesto da messaggi successivi.

Un’altra buona pratica editoriale è verificare internamente quale persona abbia accesso all’account agenzia principale. Poiché i sub-account non possono aprire direttamente il ticket, il team può raccogliere screenshot e dettagli nel proprio processo interno e consegnarli al soggetto abilitato. Non va però confuso questo passaggio organizzativo con un permesso nativo della piattaforma non documentato dalla fonte.

Quando sono coinvolti collegamenti o configurazioni di servizi esterni, una nota precisa sui dati osservati è più utile di un generico “non funziona”. Per contesti che includono webhook, ad esempio, è pertinente la guida su come ottimizzare i webhook con Array Formatter gratuito di HighLevel, senza assumere che il contenuto del ticket o l’app Marketplace seguano le stesse impostazioni.

Il risultato operativo

Risposta breve: al termine del flusso esiste un ticket con comunicazioni e allegati concentrati in HighLevel, mentre l’agenzia riceve gli aggiornamenti via email.

Questo è il risultato che la fonte consente di verificare operativamente. L’agenzia non deve aprire una conversazione separata per avviare il supporto dell’app: parte dall’app installata o dal suo listing, invia la richiesta e può consultare in piattaforma ticket e messaggi successivi. Lo sviluppatore opera dal Developer Portal, nella sezione Support Tickets, rispondendo all’interno della stessa conversazione.

In un processo d’agenzia, questa centralizzazione rende più semplice assegnare responsabilità: chi usa l’app raccoglie il contesto, chi ha l’account agenzia principale apre il ticket, chi segue l’operatività osserva gli aggiornamenti ricevuti via email e in HighLevel. Non equivale a delegare il supporto a HighLevel per qualunque componente: il ticket riguarda le app di terze parti del Marketplace e la risposta è gestita dallo sviluppatore dell’app.

La distinzione è importante anche per l’aspettativa del titolare: il sistema può ridurre la dispersione amministrativa, ma non dimostra da solo la causa di un problema né garantisce che un’app venga modificata. Risultati, tempi e qualità della risposta variano in base al caso, all’app e al contesto operativo.

Errori e limiti

Risposta breve: gli errori principali sono usare l’account sbagliato, inviare poco contesto e scambiare la centralizzazione per una garanzia di risoluzione.

Il primo errore è chiedere a un amministratore o utente di sub-account di aprire direttamente il ticket. La fonte dichiara che questi ruoli non sono abilitati; occorre usare l’account agenzia principale.

Il secondo è descrivere il caso senza dettagli o senza gli allegati disponibili. HighLevel permette di aggiungere screenshot e documenti: sfruttarli aiuta a rendere la segnalazione più contestualizzata. È un dato ufficiale che gli allegati siano supportati; è un consiglio editoriale allegare soltanto materiali necessari e verificare che siano condivisibili.

Il terzo è aspettarsi che le notifiche email sostituiscano la consultazione della conversazione. La fonte conferma le notifiche per aggiornamenti e risposte, ma il ticket e le comunicazioni sono visibili in HighLevel: per ricostruire il caso è opportuno riferirsi al thread centralizzato.

Infine, non assumere che tutti i nomi di menu restino invariati. La fonte usa “Open/Raise a support ticket” e “Support Tickets”; l’interfaccia, la disponibilità della funzione e le denominazioni possono cambiare dopo la data di verifica. Tornando al problema iniziale, il valore del flusso è evitare che una richiesta per un’app Marketplace resti dispersa: per ottenere questo risultato, servono account corretto, contesto chiaro e consultazione ordinata del ticket.

Per approfondire l’uso quotidiano della piattaforma e ricevere risorse dedicate, consulta il bonus WhatsApp GoHighLevel. I risultati variano in base al contesto, all’app utilizzata e al processo interno dell’agenzia.