Come scrivere un ticket di supporto efficace

Un ticket ben scritto fornisce al team i dettagli necessari per indagare senza dover fare supposizioni. Non può garantire tempi di risposta o risultati, ma rende più chiaro il passaggio successivo. Questa guida spiega cosa includere e offre modelli per le categorie di ticket più comuni.

Per sapere come inviare un ticket, inclusi i campi e dove fare clic, consulta Usare il Centro assistenza. Questo articolo riguarda il contenuto.

Struttura essenziale di un buon ticket

Ogni ticket utile risponde a quattro domande:

1. Cosa stavo cercando di fare: indica l'obiettivo, non solo cosa non ha funzionato.
2. Cosa è successo realmente: l'errore, lo stato o il comportamento esatto osservato.
3. Cosa ho già provato: evita di ripetere un controllo di base.
4. Informazioni identificative: dominio, casella di posta, numero di fattura o timestamp che identificano il caso.

Più contesto fornisci, più sarà facile verificare l'area corretta del prodotto. Non includere mai password, codici 2FA o token API.

Cosa includere per categoria

Ticket di fatturazione

• Numero di fattura o riferimento del pagamento mostrato in Billing o sulla ricevuta.
• L'addebito previsto e l'addebito effettivo, se diversi.
• Se il problema riguarda un rinnovo, l'attivazione di un componente aggiuntivo, una richiesta di rimborso o altro.
• Ultime 4 cifre della carta per problemi specifici della carta, ma mai PAN completo o CVV.
• Valuta e importo della contestazione.

Esempio:

Ieri mi sono stati addebitati $52, ma mi aspettavo $39. Il numero della fattura indicato nella mia pagina Billing è riportato qui sotto. Ultime 4 cifre della carta: 4242. Spiegate per favore se la differenza dipende da un'altra voce o dalle imposte. Ho allegato uno screenshot del dashboard che mostra l'addebito.

Ticket tecnici o di invio

• Indirizzo della casella di invio.
• Indirizzo del destinatario o schema, per esempio "tutti i destinatari @gmail.com".
• Messaggio di errore esatto, copiando il testo completo e gli eventuali codici come 550 o 421.
• Quando è iniziato: se possibile, includi data, ora e fuso orario.
• Se la stessa casella può inviare ad altri indirizzi: indica se il problema riguarda un solo destinatario o provider.
• Se webmail può inviare lo stesso messaggio: aiuta a distinguere un problema di configurazione dell'app di posta da un problema dell'account o di consegna.

Esempio:

Da questa mattina la casella alice@mycompany.com non riesce a inviare ad alcun indirizzo gmail.com. Gli altri destinatari (yahoo.com, outlook.com) funzionano. Il messaggio di mancata consegna è "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail mostra lo stesso errore. Il problema è iniziato alle ~09:00 UTC del 2026-05-15. Anche le altre caselle dello stesso dominio non riescono a raggiungere gmail.com.

Ticket DNS

• Nome di dominio.
• Lo stato mostrato da TrekMail per il dominio e il record esatto non verificato.
• Il risultato di una ricerca DNS, se disponibile. Per esempio, l'output di dig per un record MX o SPF TXT.
• Il tuo provider DNS, come Cloudflare o GoDaddy.
• Il record specifico che non viene verificato.
• Se hai modificato il DNS di recente, inclusa l'ora approssimativa.

Esempio:

Dominio: mycompany.com. Il record DKIM è ancora rosso nella pagina Domains. Ieri ho aggiunto il record su Cloudflare e l'ho impostato come solo DNS, senza proxy. dig +short TXT dkim._domainkey.mycompany.com restituisce il valore previsto v=DKIM1; k=rsa; p=.... TrekMail continua a indicarlo come mancante. Ho controllato la propagazione anche con un altro servizio di ricerca DNS.

Ticket di consegna o spam

• Dominio e casella di posta di invio.
• Frequenza di rimbalzo nel pannello Domain Email Stats.
• Destinatari di esempio i cui messaggi rimbalzano o finiscono nello spam, senza condividere l'intero elenco.
• Origine dell'elenco: modulo di adesione, provider precedente o altra fonte.
• Schema di invio recente: indica se volume o pubblico sono cambiati di recente.

Esempio:

La frequenza di rimbalzo del dominio mycompany.com è salita dallo 0.5% all'8% negli ultimi sette giorni. Ho allegato uno screenshot di Email Stats. Invio a un elenco newsletter con adesione di circa 2,000 iscritti. I rimbalzi includono "user unknown" e "mailbox over quota". Due settimane fa ho rimosso circa 200 iscritti inattivi, l'unica modifica recente. Devo verificare l'elenco rimanente prima di inviare di nuovo?

Ticket API

• Nome del token API, senza incollare il token effettivo.
• L'endpoint chiamato.
• Il corpo della richiesta, con i dati sensibili oscurati.
• La risposta, con codice di stato e corpo.
• Comportamento previsto e comportamento osservato.

Esempio:

Chiamo POST /api/v1/verify/bulk con un array emails oscurato e mode: quick. Ricevo HTTP 422; il corpo della risposta è allegato qui sotto senza indirizzi email. Mi aspettavo la creazione di un processo di verifica. Nome del token: "production-verify-token". Il problema è iniziato oggi verso le 13:00 UTC e ieri la stessa richiesta funzionava.

Ticket relativi ad account o accesso

• L'email dell'account, cioè l'indirizzo di accesso.
• Cosa succede, per esempio accesso impossibile, ripristino password non ricevuto o 2FA non funzionante.
• Browser e sistema operativo.
• Se accedi con un provider social, come Google, Microsoft o servizi simili.
• Data approssimativa dell'ultimo accesso riuscito.

Per una richiesta di recupero 2FA, descrivi il problema di accesso e fornisci solo i dati dell'account richiesti tramite il flusso di supporto ufficiale. Non inviare mai password attuali, codici 2FA, codici di recupero o documenti d'identità in un normale messaggio del ticket, salvo richiesta esplicita di una procedura TrekMail verificata.

Cosa NON includere

Non condividere:

• Password in testo normale. Mai, né la password del dashboard, né quelle delle caselle o di servizi di terze parti.
• Numeri completi di carte di credito, CVV o dati bancari completi. Le ultime 4 cifre sono sufficienti per l'identificazione.
• Token API in testo normale, perché possiamo identificarli per nome.
• Indirizzi o dati di altri clienti negli allegati. Anonimizzali o oscurali.
• Dati personali sensibili dei destinatari, salvo siano essenziali per l'indagine.

Se condividi accidentalmente un segreto, revocalo o ruotalo quando possibile, poi informa subito il supporto affinché il team possa indicarti il passaggio successivo.

Indicazioni per gli allegati

• Screenshot: solo immagini JPEG, PNG, GIF o WebP, massimo 5 MB. Mostra la pagina e l'errore pertinenti, ma ritaglia o oscura URL contenenti token, indirizzi di caselle o altre informazioni private.
• Output di query DNS: incollalo come testo, formattato con backtick per facilitarne la lettura, non come screenshot.
• Log degli errori: incolla le righe pertinenti, non l'intero log.
• Testo del messaggio di mancata consegna: includi il rapporto completo, in particolare la riga Diagnostic-Code:.
• Screenshot del browser: evita di mostrare altre schede, notifiche, password salvate o dati non pertinenti di altri clienti.

La rimozione degli allegati immagine dei ticket è prevista 30 giorni dopo la chiusura del ticket. Conserva una copia locale di tutto ciò che è importante.

Un problema per ticket

Se hai due problemi distinti, invia due ticket separati. In questo modo ogni conversazione resta focalizzata e la cronologia è più facile da seguire.

Se due problemi sono collegati, per esempio "fatturazione non riuscita E invio interrotto", puoi inserirli nello stesso ticket purché il collegamento sia chiaro.

Aggiornare un ticket

Se il problema si risolve prima della risposta del supporto, per esempio perché termina la propagazione DNS o torna disponibile un servizio di terze parti, aggiungi un breve aggiornamento come: "Risolto: la propagazione DNS è terminata. Chiudete questo ticket." Puoi anche chiudere autonomamente un ticket attivo dalla relativa pagina.

Se una soluzione temporanea parziale è accettabile ma non è quella desiderata, specificalo: "Ho aggirato il problema eseguendo X, ma vorrei comunque capire perché il metodo originale non ha funzionato."

Modelli da copiare

Per un ticket generico relativo a un problema:

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

Per una richiesta di funzionalità:

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

Per una contestazione di fatturazione:

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>