Come preservare le conversazioni email quando diventano ticket
Mantenere unita una conversazione email dopo che è diventata un ticket dipende dalle regole di threading utilizzate dall'helpdesk. Tra gli indicatori comuni ci sono gli header Message-ID, In-Reply-To e References. Alcune piattaforme utilizzano anche un ID ticket o un altro identificatore nel corpo del messaggio o nell'indirizzo di ricezione.
Utilizza questa checklist prima di affidarti a un nuovo canale email:
- Collega l'indirizzo di assistenza utilizzando un metodo ufficialmente supportato dall'helpdesk.
- Invia un ticket di prova e rispondi attraverso lo stesso percorso che utilizzeranno i clienti.
- Confronta gli header del messaggio originale e della risposta, quindi verifica che la risposta compaia nel ticket esistente.
Se il test crea un nuovo ticket, consulta le regole di threading documentate dall'helpdesk prima di modificare il routing della posta. Ogni piattaforma può combinare in modo diverso header, identificatori dei ticket e controlli sul mittente.
Punti chiave
Il threading delle email non si basa solo sulle righe dell'oggetto. Gli helpdesk esaminano comunemente gli header standard delle risposte e possono utilizzare i propri identificatori dei ticket come ulteriori segnali di corrispondenza.
| Punto | Dettagli |
|---|---|
| Gli header collegano le risposte | In-Reply-To e References fanno riferimento agli ID dei messaggi della conversazione esistente. |
| Le regole variano in base alla piattaforma | Un helpdesk può anche esaminare un ID ticket, un identificatore nascosto, un indirizzo di ricezione o il mittente. |
| Utilizza connessioni supportate | Segui la configurazione della casella documentata dal tuo helpdesk e dal tuo provider email. |
| Testa il percorso reale | Rispondi come cliente e verifica che il messaggio venga aggiunto al ticket originale. |
| Opzioni per le caselle Deskhero | Deskhero supporta connessioni bidirezionali alle caselle Google e Microsoft, oltre all'inoltro da un dominio con invio autenticato. |
Indice
- Quali header mantengono effettivamente i thread delle email
- Configurare i server email per mantenere integri i thread
- Perché i thread si interrompono e come risolvere ogni causa
- Come Deskhero mantiene intatta la cronologia delle conversazioni
- Dove la maggior parte delle guide alla configurazione sbaglia
- Avviare un helpdesk con thread senza perdere neanche una risposta
- Fonti
- FAQ
Quali header mantengono effettivamente i thread delle email
Un'email normalmente ha un Message-ID. Una risposta può contenere un valore In-Reply-To che fa riferimento al messaggio a cui si sta rispondendo e un valore References che elenca gli ID dei messaggi precedenti. Un helpdesk può utilizzare queste relazioni per associare i messaggi a una conversazione. La documentazione di Amazon Connect descrive sia i thread cronologici sia le strutture ad albero create quando qualcuno risponde a un messaggio precedente.
Le piattaforme possono aggiungere metodi di corrispondenza propri. Zendesk documenta tre controlli: gli elementi degli header, un ID codificato nel corpo del messaggio e un ID codificato in un indirizzo di ricezione Zendesk. Queste sono regole specifiche di Zendesk, non un modello copiabile in ogni helpdesk.
Il threading è importante perché separare una risposta dai messaggi precedenti rende più difficile seguire la cronologia dell'assistenza:
- Gli utenti potrebbero dover cercare in un altro ticket gli allegati o le decisioni precedenti.
- I destinatari e le risposte precedenti possono essere separati dalla domanda più recente.
- Due utenti potrebbero rispondere a messaggi correlati senza rendersi conto che appartengono alla stessa conversazione.
La documentazione email di Freshdesk mostra un altro approccio specifico della piattaforma. Controlla un ID ticket, un ID messaggio o un identificatore univoco, seguito da un controllo sul mittente. La lezione pratica è capire quali segnali utilizza il tuo helpdesk e mantenerli intatti lungo il percorso effettivo della posta.
Configurare i server email per mantenere integri i thread
Una configurazione affidabile inizia dal metodo di connessione supportato dall'helpdesk. Evita di presumere che un relay SMTP, una regola di inoltro o la sincronizzazione di una casella si comportino allo stesso modo tra prodotti diversi.
- Scegli la connessione alla casella documentata. Se l'helpdesk offre una connessione diretta a Google o Microsoft, segui il relativo flusso di autorizzazione. Se richiede l'inoltro, utilizza esattamente la destinazione e i record DNS forniti dal prodotto.
- Configura l'inoltro per l'indirizzo previsto. La guida di Deskhero all'inoltro in Google Workspace spiega come creare un Gruppo e aggiungere l'indirizzo di destinazione di Deskhero come membro. Microsoft 365 e altri provider seguono procedure di configurazione diverse.
- Lascia intatti gli identificatori della piattaforma. Se il tuo helpdesk aggiunge un contrassegno del ticket a una notifica in uscita, non rimuoverlo dal modello a meno che la documentazione del prodotto non indichi che è facoltativo. Freshdesk consiglia di includere il proprio formato per l'ID ticket, mentre Zendesk aggiunge per impostazione predefinita un ID codificato alle notifiche in uscita.
- Controlla i sistemi che trasformano la posta. Le regole di routing, le mailing list e i gateway possono modificare un messaggio prima che l'helpdesk lo riceva. Confronta il codice sorgente originale in ogni fase disponibile invece di cercare di indovinare dove sia cambiato un valore.
- Esegui un test di verifica ripetibile. Crea un ticket, invia una risposta e controlla il codice sorgente originale. Verifica se
In-Reply-Tofa riferimento a unMessage-IDprecedente, seReferencescontiene la catena prevista e se la risposta è stata aggiunta al ticket esistente.
Consiglio: Testa utilizzando lo stesso indirizzo, lo stesso percorso di inoltro e lo stesso client email che useranno i tuoi clienti. Un messaggio diretto a un indirizzo di test interno non verifica l'intero percorso di produzione.
Perché i thread si interrompono e come risolvere ogni causa
Una risposta può diventare un nuovo ticket per diversi motivi. La causa esatta dipende dalle regole di corrispondenza della piattaforma.
- Header delle risposte mancanti. Un messaggio composto come nuova email potrebbe non contenere i valori
In-Reply-TooReferencesattesi da una risposta. Chiedi al mittente di utilizzare Rispondi, quindi confronta il codice sorgente originale. - Routing o destinatari modificati. Un messaggio inviato a un indirizzo di assistenza diverso può creare un altro ticket. Freshdesk, ad esempio, documenta un comportamento speciale quando viene incluso più di un indirizzo helpdesk configurato.
- Identificatore della piattaforma rimosso. Modificare un modello di notifica può rimuovere un ID ticket o un identificatore nascosto utilizzato dall'helpdesk come alternativa.
- Corrispondenza dei messaggi scaduta. Freshdesk afferma che il relativo ID messaggio scade normalmente sette giorni dopo l'ultima risposta. Trascorso questo periodo, cerca l'ID ticket o l'identificatore del ticket. Questa tempistica è specifica di Freshdesk e non deve essere considerata valida per altri prodotti.
Inizia la diagnosi dal messaggio originale in uscita e dalla risposta del cliente. Confronta i loro header originali affiancandoli, quindi controlla la documentazione dell'helpdesk e la cronologia del ticket. Se gli header della risposta sono presenti, esamina gli altri requisiti della piattaforma, come i contrassegni del ticket, l'indirizzo di ricezione o il mittente autorizzato. Se gli header mancano, segui il percorso attraverso il provider email e qualsiasi servizio di inoltro per individuare il punto in cui il messaggio è cambiato.
Come Deskhero mantiene intatta la cronologia delle conversazioni
Deskhero trasforma una casella Gmail, Google Workspace o Microsoft 365 esistente in un helpdesk. Supporta inoltre caselle su altri domini di proprietà tramite autenticazione DNS e inoltro dei messaggi in entrata.
- Le connessioni Google e Microsoft offrono la sincronizzazione bidirezionale, così Deskhero può leggere la posta in arrivo e inviare risposte come indirizzo collegato.
- Una casella DNS utilizza record DKIM per l'invio autenticato e un indirizzo Deskhero univoco per l'inoltro della posta in entrata.
- Le risposte nella stessa conversazione email vengono aggiunte al ticket Deskhero esistente.
- Le risposte suggerite dall'AI utilizzano le conoscenze del workspace e restano sotto il controllo degli utenti. Le risposte automatiche sono una funzione separata che deve essere abilitata per ogni gruppo e risponde solo a partire dalle FAQ pubbliche approvate.
Per ulteriori informazioni, consulta gli articoli di Deskhero sulla sincronizzazione bidirezionale delle email dell'helpdesk, sull'utilizzo di una casella esistente come helpdesk e sulla trasformazione delle email in entrata in ticket.
| Requisito | Opzione Deskhero |
|---|---|
| Collegare Gmail o Google Workspace | Connessione OAuth con sincronizzazione bidirezionale |
| Collegare Microsoft 365 o Outlook | Connessione OAuth con sincronizzazione bidirezionale, incluse le caselle condivise |
| Utilizzare un altro dominio di proprietà | Autenticazione DNS per l'invio e inoltro per la posta in entrata |
| Controllare le risposte dell'AI | Gli utenti esaminano le risposte suggerite; le risposte automatiche richiedono un'attivazione separata |
Dove la maggior parte delle guide alla configurazione sbaglia
È allettante ridurre il threading a un'unica regola, come mantenere il Message-ID. La documentazione dei vendor mostra perché questo è incompleto. Zendesk combina controlli sugli header e sugli ID codificati. Freshdesk combina diversi indicatori email con un controllo sul mittente. Amazon Connect collega i contatti utilizzando dati sui contatti correlati e gli header email convenzionali.
L'approccio migliore è considerare il threading come un comportamento end-to-end. Utilizza una connessione alla casella supportata, mantieni intatti gli identificatori generati dal prodotto e testa con una risposta reale di un cliente. Quando il risultato è errato, confronta i messaggi originali e procedi seguendo l'ordine di corrispondenza documentato dall'helpdesk.
In questo modo eviti anche modifiche non necessarie al server email. Un nuovo relay o un modello riscritto può introdurre un'ulteriore variabile senza risolvere il problema effettivo di corrispondenza.
Avviare un helpdesk con thread senza perdere neanche una risposta
Deskhero può collegare una casella Gmail, Google Workspace o Microsoft 365 esistente tramite sincronizzazione bidirezionale. Per un altro dominio di proprietà, supporta l'invio autenticato attraverso la configurazione DNS e l'inoltro della posta in entrata a un indirizzo Deskhero univoco.
I tuoi utenti lavorano da una casella condivisa, mentre le risposte vengono inviate dall'indirizzo aziendale collegato. Se la tua attività di assistenza utilizza Shopify, l'integrazione Shopify aggiunge il contesto del cliente e dell'ordine alla barra laterale del ticket.
Deskhero offre una prova gratuita di 30 giorni senza richiedere una carta di credito. Puoi collegare un indirizzo esistente invece di chiedere ai clienti di impararne uno nuovo.
Fonti
- Funzionalità email e threading di Amazon Connect
- Come Zendesk organizza in thread le email in entrata nei ticket
- Panoramica del canale email e del threading di Freshdesk
FAQ
Qual è la differenza tra sincronizzazione bidirezionale e inoltro?
La sincronizzazione bidirezionale consente a un helpdesk di leggere dalla casella collegata e inviare messaggi tramite essa. L'inoltro invia i messaggi in entrata a un'altra destinazione e può richiedere un'autenticazione separata per la posta in uscita. I metodi disponibili e le regole di threading dipendono dall'helpdesk e dal provider email.
Perché la risposta di un cliente ha creato un nuovo ticket invece di essere aggiunta al thread?
Alla risposta potrebbero mancare gli header attesi, potrebbe essere stato utilizzato un indirizzo di assistenza diverso, potrebbe provenire da un mittente che la piattaforma non associa al ticket oppure potrebbe mancare un identificatore del ticket specifico del prodotto. Controlla il codice sorgente originale dell'email e le regole documentate dal tuo helpdesk.
Come verifico se il threading ha funzionato correttamente?
Verifica che la risposta compaia nel ticket esistente. In caso contrario, confronta i valori In-Reply-To e References della risposta con i valori Message-ID precedenti, quindi controlla gli eventuali identificatori dei ticket utilizzati dalla piattaforma.
Ho bisogno di un relay SMTP autenticato se utilizzo già la sincronizzazione bidirezionale?
Di solito non come soluzione separata per il threading. Segui la configurazione di invio richiesta dal tuo helpdesk. Una connessione diretta alla casella potrebbe gestire già la posta in uscita, mentre una configurazione basata sull'inoltro o sul DNS potrebbe utilizzare un altro metodo di invio autenticato.
Deskhero supporta sia Gmail sia Microsoft 365?
Sì. Deskhero supporta connessioni bidirezionali per Gmail, Google Workspace, Microsoft 365 e Outlook. Sono supportate anche le caselle condivise Microsoft.