Usa questo modello
Un ottimo supporto inizia con un'ottima documentazione dei ticket. Con Trupeer, puoi risparmiare ore sulla documentazione del supporto partendo da un modello gratuito di ticket e risoluzione del cliente, personalizzandolo con le tue linee guida del brand e trasformando i ticket risolti in video casi studio per la knowledge base del supporto.
La maggior parte dei team di supporto ha un sistema di ticketing pieno di ticket e non ha idea di cosa stia effettivamente andando storto. Tutto è categorizzato come Altro, le note di risoluzione dicono "risolto" e il report mensile mostra il volume e nient'altro.
Questo è un problema di progettazione dei campi, non di reportistica. Questo modello copre entrambe le metà di un ticket: il record che acquisisci, che determina ciò che puoi imparare, e le risposte che invii, che determinano l'esperienza del cliente.
Scarica il modello di ticket e risoluzione
Formato | Ideale per |
|---|---|
Excel (.xlsx) | Il registro dei ticket, con categorie, codici di risoluzione e schede di reportistica |
Word (.docx) | Il modulo del ticket, il report di risoluzione e i modelli di risposta |
Moduli ticket stampabili e compilabili per assistenza sul posto o sul campo | |
Fogli Google | Un registro condiviso per piccoli team senza uno strumento di helpdesk |
Documenti Google | I modelli di risposta, da copiare nelle risposte predefinite del tuo helpdesk |
Gratuito, modificabile, senza filigrana. Se hai già uno strumento di helpdesk, usa l'elenco dei campi e il testo delle risposte e ignora il registro.
Come personalizzare questo modello in Trupeer
Passo 1: Apri la sezione Modelli
Vai alla sezione Modelli dalla navigazione principale.
Passo 2: Seleziona e apri un modello
Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.
Passo 3: Espandi la visualizzazione del modello
Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.
Passo 4: Modifica il modello
Fai clic su Modifica per iniziare a modificare il modello selezionato.
All'interno dell'editor puoi:
Aggiungere nuove sezioni
Definire o aggiornare le regole di formattazione
Aggiungere un logo e regolarne la posizione e le relative impostazioni
Passo 5: Salva il tuo modello personalizzato
Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.
Passo 6: Visualizza l'anteprima e perfeziona il modello
Quando desideri vedere come appare il tuo modello personalizzato, apri l'Anteprima.
Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.
Con un modello di ticket e risoluzione del cliente puoi:
Risparmiare ore di scrittura: Salta la pagina vuota grazie a una struttura pensata per la documentazione dei ticket.
Standardizzare la qualità del supporto: I campi integrati assicurano che ogni ticket acquisisca le informazioni chiave.
Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.
Costruire una KB più forte: I ticket risolti diventano futuri articoli di supporto e guide operative.
Individuare le tendenze: I ticket standardizzati rendono facile identificare i problemi ricorrenti.
Raggiungere team globali: Traduci i modelli di ticket in oltre 65 lingue con un solo clic.
Le due metà di un modello di ticket
Il record. Cosa viene acquisito: chi, cosa, quando, quanto è urgente, quale categoria, cosa lo ha risolto. Questa metà è invisibile al cliente e determina tutto ciò che potrai imparare in seguito.
Le risposte. Ciò che il cliente riceve in ogni fase: conferma di ricezione, aggiornamenti, avviso di escalation, risoluzione, follow-up. Questa metà è ciò su cui ti giudicano.
I team tendono a investire sulla seconda metà e a trascurare la prima, motivo per cui la reportistica di supporto produce così spesso grafici sui volumi e nessuna intuizione strategica. Entrambe sono presenti in questo modello.
I campi del modulo ticket
Ogni campo dovrebbe meritarsi il suo posto. Ognuno aggiunto rallenta l'inserimento, e i campi che nessuno usa si riempiono di dati inutili.
Acquisiti all'inserimento
Campo | Perché esiste |
|---|---|
ID Ticket | Riferimento per tutto ciò che viene dopo |
Data e ora di apertura | Avvia il timer del SLA |
Canale | E-mail, telefono, chat, portale, di persona. Ti dice da dove arriva effettivamente la richiesta |
Nome e contatto del richiedente | A chi rispondere |
Account o organizzazione | Raggruppa i ticket per cliente, che è dove si mostrano i pattern |
Prodotto, servizio o sistema | Ciò che non funziona |
Categoria | Vedi sotto. Il campo in assoluto più importante |
Descrizione | Con le parole del cliente, non parafrasato |
Priorità | Derivata dall'impatto e dall'urgenza, non scelta liberamente |
Assegnato a | Un solo nome, mai un team |
Stato | Aperto, in corso, in attesa del cliente, risolto, chiuso |
Acquisiti alla chiusura
Campo | Perché esiste |
|---|---|
Codice di risoluzione | Cosa lo ha effettivamente risolto. Vedi sotto |
Note di risoluzione | Sufficienti affinché la persona successiva possa ripetere l'azione |
Causa radice | Laddove nota. Opzionale per ticket, essenziale nel complesso |
Tempo di prima risposta | Misurato, non stimato |
Tempo di risoluzione | Escluso il tempo in attesa del cliente |
Riaperto | Sì o no. Un ticket riaperto non era stato risolto |
Articolo della knowledge base creato o aggiornato | Il campo che genera valore cumulativo |
Conferma del cliente | Se il cliente ha concordato sulla risoluzione |
L'ultimo campo di inserimento e quello relativo all'articolo della KB sono i due più comunemente mancanti, ed entrambi sono quelli che fanno la differenza tra una semplice coda e un sistema che migliora continuamente.
Una categorizzazione che funziona davvero
La categoria è il campo che decide se i dati dei tuoi ticket valgono qualcosa, e quasi sempre è strutturata male.
Due livelli, non quattro. Categoria e sottocategoria. Gerarchie più profonde producono tag non coerenti, perché gli agenti smettono di leggere dopo il secondo menu a discesa.
Tra otto e quindici categorie di primo livello. Di meno e tutto finisce in Altro. Di più e nessuno riesce a trovare quella giusta.
Nomina le categorie in base a ciò che il cliente ha riscontrato, non in base alla struttura del tuo team interno. Ad esempio, "Impossibile accedere" invece di "Piattaforma di identità".
Nessuna categoria Altro. O se devi averne una, esaminala mensilmente e trasforma gli elementi ricorrenti in categorie reali. Una voce Altro che supera il cinque percento significa che la tua tassonomia è errata.
Categorizza al primo contatto e lascia che l'agente la modifichi alla chiusura se si rivela essere qualcos'altro. La categorizzazione retrospettiva viene sempre fatta di fretta e quasi sempre è errata.
Rivedi la tassonomia trimestralmente. Le categorie diventano obsolete con l'evoluzione del prodotto.
Un set iniziale pratico per la maggior parte dei team di supporto: accesso e login, fatturazione e pagamenti, configurazione, come fare per, non funziona come previsto, problema di dati, integrazione, prestazioni, richiesta di funzionalità, bug, modifica dell'account, cancellazione.
Codici di risoluzione
L'equivalente sul lato chiusura, ed ancora più spesso trascurato. Le note di risoluzione scritte come testo libero non possono essere quantificate.
Codice | Significato | Cosa ti dice |
|---|---|---|
Risolto dal supporto | L'agente lo ha risolto direttamente | Risoluzione normale |
Risolto dal team tecnico | Ha richiesto una modifica al codice o alla configurazione | Volume di difetti del prodotto |
Errore dell'utente o malinteso | Il prodotto ha funzionato, l'aspettativa non corrispondeva | Lacuna nella documentazione o nella UX |
Documentazione fornita | La risposta esisteva già | Problema di reperibilità, non di conoscenza |
Soluzione temporanea fornita | Il problema di fondo rimane | Backlog nascosto. Tieni d'occhio questo codice |
Duplicato | Stesso problema di un altro ticket | Gonfia il volume se non monitorato |
Nessun difetto riscontrato | Impossibile riprodurre il problema | Necessita di una soglia prima di diventare un pattern |
Ritirato dal cliente | Si è risolto da solo o non è più necessario | Spesso significa risposta lenta |
Fuori portata | Non è qualcosa che supportate | Verifica se dovrebbe esserlo |
Due di questi codici sono oro colato per la diagnostica. Un'alta percentuale di documentazione fornita significa che i tuoi contenuti di aiuto esistono ma non vengono trovati. Un'alta percentuale di soluzioni temporanee fornite significa che stai accumulando problemi irrisolti che si ripresenteranno.
La priorità e come impostarla
La priorità dovrebbe essere derivata, non scelta. Gli agenti lasciati liberi di scegliere segneranno tutto come prioritario, perché ogni cliente ritiene il proprio problema urgente.
Urgenza bassa | Urgenza media | Urgenza alta | |
|---|---|---|---|
Impatto basso | P4 | P4 | P3 |
Impatto medio | P4 | P3 | P2 |
Impatto alto | P3 | P2 | P1 |
L'impatto è quante persone sono colpite e in che misura. Un utente che subisce un disservizio è un impatto basso. Un intero team bloccato è un impatto alto.
L'urgenza è la rapidità con cui il problema deve essere risolto. Un problema estetico è basso, indipendentemente da quante persone lo vedano. Una scadenza bloccata è alta.
Pubblica la matrice e i tempi di risposta previsti per ogni livello, in modo che la priorità sia un calcolo e non una negoziazione.
Il ciclo di vita del ticket
Fase | Cosa succede | Cosa riceve il cliente |
|---|---|---|
Aperto | Ticket creato, categorizzato, prioritarizzato | Conferma con riferimento e tempistiche previste |
Assegnato | Assegnatario designato | Nulla, a meno che l'assegnatario non cambi |
In corso | In fase di gestione | Aggiornamento se supera i tempi promessi |
In attesa del cliente | Bloccato in attesa di informazioni | Richiesta chiara, più una finestra temporale di chiusura automatica |
In escalation | Passato al livello superiore secondo la matrice | Notifica di chi lo gestisce ora e quando risponderà |
Risolto | Soluzione applicata, in attesa di conferma | Messaggio di risoluzione che descrive l'intervento effettuato |
Chiuso | Conferma del cliente o tempo di chiusura automatica trascorso | Sondaggio di soddisfazione opzionale |
Riaperto | Il problema si è ripresentato o non era stato risolto | Conferma che il ticket non era stato risolto |
Lo stato "in attesa del cliente" richiede una finestra di chiusura automatica definita, di solito da cinque a dieci giorni lavorativi con un promemoria preventivo. Senza di essa, i ticket rimangono aperti all'infinito e le metriche sui tempi di risoluzione perdono significato.
Modelli di risposta per fase
Il testo che i clienti vedono effettivamente. Mantienili brevi e sostituisci i segnaposto con valori reali anziché lasciarli generici.
Conferma di ricezione
Grazie per averci contattato. Il tuo riferimento è [ID] e me ne sto occupando. Ti ricontatterò entro [ora] con un aggiornamento, anche se non avrò ancora una risposta completa.
L'ultima frase è importante. Promettere un aggiornamento invece di una risoluzione è una promessa che puoi mantenere.
Aggiornamento di stato
Un rapido aggiornamento su [ID]. Ho [cosa hai fatto] e ora sto [cosa farai dopo]. Prevedo di risolvere la questione entro [ora]. Non è richiesto alcun intervento da parte tua in questa fase.
Invia questo messaggio prima che sia il cliente a sollecitare. Un aggiornamento spontaneo vale più di una risposta rapida a un sollecito.
Richiesta di informazioni
Per procedere ho bisogno di [cosa specifica]. Una volta ottenuto ciò, dovrei essere in grado di [risultato]. Se non riceverò risposta entro il [data], chiuderò il ticket, ma potrai rispondere in qualsiasi momento per riaprirlo.
Chiedi una sola cosa alla volta. Tre richieste in un unico messaggio generano solitamente un'unica risposta parziale.
Notifica di escalation
Ho passato questo ticket a [nome o team] perché [motivo]. Ti contatteranno entro [ora]. Il tuo riferimento rimane invariato [ID] e continuerò a seguire la pratica in copia.
Spiega il motivo. Un'escalation senza una spiegazione viene percepita come un rimpallo di responsabilità.
Risoluzione
Il problema è ora risolto. La causa era [causa] e ho [cosa hai fatto]. Ora dovresti visualizzare [risultato previsto]. Se dovesse accadere di nuovo, rispondi a questo messaggio e tornerà direttamente a me.
Indica la causa. Un semplice "ora è a posto" non dà ai clienti la certezza che il problema non si ripresenterà.
Follow-up della risoluzione
Un controllo su [ID] del [data]. Funziona ancora tutto come previsto? In caso contrario, rispondi pure a questo messaggio.
Invia questo messaggio due o tre giorni dopo, e solo per ticket significativi o ricorrenti.
Disservizio o problema diffuso
Siamo a conoscenza del problema [problema] che interessa [ambito] e ci stiamo lavorando. Ti aggiornerò entro [ora] a prescindere dai progressi. Non devi fare nulla.
Proattivo, rivolto a tutti i soggetti interessati, prima che ti contattino.
Scuse dopo un disservizio
Hai fatto bene a segnalarlo e mi scuso. [Cosa è andato storto], ed è nostra responsabilità. Abbiamo [azione intrapresa] e [cosa impedisce che si ripeta]. Se c'è qualcos'altro in sospeso, fammelo sapere e me ne occuperò.
Specifico, senza atteggiamenti difensivi, e indica chiaramente cosa impedisce al problema di ripetersi.
Il report di risoluzione
Per qualsiasi problema rilevante, il record di chiusura ha bisogno di qualcosa di più di una semplice nota. Il modello include un report di risoluzione che copre:
Riferimento del ticket e date. Cosa ha segnalato il cliente, con le sue parole. Cosa stava effettivamente accadendo, che spesso è diverso. Causa radice. Cosa è stato fatto per risolverlo. Se è stata utilizzata una soluzione temporanea e se il problema di fondo permane. Tempo per la prima risposta e per la risoluzione. Se si è ripresentato. Cosa è stato modificato per evitare che si ripeta, o una nota che indica che non è stato modificato nulla. Articolo della knowledge base creato o aggiornato.
Quest'ultima coppia di elementi è ciò che trasforma un ticket risolto in un miglioramento concreto. La maggior parte delle note di chiusura si limita a indicare ciò che è stato fatto, il che aiuta l'operatore successivo solo se riesce a ritrovare lo specifico ticket.
Cosa ti consentono di fare i dati dei ticket
Presupponendo che i campi siano compilati correttamente:
Trovare le prime cinque categorie per volume e risolvere i problemi più grandi. Di solito il volume maggiore è legato a un problema di documentazione o di prodotto piuttosto che di supporto.
Confrontare il volume con il codice di risoluzione. Un volume elevato con codice "documentazione fornita" indica un problema di reperibilità dei contenuti, non di capacità del supporto.
Monitorare il tasso di soluzioni temporanee, che rappresenta il tuo backlog nascosto.
Verificare il tasso di riapertura per agente e per categoria. Un alto numero di riaperture significa che i ticket vengono chiusi invece di essere realmente risolti.
Analizzare il mix di canali nel tempo. Una crescita del canale telefonico spesso significa che il self-service si è interrotto da qualche parte.
Fare incroci per account. Un singolo cliente che apre ripetutamente ticket nella stessa categoria indica un problema di formazione o di configurazione, non sfortuna.
Tracciare separatamente la prima risposta e la risoluzione. Hanno cause diverse e richiedono soluzioni diverse.
Nulla di tutto questo è possibile senza una categorizzazione rigorosa al momento dell'inserimento, motivo per cui a questo campo viene dedicata la massima attenzione in questo modello.
Help desk, service desk e modelli di ticket
Help desk | Service desk | Supporto clienti | |
|---|---|---|---|
Destinatari | Personale interno, solitamente IT | Personale interno, catalogo servizi più ampio | Clienti esterni |
Focus | Risoluzione guasti (break-fix) | Richieste, incidenti, modifiche, problemi | Domande e problemi relativi al prodotto |
Framework | Informale | Spesso allineato a ITIL | Variabile |
Campi extra | Asset, dispositivo | Servizio, riferimento modifica, CI | Account, abbonamento, ordine |
L'elenco dei campi e il testo delle risposte in questa pagina funzionano per tutti e tre i casi. I service desk che utilizzano ITIL dovranno aggiungere riferimenti a modifiche e problemi; in quel contesto, la distinzione tra incidente e richiesta è fondamentale, a differenza di quanto avviene nel supporto clienti.
Come configurare tutto questo
Progetta prima le categorie, insieme alle persone che le utilizzeranno. Da otto a quindici, su due livelli, nominate in base all'esperienza del cliente.
Decidi i campi obbligatori all'inserimento e mantieni l'elenco breve. Ogni campo in più rallenta la prima risposta.
Costruisci la matrice delle priorità e pubblicala insieme agli obiettivi di risposta.
Definisci i codici di risoluzione prima del lancio, non dopo sei mesi di inserimento di testo libero.
Imposta la finestra di chiusura automatica per lo stato "in attesa del cliente".
Carica i modelli di risposta come risposte rapide e personalizza il tono affinché rifletta lo stile del tuo team.
Fai formazione specifica sulla categorizzazione. È il campo che più spesso viene compilato male ed è quello che conta di più.
Controlla la categoria Altro mensilmente per il primo trimestre.
Crea report su categorie e codici di risoluzione, non solo sul volume complessivo.
Rivedi la tassonomia ogni trimestre.
Best practice
Categorizza al primo contatto, correggi alla chiusura.
Riduci al minimo i campi obbligatori all'inserimento per rendere il ticket comunque gestibile.
Deriva la priorità dall'impatto e dall'urgenza invece di lasciare la scelta agli agenti.
Utilizza codici di risoluzione, non testo libero, per tutto ciò che desideri quantificare.
Prometti un aggiornamento piuttosto che una risoluzione immediata.
Invia aggiornamenti prima che sia il cliente a sollecitare.
Indica chiaramente la causa nel messaggio di risoluzione.
Imposta una finestra di chiusura automatica per lo stato "in attesa del cliente".
Registra se è stato creato un articolo per la knowledge base.
Esegui report per categoria e codice di risoluzione.
Errori comuni
Una categoria Altro che assorbe un terzo dei ticket complessivi.
Gerarchie di categorie a quattro livelli che gli agenti smettono di scorrere.
Categorie nominate in base ai team interni anziché ai sintomi descritti dal cliente.
Priorità scelta liberamente, con il risultato che tutto diventa urgente.
Note di risoluzione a testo libero senza dati quantificabili.
Nessun monitoraggio delle soluzioni temporanee, con la conseguenza che i problemi irrisolti svaniscono dai radar.
Stato "in attesa del cliente" senza chiusura automatica, il che gonfia all'infinito il conteggio dei ticket aperti.
Messaggi di risoluzione che dicono "risolto" senza spiegare cosa non andava.
Nessun follow-up sui problemi significativi.
Report basati solo sul volume, che mostrano quanto siete occupati ma non ne spiegano il motivo.
Categorizzazione retrospettiva a fine mese.
Trasforma i ticket risolti in soluzioni che i clienti possono applicare da soli
Apri il modello in Trupeer AI, applica il tuo brand kit affinché tutto ciò che è rivolto al cliente sia coordinato, e modifica direttamente qualsiasi sezione. La configurazione è descritta nella guida al modello.
Guarda di nuovo la tabella dei codici di risoluzione. "Documentazione fornita" significa che la risposta esisteva ma non è stata trovata. "Risolto dal supporto" ripetutamente nella stessa categoria significa che la risposta non esiste ancora. Entrambi sono problemi di contenuto che si manifestano come volume di supporto, ed entrambi si risolvono nello stesso modo.
Quando un operatore risolve la stessa cosa per la quarta volta, registrala una volta sola. Trupeer AI produce l'articolo scritto e una video-guida narrata in un unico passaggio, così il cliente successivo potrà guardare la soluzione anziché aprire un ticket. Traducila in oltre 65 lingue e conserva il set nella tua knowledge base affinché sia facilmente reperibile nel momento in cui qualcuno si blocca. Usa le stesse registrazioni per la formazione degli agenti.
Registralo. Personalizzalo con il tuo brand. Traducilo. Trasformalo con Trupeer.
Domande Frequenti
Esiste un modello gratuito di sistema di ticketing?
Sì. La versione Excel funziona come un registro completo dei ticket per piccoli team che non dispongono di uno strumento di helpdesk, completo di categorie, priorità, codici di risoluzione e schede di reportistica. Se disponi già di un sistema di helpdesk, prendi l'elenco dei campi e i modelli di risposta e ignora il registro.
Esiste un modello di ticket di help desk in Word?
Sì. Il file Word contiene il modulo di inserimento del ticket, il report di risoluzione e tutti i modelli di risposta, così puoi stampare il modulo o copiare il testo nelle risposte predefinite del tuo helpdesk.
Esiste un modello di ticket di servizio in Excel?
Sì, ed Excel è la versione che la maggior parte dei team trova più utile. Una riga per ticket con campi di inserimento e chiusura, menu a discesa per categoria, priorità e codice di risoluzione, oltre a schede che riassumono il volume per categoria e tipo di risoluzione.
Esiste un modello di ticket di servizio in Word?
Sì. La versione Word include un ticket di servizio stampabile adatto per l'assistenza sul campo o di persona, con righe per le firme per il lavoro completato e l'accettazione del cliente.
Esiste un modello di modulo per ticket di servizio IT?
Sì. La versione IT del modulo di inserimento aggiunge il riferimento all'asset o al dispositivo, il sistema interessato e un campo di riferimento della modifica per i service desk che gestiscono un processo di modifica formale.
Esiste un modello HTML o Bootstrap gratuito per un sistema di ticket di supporto?
No, ed è bene essere franchi su questo punto. Tali ricerche riguardano codice front-end per creare un'interfaccia di ticketing, che rappresenta una risorsa di sviluppo web piuttosto che un documento. Ti conviene cercare un tema per dashboard di amministrazione Bootstrap o utilizzare una piattaforma di helpdesk esistente, poiché creare un sistema di ticketing da un modello è solitamente più costoso di quanto sembri, una volta considerati l'autenticazione, l'instradamento delle e-mail e la logica dei SLA. Ciò che questa pagina ti offre è la progettazione dei campi e il testo delle risposte, di cui avrai comunque bisogno a prescindere dall'interfaccia utilizzata.
Che cos'è un modello di risoluzione dei ticket?
Due cose diverse a seconda del contesto. Il messaggio di risoluzione inviato al cliente che spiega cosa non andava e cosa è stato fatto, e il record di risoluzione acquisito internamente con il codice di risoluzione, la causa radice e il tempo impiegato per risolvere. Entrambi sono inclusi qui, e il secondo è ciò che rende utilizzabili i dati dei tuoi ticket.
Quali campi dovrebbe avere un ticket di supporto?
All'inserimento: ID ticket, data, canale, richiedente, account, prodotto o servizio, categoria, descrizione con le parole del cliente, priorità, assegnatario e stato. Alla chiusura: codice di risoluzione, note di risoluzione, causa radice ove nota, tempi di risposta e risoluzione, se è stato riaperto e se è stato creato un articolo della knowledge base.
Come dovrebbero essere categorizzati i ticket di supporto?
Su due livelli, da otto a quindici categorie di primo livello, nominate in base a ciò che il cliente ha riscontrato piuttosto che alla struttura del tuo team interno. Categorizza al primo contatto e consenti correzioni alla chiusura. Evita una categoria generica "Altro", oppure esaminala mensilmente e trasforma le voci ricorrenti in categorie reali.
Cosa sono i codici di risoluzione e perché sono importanti?
Un insieme fisso di valori che descrivono come è stato risolto un ticket: risolto dal supporto, risolto dal team tecnico, documentazione fornita, soluzione temporanea fornita, errore dell'utente, duplicato, nessun difetto riscontrato. Sono importanti perché le note di risoluzione a testo libero non possono essere quantificate, e in particolare due di questi codici ti dicono dove si trovano i tuoi veri problemi.
Come si imposta la priorità dei ticket?
Derivandola dall'impatto e dall'urgenza utilizzando una matrice pubblicata, anziché lasciare la scelta libera agli agenti. L'impatto indica quante persone sono colpite e in che misura. L'urgenza indica la rapidità con cui il problema deve essere risolto. Pubblica la matrice con gli obiettivi di risposta in modo che la priorità sia un calcolo matematico e non una trattativa.
Cosa dovrebbe contenere un messaggio di risoluzione dei ticket?
Qual era la causa, cosa hai fatto, cosa dovrebbe vedere ora il cliente e come ricontattarti in caso di ricadute. Indicare la causa è la parte più spesso tralasciata, ed è ciò che dà al cliente la certezza che la soluzione sia efficace e duratura.
Quanto tempo si dovrebbe attendere prima di chiudere un ticket?
Da cinque a dieci giorni lavorativi nello stato "in attesa del cliente", con un promemoria prima della chiusura e l'indicazione chiara che una risposta riaprirà il ticket. Senza una finestra di chiusura automatica, il conteggio dei ticket aperti sale all'infinito e le metriche sui tempi di risoluzione perdono di significato.
Posso personalizzare questo modello di ticket e risoluzione?
Sì, tutte le versioni sono completamente modificabili. Le categorie e i codici di risoluzione sono le parti che devono adattarsi alla tua realtà, e vengono forniti come set iniziale da modificare anziché da adottare ciecamente. In Trupeer AI puoi anche applicare il tuo brand kit in modo che i messaggi e gli articoli rivolti ai clienti siano coordinati.
