Una chiamata di supporto per il flusso di lavoro del ticket non dovrebbe dipendere da ciò che l'agente ricorda dopo che il cliente ha riattaccato.
È nella chiamata che emerge il vero problema.
Il cliente spiega cosa si è rotto. Menzionano il browser, l'account, il messaggio di errore, la soluzione alternativa provata e la scadenza che rende urgente il problema. L'agente pone domande, verifica le ipotesi e promette il passaggio successivo.
Poi la chiamata finisce.
Se il ticket parte dalla memoria, il dettaglio utile comincia subito a trapelare.
Il risultato è un biglietto che dice:
"Il cliente ha chiamato. Problema di accesso. Indagine in corso."
Questo non è sufficiente per il supporto.
Questa è una mollica di pane.
Quando il supporto telefonico dovrebbe diventare ticket utilizzabili
Trasforma le chiamate di supporto in output pronti per i ticket
Superscribe Phone acquisisce le chiamate e aiuta a trasformarle in ticket revisionati, note, follow-up, attività e contesto fatturabile invece che in un'altra trascrizione da ripulire in seguito.
La versione breve
Una chiamata di supporto al flusso di lavoro del ticket dovrebbe catturare sette cose:
- il problema esatto del cliente
- l'utente, l'account, il dispositivo, il sistema o l'ambiente interessato
- i passaggi già provati
- ciò che l'agente ha testato durante la chiamata
- l’impatto e l’urgenza attuali
- il proprietario successivo e l'azione successiva
- cosa dovrebbe essere detto al cliente
La registrazione o la trascrizione della chiamata è materiale originale.
Il ticket è un contesto funzionante.
Questa differenza è importante perché il passaggio successivo del supporto potrebbe avvenire ore dopo, da parte di una persona diversa, in un sistema diverso. Se il ticket non riporta il contesto utile della chiamata, il team deve porre nuovamente le stesse domande al cliente.
Ecco perché il supporto sembra più lento di quanto non sia in realtà.
Perché i ticket di supporto telefonico si assottigliano
Le chiamate all'assistenza sono complicate come non lo sono chat ed e-mail.
Il cliente non sempre descrive il problema in ordine. Ricordano un messaggio di errore a metà della chiamata. Menzionano un secondo utente interessato verso la fine. Dicono che “succede ogni mattina”, ma solo successivamente chiariscono che è iniziato dopo la reimpostazione della password.
Nel frattempo, l'agente svolge tre lavori:
- ascoltando il cliente
- risoluzione dei problemi in diretta
- cercando di lasciare una traccia utile per dopo
Il terzo lavoro è quello che solitamente perde.
Non perché gli agenti siano negligenti.
Perché la chiamata già consumava l'attenzione.
Dopo la chiamata, potrebbe esserci un altro elemento in coda, un altro cliente, un'altra escalation o un aggiornamento promesso. La nota del biglietto diventa una versione compressa della memoria:
- "L'utente non può accedere."
- "Problema della stampante."
- "VPN inattiva."
- "Il cliente dice che l'app è lenta."
- "Ho bisogno che lo sviluppatore controlli."
Quelle note sono tecnicamente biglietti.
Non sono buoni trasferimenti.
Un ticket ha un lavoro diverso da una trascrizione
Una trascrizione conserva ciò che è stato detto.
Un ticket spiega cosa dovrebbe succedere dopo.
Strumenti come Zendesk e Jira Service Management offrono ai team luoghi in cui archiviare campi, commenti, stati, tipi di richiesta e contesto interno (Documenti per sviluppatori Zendesk, Supporto Atlassiano).
Lo storage non è il collo di bottiglia.
Il collo di bottiglia è modellare la chiamata nel giusto contenuto del ticket prima che i dettagli si confondano.
Un ticket di supporto utile dovrebbe rispondere:
- Cosa è rotto?
- Chi è interessato?
- Quanto è grave?
- Come si può riprodurlo o investigarlo?
- Cosa è già stato provato?
- Qual è la prossima azione?
- Cosa si aspetta il cliente dopo?
Ecco perché le note delle chiamate non sono trascrizioni. La trascrizione può essere completa, ma il biglietto deve essere utilizzabile.
Il flusso di lavoro: chiamata, struttura, revisione, instradamento
Il flusso di lavoro dalla chiamata di supporto al ticket più pulito prevede quattro passaggi.
1. Cattura la chiamata
La chiamata dovrebbe essere la fonte della verità.
Nemmeno una nota scritta a metà.
Non la memoria dell'agente dopo la chiamata successiva.
Cattura le cose perché piccoli dettagli cambiano il biglietto. Il "problema di accesso" diventa molto diverso quando il cliente afferma che si verifica solo su un laptop gestito, solo dopo l'SSO, solo quando è connesso al Wi-Fi dell'hotel o solo per gli utenti con un ruolo.
Questi dettagli determinano se il ticket è una reimpostazione della password, un problema del provider di identità, un problema di rete, un bug delle autorizzazioni o un momento di formazione del cliente.
Se la fonte è debole, il ticket inizia debole.
2. Strutturare il contesto di supporto
Il testo grezzo della chiamata è troppo per un ticket.
Il ticket necessita di una versione sagomata del bando:
- Riepilogo del problema: la versione più breve e accurata del problema
- Impatto sui clienti: chi è bloccato e perché è importante
- Ambiente: account, dispositivo, browser, versione, posizione, integrazione o sistema
- Sintomi: comportamento, errore, tempistica o modello esatto
- Passaggi provati: ciò che il cliente e l'agente hanno già testato
- Indizi sulla riproduzione: cosa lo fa accadere di nuovo
- Azione successiva: proprietario, azione e aggiornamento previsto
- Nota rivolta al cliente: cosa il cliente dovrebbe sentire dopo
Questo è il livello che trasforma una chiamata di supporto in un ticket su cui qualcuno può agire.
3. Revisione prima che il ticket diventi memoria della squadra
Non inserire le note generate direttamente nella coda dei biglietti.
Le chiamate di supporto spesso includono ipotesi, dettagli sensibili dell'account, frustrazione, diagnosi parziali e note interne private. Il biglietto dovrebbe preservare il contesto utile senza trasformare ogni frase in storia ufficiale.
La revisione rileva la differenza tra:
- "SSO non funziona."
- "Il cliente segnala un errore di accesso SSO per due utenti. È necessario verificare i registri del provider di identità."
Una è una conclusione non dimostrata.
L'altro è un ticket di supporto.
4. Indirizzare l'output dove avviene il lavoro
Il ticket dovrebbe arrivare al sistema in cui la squadra lavorerà effettivamente.
Se si tratta di un problema di supporto, crea o aggiorna il ticket. Se necessita di ingegneria, includi passaggi di riproduzione e impatto. Se ha bisogno del successo del cliente, preserva le aspettative e l'aggiornamento promesso. Se crea tempo di supporto fatturabile, mantieni il motivo mentre è ancora aggiornato.
Questo è lo stesso schema dietro un forte workflow di follow-up per le chiamate aziendali. La chiamata non è completa quando il cliente riattacca. È completo quando l'output utile raggiunge il flusso di lavoro successivo.
Un pratico modello di ticket di supporto
Utilizzalo se scrivi ancora i ticket manualmente dopo le chiamate.
Riepilogo del problema:
Impatto sui clienti:
Utente, account o sistema interessato:
Ambiente:
Sintomi:
Passaggi già provati:
Indizi sulla riproduzione:
Azione successiva:
- Proprietario:
- Ora di scadenza o di aggiornamento:
Aggiornamento rivolto al cliente:
Contesto interno:
Ecco una versione compilata.
Riepilogo del problema:
L'utente non può completare l'accesso SSO dal laptop gestito.
Impatto sui clienti:
Al responsabile finanziario non è consentito approvare le fatture prima della chiusura odierna.
Utente, account o sistema interessato:
Conto Acme. Utente: responsabile finanziario. Dispositivo: MacBook aziendale.
Ambiente:
Cromo. Sia il Wi-Fi dell'ufficio che l'hotspot mobile sono stati testati.
Sintomi:
L'accesso reindirizza a SSO, quindi ritorna all'app con una pagina vuota. Nessun errore di password mostrato.
Passaggi già provati:
Cancellata la cache del browser. Ho provato in incognito. Confermato che un altro utente sullo stesso account può accedere.
Indizi sulla riproduzione:
Avviato dopo che ieri l'IT del cliente ha modificato le regole del provider di identità.
Azione successiva:
- Proprietario: il supporto passa alla revisione dei log di identità.
- Orario di scadenza o di aggiornamento: il cliente prevede l'aggiornamento entro due ore.
Aggiornamento rivolto al cliente:
Stiamo controllando il trasferimento SSO e ti aggiorneremo prima delle 15:00.
Contesto interno:
È urgente perché blocca l'approvazione della fattura. Non inquadrare ancora come interruzione confermata dell'app.
Quel biglietto dà alla persona successiva un punto di partenza.
Inoltre impedisce al cliente di ripetere l'intera chiamata.
Cosa non dovrebbe figurare nel biglietto
Un buon ticket di supporto non è una discarica.
Lascia fuori:
- lunghe sezioni di trascrizione che non influiscono sull'azione successiva
- ipotesi scritte come fatti
- riempitivo emotivo dalla chiamata
- dettagli privati del cliente che non sono necessari
- colpa interna
- causa principale non verificata
Il biglietto dovrebbe essere specifico, ma non rumoroso.
Se la trascrizione completa della chiamata è necessaria in seguito, conservala come materiale di partenza. Il biglietto principale dovrebbe contenere la versione pronta per il lavoro.
Dove si inserisce Superscribe
Superscribe Phone è progettato per le chiamate che generano lavoro.
Per i team di supporto e i piccoli operatori di servizi, ciò significa che la chiamata può diventare una nota di ticket revisionata, un'attività, un follow-up, un aggiornamento CRM, un contesto di escalation o una traccia di supporto fatturabile.
Il punto non è creare una trascrizione più bella.
Il punto è accorciare il percorso dalla telefonata al biglietto utile.
Quando la chiamata crea lavoro al di fuori del sistema telefonico, Superscribe Desktop copre il livello successivo. Puoi dettare il trasferimento tecnico, l'aggiornamento del cliente, la nota interna o la spiegazione della fattura direttamente nel campo a cui appartiene.
Le chiamate creano il contesto. La dettatura desktop cattura il follow-through.
Quel ponte è importante per lo stesso motivo rapporti automatici sugli incidenti da chiamate di supporto questione. Il lavoro di supporto è valido tanto quanto il trasferimento che lascia dietro di sé.
Prima che la successiva chiamata di supporto sovrascriva questa
Cattura il contesto del ticket mentre è fresco
Usa Superscribe Phone quando le chiamate di supporto devono diventare ticket esaminati, note, follow-up e contesto fatturabile.
FAQ
Che cos'è un flusso di lavoro da chiamata di supporto a ticket?
Un flusso di lavoro da chiamata di supporto a ticket cattura una conversazione di supporto telefonico, estrae il contesto utile del problema, lo esamina e lo instrada nel sistema di ticket con i proprietari e i passaggi successivi.
La trascrizione della chiamata è sufficiente per un ticket di supporto?
Di solito no. Una trascrizione preserva la conversazione, ma un ticket necessita di un riepilogo conciso del problema, dell'impatto, dell'ambiente, della cronologia della risoluzione dei problemi, di indizi sulla riproduzione e di un'azione successiva.
Cosa dovrebbe includere un ticket di supporto da una telefonata?
Dovrebbe includere il problema, l'utente o il sistema interessato, l'impatto sul cliente, i sintomi, i passaggi già provati, gli indizi di riproduzione, il proprietario, l'azione successiva e l'aggiornamento rivolto al cliente.
I ticket di supporto dovrebbero essere creati automaticamente dalle chiamate?
Possono essere redatti automaticamente, ma i ticket importanti dovrebbero comunque essere rivisti prima che diventino memoria della squadra. La revisione è il luogo in cui trovi diagnosi non verificate, dettagli sensibili e promesse poco chiare.