Supporttickets vs. featureverzoeken: wat vertrouw je?

Een featureverzoekbord vangt wat gebruikers vragen wanneer ze tijd hebben om te gaan zitten en te beschrijven wat ze willen. Een supportticket vangt waar gebruikers nu op vastlopen, vaak geïrriteerd, vaak zonder het vocabulaire om het onderliggende verzoek netjes te beschrijven. Beide zijn echte signalen, en teams die maar naar één van de twee kijken, lossen uiteindelijk met zelfvertrouwen het verkeerde probleem op, omdat elk kanaal systematisch een ander soort gebruiker en een ander soort behoefte oververtegenwoordigt. Featureverzoeken prioriteren behandelt het rangschikken van wat al op het bord staat; dit gaat over het gat tussen wat het bord überhaupt bereikt en wat alleen ooit als supportticket verschijnt.

Waarom zou hetzelfde onderliggende probleem in het ene kanaal verschijnen en niet in het andere?

Omdat de twee kanalen verschillende activatiekosten hebben, en de grootte van die kosten bepaalt wie ze overwint. Een featureverzoek indienen vereist initiatief: een gebruiker moet geloven dat het verzoek de moeite waard is om te verwoorden, het bord vinden, en iets samenhangends schrijven, wat betrokken, geduldige gebruikers selecteert die al in het product hebben geïnvesteerd. Een supportticket indienen vereist in vergelijking bijna geen initiatief, vaak gewoon een klik op “help” midden in een taak, wat betekent dat het gefrustreerde gebruikers op het moment zelf vangt, inclusief degenen die zich nooit met een featureverzoekbord zouden bemoeien. Een echt gat in het product kan onzichtbaar zijn op het featurebord en luidruchtig in support simpelweg omdat de gebruikers die het raken, degenen zijn die het minst geneigd zijn een formeel verzoek in te dienen.

Betekent ticketvolume voor een ontbrekende feature hetzelfde als stemmenaantal ervoor?

Nee, omdat ze verschillende populaties meten onder verschillende omstandigheden. Een featureverzoek met honderd stemmen vertegenwoordigt honderd mensen die de tijd namen om een bestaand verzoek te vinden en te steunen, wat een sterk signaal is van duurzame, overwogen vraag. Honderd supporttickets over hetzelfde onderliggende gat, ingediend in dezelfde periode, vertegenwoordigen waarschijnlijk gebruikers die op het moment tegen een muur aanlopen, van wie sommigen het volledig zouden vergeten zodra de directe frictie voorbij is. Beide behandelen als gelijkwaardig “honderd mensen willen dit”-signaal overweegt het ticketvolume te zwaar, omdat tickets goedkoop zijn om te genereren en stemmen niet.

Wat betekent het als een feature supporttickets heeft maar bijna geen stemmen op het bord?

Vaak dat het verzoek bestaat maar de gebruikers die het raken niet weten dat het bord bestaat, niet geloven dat stemmen iets uithaalt, of het probleem te zelden tegenkomen om de moeite te nemen van kanaal te wisselen om het formeel te registreren. Dit is precies de populatie die een featureverzoekbord structureel mist, en een laag stemmenaantal hier is bewijs van een meetgat, niet van lage vraag. Behandel een cluster supporttickets rond een ontbrekende feature als een eigen signaal dat het waard is om zelf, namens de gebruikers, op het bord te loggen, in plaats van de tickets te wantrouwen, zodat het niet onzichtbaar blijft voor wie prioriteert op basis van alleen stemmenaantallen.

Bord leest als lage prioriteit:
"Export to CSV": 4 stemmen in 6 maanden

Support vertelt een ander verhaal:
"Export to CSV": 31 tickets in dezelfde periode, elk van
een ander account, elk gesloten met "momenteel niet
ondersteund, we geven de feedback door"

Betekent een piek in supporttickets altijd dat het onderliggende probleem een ontbrekende feature is?

Nee, en hier kunnen de twee kanalen in de tegenovergestelde richting misleiden. Een tickpiek wordt net zo vaak veroorzaakt door een verwarrende interface rond een al bestaande feature, een bug, of een verandering die zonder voldoende uitleg uitkwam, waarvan geen enkele wordt opgelost door iets nieuws te bouwen. Elke tickpiek lezen als “gebruikers willen een feature die we niet hebben” produceert een roadmap vol dingen die eigenlijk documentatiegaten of vermomde bruikbaarheidsproblemen waren. Het supportticket vertelt je waar de frictie zit; het vertelt je op zichzelf niet of de oplossing een nieuwe feature, een interfaceverandering, of een beter hulpartikel is, en dat door elkaar halen verspilt engineeringtijd aan de verkeerde oplossing.

Hoe zouden de twee signalen echt gecombineerd moeten worden bij het beslissen wat te bouwen?

Gebruik tickets om te vinden waar de frictie zit, en gebruik het featureverzoekbord, plus directe outreach waar het bord dun is, om te bevestigen hoe het werkelijk gewenste resultaat eruitziet. Een tickcluster identificeert een echt, gevoeld probleem; het specificeert zelden de oplossing precies genoeg om ertegen te bouwen, omdat een gefrustreerde gebruiker in een supportgesprek symptomen beschrijft, geen specificaties. Het featureverzoekbord, wanneer het genoeg stemmen heeft op hetzelfde onderliggende probleem, draagt doorgaans meer van het detail van “wat zou dit werkelijk bevredigen”, omdat het schrijven van een verzoek al een daad is van specificeren wat je wilt, niet alleen rapporteren wat er mis is.

Zouden supportagenten tickets zelf als featureverzoeken moeten loggen?

Ja, en dit is de enkele fix met de meeste hefboomwerking voor het gat tussen de twee kanalen. Een agent die een ticket herkent als een vermomd featureverzoek, in plaats van het gewoon op te lossen en verder te gaan, kan het namens de klant op het bord loggen, wat het meetgat direct dicht in plaats van te vereisen dat de klant een tweede kanaal ontdekt en gebruikt. Dit werkt alleen als loggen voor de agent seconden kost, geen minuten, zodat de frictie van het doen ervan lager is dan de frictie van gewoon het ticket sluiten en verdergaan naar het volgende.

FAQ

Zouden featureverzoekstemmen ooit gekort moeten worden als ze allemaal van één account of team komen? Ja, weeg naar afzonderlijke accounts of organisaties in plaats van naar ruw stemmenaantal, omdat vijf stemmen van vijf mensen bij hetzelfde bedrijf de prioriteiten van één klant vertegenwoordigen, niet vijf onafhankelijke bevestigingen van vraag.

Is het de moeite waard om een feature te bouwen die zwaar in tickets voorkomt maar bijna geen stemmen heeft? Vaak wel, mits het ticketvolume echt van afzonderlijke accounts komt en de onderliggende behoefte bevestigd is in plaats van aangenomen; behandel het lage stemmenaantal als een meetartefact van de activatiekosten van het bord, niet als bewijs dat de vraag niet echt is.

Hoe onderscheid je op het eerste gezicht een UI-verwarringsticket van een echt ontbrekende-featureticket? Kijk of de oplossing bestaat uit het uitleggen van een bestaande mogelijkheid of het verontschuldigen voor een ontbrekende. Een patroon van “oh, het staat er eigenlijk gewoon”-oplossingen wijst op een interface- of vindbaarheidsprobleem; een patroon van “dat ondersteunen we nog niet” wijst op een echt gat.

Doet dit onderscheid er evenveel toe bij een heel klein supportvolume? Minder mechanisch, aangezien een handvol tickets makkelijk individueel te lezen is zonder geaggregeerde analyse nodig te hebben, maar de onderliggende bias, tickets oververtegenwoordigen gefrustreerde gebruikers en ondervertegenwoordigen geduldige, is aanwezig op elke schaal en het waard om in gedachten te houden zelfs wanneer je elk ticket zelf leest.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken