La frase più costosa dell'assistenza

“Potresti inviarci uno screenshot e dirci quale browser stavi usando?” È una domanda gentile e ragionevole, ed è il motivo per cui un bug da due minuti richiede tre giorni per essere corretto. Il cliente è impegnato, quindi la risposta arriva il giorno dopo. Lo screenshot mostra il messaggio di errore ma non il clic che l'ha causato. La versione del browser è sbagliata perché l'ha controllata sul telefono. Quando lo sviluppo vede il ticket, nessuno ricorda esattamente cosa sia successo, nemmeno il cliente.

La soluzione non è un modulo di segnalazione migliore. È smettere di chiedere al cliente prove che avresti potuto acquisire tu, nel momento in cui il problema si è verificato.

Cosa contiene davvero una segnalazione di bug utile

Gli sviluppatori hanno bisogno di cinque cose per riprodurre un bug:

  • Cosa ha fatto il cliente: i clic e gli input, in ordine.
  • Cosa si aspettava: il risultato che stava cercando di ottenere.
  • Cosa è successo davvero: l'errore, la schermata vuota, il pulsante che non ha fatto nulla.
  • L'ambiente: pagina, browser, dispositivo, viewport e da dove arrivava.
  • La traccia tecnica: errori della console e richieste di rete non riuscite.

Un cliente può darti in modo affidabile il secondo elemento e parte del terzo. Gli altri tre sono esattamente ciò che registra una registrazione della sessione: la sequenza di azioni, la pagina e il browser, il log della console e le chiamate di rete. Chiedere alle persone di ricostruirli a memoria significa chiedere proprio la parte che sono meno in grado di dare.

Allega la sessione invece di chiederla

Il punto di partenza più semplice è la segnalazione stessa. Quando un cliente invia un widget di feedback in-app o un modulo di segnalazione bug, la sessione è proprio lì: la pagina in cui si trova, gli errori appena scattati, le richieste fallite un secondo prima. Acquisiscila insieme alla segnalazione, e il ticket arriva già con ciò che serve allo sviluppo.

Questo cambia la prima risposta. Invece di “puoi inviarci uno screenshot?”, l'agente apre la registrazione, vede il TypeError nella console due secondi prima che il cliente cliccasse di nuovo su Paga, e può dire “abbiamo visto cosa è andato storto, ed ecco una soluzione temporanea” entro la stessa ora.

Con l'email è più difficile, perché un'email non ha una sessione allegata. Due abitudini aiutano. Identifica gli utenti che hanno effettuato l'accesso nelle tue analisi, così un ticket da un indirizzo noto può essere abbinato alle sue sessioni recenti, e inserisci un link per il feedback all'interno del prodotto, così la prossima segnalazione arriva dalla pagina in cui si trova il problema e non da una casella di posta il giorno dopo.

Smista per bug, non per ticket

Quando i ticket contengono l'errore, puoi raggrupparli in base a esso. È qui che la maggior parte dei team ottiene il guadagno più grande. Un bug nel checkout non produce un ticket; ne produce trenta, ognuno scritto in modo diverso: “pagamento non riuscito”, “non riesco a comprare”, “pulsante rotto”. Letti uno alla volta, sembrano trenta problemi. Raggruppati in base al messaggio di errore che condividono, sono un solo bug con trenta clienti coinvolti, ed è questo il numero che lo fa diventare una priorità.

Il raggruppamento cambia anche il modo in cui chiudi il cerchio. Inoltra il bug una sola volta, come issue in Linear, GitHub o Jira, e collega a essa ogni ticket corrispondente. Quando la correzione viene rilasciata, tutti quei clienti possono saperlo, non solo i cinque che hanno risposto per caso.

Perché funzioni, il raggruppamento deve corrispondere a ciò che lo sviluppo vede già. Se l'assistenza conta i “problemi di pagamento” e lo sviluppo conta Cannot read properties of undefined (reading 'total'), i due elenchi non coincideranno mai. Raggruppa i ticket in base allo stesso messaggio di errore normalizzato usato dal tuo monitoraggio degli errori.

Gestisci la privacy prima che sia lei a gestire te

Allegare le sessioni ai ticket significa che gli agenti di assistenza vedono di più di ciò che hanno fatto i clienti, quindi stabilisci prima le regole:

  • Maschera gli input dei moduli per impostazione predefinita, e non registrare mai password o campi di pagamento.
  • Indica nella tua informativa sulla privacy che l'assistenza può esaminare la sessione collegata a una richiesta.
  • Limita l'accesso alle registrazioni a chi gestisce i ticket, non a chiunque abbia un account.
  • Rispetta il consenso: un visitatore che ha rifiutato le analisi non dovrebbe avere una sessione da allegare.

Fatto in questo modo, il contesto della sessione è meno invasivo dell'alternativa, cioè chiedere ai clienti di condividere lo schermo o di inviare via email screenshot del loro account.

Un flusso di lavoro che puoi avviare questa settimana

  1. Aggiungi un widget di feedback in-app o di segnalazione bug nelle pagine in cui i problemi si verificano più spesso: checkout, onboarding, impostazioni.
  2. Acquisisci la sessione con ogni invio, così ogni ticket contiene la registrazione, il log della console e le richieste non riuscite.
  3. Identifica gli utenti che hanno effettuato l'accesso, così i ticket via email dei clienti noti possono essere abbinati alle loro sessioni.
  4. Raggruppa i ticket per errore ed esamina ogni settimana i gruppi principali con lo sviluppo.
  5. Inoltra ogni bug una sola volta e rispondi a ogni cliente collegato quando viene corretto.

Cosa misurare

Quattro numeri ti dicono se sta funzionando:

  • Quota di ticket di bug con una sessione allegata. È l'indicatore anticipatore; fallo crescere per primo.
  • Tempo alla prima risposta utile, cioè una risposta che non chiede ulteriori informazioni.
  • Ticket per bug. Un numero in calo significa che stai correggendo i bug che generano più carico per l'assistenza.
  • Tasso di riapertura dei ticket di bug, che scende quando la prima risposta è quella giusta.

L'help desk di PulsePanda è costruito attorno a questo ciclo: i feedback inviati diventano ticket con la registrazione e gli errori allegati, i ticket sono raggruppati in base agli stessi errori della pagina Errori, e l'inoltro a Linear, GitHub o Jira ti permette di rispondere a ogni cliente coinvolto quando la issue viene chiusa.