Zgłoszenia do supportu vs. prośby o funkcje: czemu ufać?

Tablica próśb o funkcje wychwytuje to, o co proszą użytkowniczki, gdy mają czas usiąść i opisać, czego chcą. Zgłoszenie do supportu wychwytuje to, na czym utknęły użytkowniczki właśnie teraz, często zirytowane, często bez słownictwa, by porządnie opisać leżącą u podstaw prośbę. Oba są prawdziwym sygnałem, a zespoły, które patrzą tylko na jedno z dwóch, kończą pewnym siebie rozwiązywaniem złego problemu, ponieważ każdy kanał systematycznie nadreprezentuje inny typ użytkowniczki i inny typ potrzeby. Priorytetyzacja próśb o funkcje opisuje rankingowanie tego, co już jest na tablicy; ten tekst dotyczy luki między tym, co w ogóle trafia na tablicę, a tym, co pojawia się tylko jako zgłoszenie do supportu.

Dlaczego ten sam podstawowy problem pojawiłby się w jednym kanale, a nie w drugim?

Ponieważ oba kanały mają różne koszty aktywacji, a wielkość tego kosztu decyduje, kto go pokona. Zgłoszenie prośby o funkcję wymaga inicjatywy: użytkowniczka musi uwierzyć, że warto ją sformułować, znaleźć tablicę, i napisać coś spójnego, co selekcjonuje zaangażowane, cierpliwe użytkowniczki już zainwestowane w produkt. Zgłoszenie do supportu wymaga w porównaniu prawie żadnej inicjatywy, często tylko kliknięcia “pomoc” w środku zadania, co oznacza, że wychwytuje sfrustrowane użytkowniczki w danej chwili, w tym te, które nigdy nie zawracałyby sobie głowy tablicą próśb. Prawdziwa luka w produkcie może być niewidoczna na tablicy funkcji i głośna w supporcie po prostu dlatego, że użytkowniczki, które na nią trafiają, są najmniej skłonne zgłosić formalną prośbę.

Czy wolumen zgłoszeń dla brakującej funkcji znaczy to samo co liczba głosów na nią?

Nie, ponieważ mierzą różne populacje w różnych warunkach. Prośba o funkcję ze stoma głosami reprezentuje sto osób, które poświęciły czas, by znaleźć i poprzeć istniejącą prośbę, co jest silnym sygnałem trwałego, przemyślanego popytu. Sto zgłoszeń do supportu na temat tej samej podstawowej luki, zgłoszonych w tym samym okresie, prawdopodobnie reprezentuje użytkowniczki, które w danej chwili uderzają w ścianę, z których niektóre całkowicie by o tym zapomniały, gdy tylko minie bezpośrednie tarcie. Traktowanie obu jako równoważnego sygnału “sto osób tego chce” nadmiernie waży wolumen zgłoszeń, ponieważ zgłoszenia są tanie w generowaniu, a głosy nie.

Co oznacza, gdy funkcja ma zgłoszenia do supportu, ale prawie żadnych głosów na tablicy?

Często, że prośba istnieje, ale użytkowniczki, które na nią trafiają, nie wiedzą, że tablica istnieje, nie wierzą, że głosowanie coś zmieni, lub trafiają na problem zbyt rzadko, by zawracać sobie głowę zmianą kanału, żeby go formalnie zarejestrować. To dokładnie populacja, którą tablica próśb strukturalnie pomija, a niska liczba głosów tutaj jest dowodem luki pomiarowej, nie niskiego popytu. Zamiast nie ufać zgłoszeniom, traktujcie klaster zgłoszeń do supportu wokół brakującej funkcji jako własny sygnał, wart zarejestrowania na tablicy przez was samych, w imieniu użytkowniczek, żeby nie pozostał niewidoczny dla kogokolwiek, kto priorytetyzuje tylko na podstawie liczby głosów.

Tablica czyta się jako niski priorytet:
"Export to CSV": 4 głosy w 6 miesięcy

Support opowiada inną historię:
"Export to CSV": 31 zgłoszeń w tym samym okresie, każde
z innego konta, każde zamknięte słowami "obecnie
nieobsługiwane, przekażemy dalej opinię"

Czy skok zgłoszeń do supportu zawsze oznacza, że podstawowym problemem jest brakująca funkcja?

Nie, i tu oba kanały mogą wprowadzać w błąd w przeciwnym kierunku. Skok zgłoszeń jest równie często spowodowany mylącym interfejsem wokół już istniejącej funkcji, błędem, lub zmianą, która wyszła bez odpowiedniego wyjaśnienia, z czego żadne nie rozwiązuje się budowaniem czegoś nowego. Czytanie każdego skoku zgłoszeń jako “użytkowniczki chcą funkcji, której nie mamy” tworzy roadmapę pełną rzeczy, które w rzeczywistości były lukami w dokumentacji lub przebranymi problemami użyteczności. Zgłoszenie do supportu mówi wam, gdzie jest tarcie; samo nie mówi wam, czy rozwiązaniem jest nowa funkcja, zmiana interfejsu, czy lepszy artykuł pomocy, a mylenie tego marnuje czas inżynierski na złe rozwiązanie.

Jak oba sygnały powinny być naprawdę łączone przy decydowaniu, co budować?

Używajcie zgłoszeń, by znaleźć, gdzie jest tarcie, i używajcie tablicy próśb, plus bezpośredniego kontaktu tam, gdzie tablica jest uboga, by potwierdzić, jak naprawdę wygląda pożądany rezultat. Klaster zgłoszeń identyfikuje prawdziwy, odczuwany problem; rzadko określa rozwiązanie wystarczająco precyzyjnie, by na nim budować, ponieważ sfrustrowana użytkowniczka w rozmowie z supportem opisuje objawy, nie specyfikacje. Tablica próśb, gdy ma wystarczająco głosów na ten sam podstawowy problem, zwykle niesie więcej ze szczegółu “co by to naprawdę zaspokoiło”, ponieważ napisanie prośby jest już aktem określenia, czego się chce, nie tylko zgłoszenia, co jest nie tak.

Czy agentki supportu powinny same rejestrować zgłoszenia jako prośby o funkcje?

Tak, i to najbardziej dźwigniowa poprawka luki między dwoma kanałami. Agentka, która rozpoznaje zgłoszenie jako przebraną prośbę o funkcję, zamiast po prostu je rozwiązać i iść dalej, może zarejestrować je na tablicy w imieniu klienta, co bezpośrednio zamyka lukę pomiarową zamiast wymagać, by klient sam odkrył i użył drugiego kanału. To działa tylko, jeśli rejestrowanie zajmuje agentce sekundy, nie minuty, żeby tarcie związane z tym było niższe niż tarcie zwykłego zamknięcia zgłoszenia i przejścia do następnego.

FAQ

Czy głosy próśb o funkcje powinny kiedykolwiek być dyskontowane, jeśli wszystkie pochodzą z jednego konta lub zespołu? Tak, ważcie według odrębnych kont lub organizacji zamiast surowej liczby głosów, ponieważ pięć głosów od pięciu osób z tej samej firmy reprezentuje priorytety jednego klienta, nie pięć niezależnych potwierdzeń popytu.

Czy warto budować funkcję, która często pojawia się w zgłoszeniach, ale ma prawie żadnych głosów? Często tak, o ile wolumen zgłoszeń naprawdę pochodzi z odrębnych kont, a podstawowa potrzeba jest potwierdzona, a nie zakładana; traktujcie niską liczbę głosów jako artefakt pomiarowy kosztu aktywacji tablicy, nie jako dowód, że popyt nie jest prawdziwy.

Jak na pierwszy rzut oka odróżnić zgłoszenie o zamieszaniu w interfejsie od prawdziwego zgłoszenia o brakującej funkcji? Spójrzcie, czy rozwiązanie polega na wyjaśnieniu istniejącej możliwości, czy na przeprosinach za brakującą. Wzorzec rozwiązań “och, to faktycznie tam jest” wskazuje na problem interfejsu lub odkrywalności; wzorzec “jeszcze tego nie obsługujemy” wskazuje na prawdziwą lukę.

Czy to rozróżnienie ma tak samo duże znaczenie przy bardzo małym wolumenie supportu? Mniej mechanicznie, ponieważ garstkę zgłoszeń łatwo czyta się pojedynczo bez potrzeby zagregowanej analizy, ale podstawowe odchylenie, zgłoszenia nadreprezentują sfrustrowane użytkowniczki i niedoreprezentują cierpliwe, jest obecne na każdą skalę i warto o nim pamiętać, nawet gdy sami czytacie każde zgłoszenie.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Porównanie narzędzi do changeloga