Ticket di supporto vs. richieste: di cosa ti fidi?
5 min di lettura
Una bacheca di richieste di funzionalità cattura ciò che le utenti chiedono quando hanno tempo di sedersi e descrivere cosa vogliono. Un ticket di supporto cattura in cosa sono bloccate le utenti proprio adesso, spesso infastidite, spesso senza il vocabolario per descrivere pulitamente la richiesta sottostante. Entrambi sono segnale reale, e i team che guardano solo uno dei due finiscono per risolvere il problema sbagliato con sicurezza, perché ogni canale sovrarappresenta sistematicamente un tipo diverso di utente e un tipo diverso di bisogno. Dare priorità alle richieste di funzionalità copre come classificare ciò che è già in bacheca; questo riguarda il divario tra ciò che arriva in bacheca e ciò che compare solo mai come ticket di supporto.
Perché lo stesso problema sottostante comparirebbe in un canale e non nell’altro?
Perché i due canali hanno costi di attivazione diversi, e la dimensione di quel costo determina chi lo supera. Presentare una richiesta di funzionalità richiede iniziativa: un’utente deve credere che la richiesta valga la pena di essere articolata, trovare la bacheca, e scrivere qualcosa di coerente, il che seleziona utenti coinvolte e pazienti già investite nel prodotto. Presentare un ticket di supporto richiede quasi nessuna iniziativa a confronto, spesso solo un clic su “aiuto” a metà di un compito, il che significa che cattura utenti frustrate nel momento, incluse quelle che non si sarebbero mai disturbate con una bacheca di richieste. Un divario reale nel prodotto può essere invisibile sulla bacheca funzionalità e rumoroso nel supporto semplicemente perché le utenti che ci si imbattono sono quelle meno propense a presentare una richiesta formale.
Il volume di ticket per una funzionalità mancante significa la stessa cosa del conteggio voti per essa?
No, perché misurano popolazioni diverse in condizioni diverse. Una richiesta di funzionalità con cento voti rappresenta cento persone che si sono prese il tempo di trovare e sostenere una richiesta esistente, il che è un segnale forte di domanda durevole e ponderata. Cento ticket di supporto sullo stesso divario sottostante, presentati nello stesso periodo, probabilmente rappresentano utenti che sbattono contro un muro nel momento, alcune delle quali dimenticherebbero del tutto una volta passata la frizione immediata. Trattare i due come segnale equivalente di “cento persone lo vogliono” sovrappesa il volume di ticket, perché i ticket sono economici da generare e i voti no.
| Bacheca richieste | Ticket di supporto |
|---|---|
| Richiede iniziativa per presentare | Ne richiede quasi nessuna |
| Cattura domanda ponderata e durevole | Cattura frustrazione nel momento |
| Sbilanciata verso utenti coinvolte e pazienti | Cattura utenti che non userebbero mai la bacheca |
| Un conteggio voti è un vero segnale di impegno | Un conteggio ticket riflette frizione, non sempre desiderio |
Cosa significa quando una funzionalità ha ticket di supporto ma quasi nessun voto in bacheca?
Spesso, che la richiesta esiste ma le utenti che ci si imbattono non sanno che la bacheca esiste, non credono che votare serva a qualcosa, o incontrano il problema troppo raramente per disturbarsi a cambiare canale per registrarlo formalmente. Questa è esattamente la popolazione che una bacheca richieste perde strutturalmente, e un conteggio voti basso qui è prova di un divario di misurazione, non di domanda scarsa. Trattate un gruppo di ticket di supporto attorno a una funzionalità mancante come un proprio segnale degno di essere registrato voi stessi in bacheca, per conto delle utenti, invece di diffidare dei ticket, così da non restare invisibile a chi dà priorità basandosi solo sui conteggi voti.
La bacheca legge come bassa priorità:
"Export to CSV": 4 voti in 6 mesi
Il supporto racconta una storia diversa:
"Export to CSV": 31 ticket nello stesso periodo, ognuno
da un account diverso, ognuno chiuso con "non
attualmente supportato, passeremo il feedback"Un picco nei ticket di supporto significa sempre che il problema sottostante è una funzionalità mancante?
No, ed è qui che i due canali possono ingannare nella direzione opposta. Un picco di ticket è altrettanto spesso causato da un’interfaccia confusa attorno a una funzionalità già esistente, da un bug, o da un cambiamento uscito senza spiegazione adeguata, nessuno dei quali si risolve costruendo qualcosa di nuovo. Leggere ogni picco di ticket come “le utenti vogliono una funzionalità che non abbiamo” produce una roadmap piena di cose che erano in realtà divari di documentazione o problemi di usabilità travestiti. Il ticket di supporto vi dice dove sta la frizione; non vi dice da solo se la soluzione è una nuova funzionalità, un cambio di interfaccia, o un articolo di aiuto migliore, e confondere le due cose spreca tempo di ingegneria sulla soluzione sbagliata.
Come dovrebbero essere combinati davvero i due segnali quando si decide cosa costruire?
Usate i ticket per trovare dove sta la frizione, e usate la bacheca richieste, più il contatto diretto dove la bacheca è scarna, per confermare come appare davvero il risultato desiderato. Un gruppo di ticket identifica un problema reale e sentito; raramente specifica la soluzione con precisione sufficiente per costruirci contro, perché un’utente frustrata in una conversazione di supporto descrive sintomi, non specifiche. La bacheca richieste, quando ha abbastanza voti sullo stesso problema sottostante, tende a portare più del dettaglio di “cosa soddisferebbe davvero questo”, perché scrivere una richiesta è già un atto di specificare cosa si vuole, non solo segnalare cosa non va.
Le agenti di supporto dovrebbero registrare i ticket come richieste di funzionalità loro stesse?
Sì, ed è la correzione a maggior leva singola per il divario tra i due canali. Un’agente che riconosce un ticket come una richiesta di funzionalità travestita, invece di limitarsi a risolverlo e andare avanti, può registrarlo in bacheca per conto della cliente, il che chiude direttamente il divario di misurazione invece di richiedere che la cliente scopra e usi un secondo canale. Questo funziona solo se registrarlo richiede secondi, non minuti, per l’agente, così che la frizione di farlo sia inferiore alla frizione di chiudere semplicemente il ticket e passare al successivo.
FAQ
I voti delle richieste di funzionalità dovrebbero mai essere scontati se vengono tutti da un solo account o team? Sì, pesate per account o organizzazioni distinte invece che per conteggio grezzo di voti, perché cinque voti da cinque persone della stessa azienda rappresentano le priorità di una cliente, non cinque conferme indipendenti di domanda.
Vale la pena costruire una funzionalità che compare molto nei ticket ma ha quasi nessun voto? Spesso sì, purché il volume di ticket venga genuinamente da account distinti e il bisogno sottostante sia confermato invece che assunto; trattate il basso conteggio voti come un artefatto di misurazione del costo di attivazione della bacheca, non come prova che la domanda non sia reale.
Come si distingue a colpo d’occhio un ticket di confusione UI da un genuino ticket di funzionalità mancante? Guardate se la risoluzione consiste nello spiegare una capacità esistente o nello scusarsi per una mancante. Un pattern di risoluzioni “oh, in realtà è proprio lì” indica un problema di interfaccia o scopribilità; un pattern di “non lo supportiamo ancora” indica un divario reale.
Questa distinzione conta altrettanto con un volume di supporto molto piccolo? Meno meccanicamente, dato che una manciata di ticket è facile da leggere individualmente senza bisogno di analisi aggregata, ma il bias sottostante, i ticket sovrarappresentano utenti frustrate e sottorappresentano quelle pazienti, è presente a qualsiasi scala e vale la pena tenerlo a mente anche quando leggete ogni ticket voi stessi.
Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.