Tichete de suport vs. cereri: în ce aveți încredere?
6 min de citit
O listă de cereri de funcționalități captează ce cer utilizatoarele când au timp să se așeze și să descrie ce vor. Un tichet de suport captează unde sunt blocate utilizatoarele chiar acum, adesea iritate, adesea fără vocabularul să descrie curat cererea subiacentă. Amândouă sunt semnal real, iar echipele care se uită doar la una din cele două sfârșesc rezolvând cu încredere problema greșită, pentru că fiecare canal supra-reprezintă sistematic un alt tip de utilizatoare și un alt tip de nevoie. Prioritizarea cererilor de funcționalități acoperă clasificarea a ce e deja pe listă; acest text e despre decalajul dintre ce ajunge pe listă deloc și ce apare doar vreodată ca tichet de suport.
De ce ar apărea aceeași problemă subiacentă într-un canal și nu în celălalt?
Pentru că cele două canale au costuri de activare diferite, iar mărimea acelui cost decide cine îl depășește. Depunerea unei cereri de funcționalitate cere inițiativă: o utilizatoare trebuie să creadă că cererea merită articulată, să găsească lista, și să scrie ceva coerent, ceea ce selectează utilizatoare implicate, răbdătoare, deja investite în produs. Depunerea unui tichet de suport cere aproape deloc inițiativă în comparație, adesea doar un clic pe “ajutor” în mijlocul unei sarcini, ceea ce înseamnă că prinde utilizatoare frustrate în acel moment, inclusiv cele care n-ar fi deranjat niciodată cu o listă de cereri. Un decalaj real în produs poate fi invizibil pe lista de funcționalități și zgomotos în suport pur și simplu pentru că utilizatoarele care-l întâlnesc sunt cele mai puțin înclinate să depună o cerere formală.
Volumul de tichete pentru o funcționalitate lipsă înseamnă același lucru cu numărul de voturi pentru ea?
Nu, pentru că măsoară populații diferite în condiții diferite. O cerere de funcționalitate cu o sută de voturi reprezintă o sută de persoane care și-au făcut timp să găsească și să susțină o cerere existentă, ceea ce e un semnal puternic de cerere durabilă, chibzuită. O sută de tichete de suport despre același decalaj subiacent, depuse în aceeași perioadă, reprezintă probabil utilizatoare care se lovesc de un zid în acel moment, dintre care unele ar uita complet odată ce frecarea imediată trece. Tratarea celor două ca semnal echivalent de “o sută de oameni vor asta” supra-ponderează volumul de tichete, pentru că tichetele sunt ieftin de generat, iar voturile nu.
| Lista de cereri de funcționalități | Tichete de suport |
|---|---|
| Cere inițiativă pentru a depune | Cere aproape deloc |
| Captează cerere chibzuită, durabilă | Captează frustrare din acel moment |
| Înclină spre utilizatoare implicate, răbdătoare | Captează utilizatoare care n-ar folosi niciodată lista |
| Un număr de voturi e un semnal real de angajament | Un număr de tichete reflectă frecare, nu întotdeauna dorință |
Ce înseamnă când o funcționalitate are tichete de suport dar aproape niciun vot pe listă?
Adesea, că cererea există dar utilizatoarele care o întâlnesc nu știu că lista există, nu cred că votul ar schimba ceva, sau întâlnesc problema prea rar ca să se deranjeze să schimbe canalul ca s-o înregistreze formal. Aceasta e exact populația pe care o listă de cereri o ratează structural, iar un număr mic de voturi aici e dovadă a unui decalaj de măsurare, nu de cerere scăzută. Tratați un cluster de tichete de suport în jurul unei funcționalități lipsă ca semnal propriu pe care voi înșivă îl înregistrați pe listă, în numele utilizatoarelor, în loc să nu aveți încredere în tichete, ca să nu rămână invizibil pentru cine prioritizează doar din numărul de voturi.
Lista se citește ca prioritate scăzută:
"Export to CSV": 4 voturi în 6 luni
Suportul spune o poveste diferită:
"Export to CSV": 31 de tichete în aceeași perioadă, fiecare
de la un cont diferit, fiecare închis cu "nu e suportat
momentan, vom transmite feedback-ul"Un vârf de tichete de suport înseamnă întotdeauna că problema subiacentă e o funcționalitate lipsă?
Nu, și aici cele două canale pot induce în eroare în direcția opusă. Un vârf de tichete e la fel de des cauzat de o interfață confuză în jurul unei funcționalități deja existente, o eroare, sau o schimbare care a ieșit fără explicație adecvată, dintre care niciuna nu se rezolvă construind ceva nou. Citirea fiecărui vârf de tichete ca “utilizatoarele vor o funcționalitate pe care n-o avem” produce o roadmap plină de lucruri care erau de fapt decalaje de documentație sau probleme de uzabilitate deghizate. Tichetul de suport vă spune unde e frecarea; nu vă spune singur dacă soluția e o funcționalitate nouă, o schimbare de interfață, sau un articol de ajutor mai bun, iar confundarea lor irosește timp de inginerie pe soluția greșită.
Cum ar trebui combinate cu adevărat cele două semnale când decideți ce construiți?
Folosiți tichetele ca să găsiți unde e frecarea, și folosiți lista de cereri, plus contact direct unde lista e săracă, ca să confirmați cum arată cu adevărat rezultatul dorit. Un cluster de tichete identifică o problemă reală, simțită; rareori specifică soluția suficient de precis ca să construiți pe ea, pentru că o utilizatoare frustrată într-o conversație de suport descrie simptome, nu specificații. Lista de cereri, când are suficiente voturi pe aceeași problemă subiacentă, tinde să poarte mai mult din detaliul “ce ar satisface asta cu adevărat”, pentru că a scrie o cerere e deja un act de a specifica ce vrei, nu doar a raporta ce nu merge.
Ar trebui agentele de suport să înregistreze tichetele ca cereri de funcționalități ele însele?
Da, și asta e corecția cu cea mai mare pârghie pentru decalajul dintre cele două canale. O agentă care recunoaște un tichet ca pe o cerere de funcționalitate deghizată, în loc să-l rezolve pur și simplu și să treacă mai departe, poate să-l înregistreze pe listă în numele clientei, ceea ce închide direct decalajul de măsurare în loc să ceară ca clienta să descopere și să folosească un al doilea canal. Asta funcționează doar dacă înregistrarea îi ia agentei secunde, nu minute, ca frecarea de a o face să fie mai mică decât frecarea de a închide pur și simplu tichetul și a trece la următorul.
FAQ
Ar trebui voturile pentru cereri de funcționalități să fie vreodată reduse dacă vin toate de la un singur cont sau echipă? Da, ponderați după conturi sau organizații distincte în loc de numărul brut de voturi, pentru că cinci voturi de la cinci persoane din aceeași companie reprezintă prioritățile unei singure cliente, nu cinci confirmări independente de cerere.
Merită construită o funcționalitate care apare mult în tichete dar are aproape niciun vot? Adesea da, cu condiția ca volumul de tichete să vină cu adevărat de la conturi distincte și nevoia subiacentă să fie confirmată, nu presupusă; tratați numărul mic de voturi ca pe un artefact de măsurare al costului de activare al listei, nu ca dovadă că cererea nu e reală.
Cum distingeți dintr-o privire un tichet de confuzie de interfață de unul genuin de funcționalitate lipsă? Uitați-vă dacă rezolvarea constă în explicarea unei capabilități existente sau scuzarea pentru una lipsă. Un tipar de rezolvări “a, de fapt e chiar acolo” indică o problemă de interfață sau de descoperabilitate; un tipar de “asta încă nu-l suportăm” indică un decalaj real.
Contează la fel de mult această distincție cu un volum de suport foarte mic? Mai puțin mecanic, întrucât un mănunchi de tichete e ușor de citit individual fără să fie nevoie de analiză agregată, dar tendința subiacentă, tichetele supra-reprezintă utilizatoarele frustrate și sub-reprezintă pe cele răbdătoare, e prezentă la orice scară și merită ținută minte chiar și când citiți fiecare tichet voi înșivă.
Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.