Gromadzenie użytkowników do swojego narzędzia do śledzenia błędów

Mam w pełni skonfigurowany moduł śledzenia błędów modliszki do śledzenia problemów w tworzonych przeze mnie aplikacjach. Gdy użytkownik zostanie zdyscyplinowany i przejdzie bezpośrednio do modliszki, aby napisać raport o problemie, uzyska najszybszą odpowiedź, a wszystko dotyczące problemu będzie bardzo łatwe do śledzenia.

Jednak nie wszyscy chcą to zrobić. Zgłaszają swoje problemy przez telefon, e-mail, w ogóle ich nie zgłaszają.

Jaki byłby najlepszy sposób, aby skłonić ich do korzystania z systemu śledzenia błędów? Najwyraźniej MUSZĄ zobaczyć natychmiastowe korzyści, aby mogli wrócić i poszukać dodatkowych korzyści.

EDYTOWAĆ:

Mówię o wsparciu dla produktów, które sprzedaję jako niezależny dostawca oprogramowania.

Twój moduł do śledzenia błędów służy Twojej wygodzie, a nie Twoim klientom. Jak możesz się czuć, jeśli nie chcesz, aby problem z telefonem lub e-mailem został wprowadzony samodzielnie?

Musisz mieć możliwość wprowadzania problemów i przypisywania ich ręcznie do klienta. Następnie, gdy zadzwonią z problemem, możesz powiedzieć: „Dziękuję za zgłoszenie tego! Zamierzam wprowadzić go do naszego systemu zarządzania problemami, a Ty zaczniesz otrzymywać wiadomości e-mail (lub cokolwiek innego) w trakcie ich rozwiązywania. W w przyszłości, jeśli jest to dla ciebie łatwe, możesz wprowadzić takie rzeczy właśnie tam. Możesz też do mnie zadzwonić, to też jest w porządku ”.

Jednym z najlepszych takich systemów, z którymi współpracowałem jako klient, jest ten od dostawcy hostingu, który sprzedaje. Wiadomość e-mail do obsługi @ jest analizowana pod kątem nazwy domeny w temacie, przypisywana do konta klienta na podstawie adresu od i automatycznie wprowadzana do systemu zgłoszeń. Całkiem zręczny.

Użytkownik, który narzeka, jest lepszy niż ten, który tego nie robi, poddaje się i dzwoni do konkurenta. Z tego powodu ułatwiłbym wysłanie skargi tak łatwo, jak to możliwe. Pozwoliłbym im nadal dzwonić i / lub wysyłać e-maile i nie prosić ich o zgłaszanie błędów.

Spójrz na to z ich punktu widzenia - jeśli musiałbyś nie tylko poświęcić trochę czasu, aby zadzwonić / napisać e-mail, ale także zostać zmuszony do nauki czyjegoś chwiejnego systemu śledzenia błędów - szanse, że po prostu nie będziesz narzekał.

W razie potrzeby zatrudnij pracownika działu obsługi klienta, aby programiści nie zostali przerwani. Mogą przyjmować skargi od klientów i robić błędy dla zespołu programistów.

Nie znam konkretnie Mantis, ale czy można ją skonfigurować do monitorowania adresu e-mail i automatycznego generowania raportów na ich podstawie? Znam inne systemy (na przykład JIRA może).

Problem polega na tym, że zmuszają ich do używania właściwego adresu e-mail!

„Zgłoś to na narzędziu do śledzenia błędów na stronie http: // your / url / . Nie mogę śledzić błędów, jeśli ich tam nie zgłosisz.”

Być może możesz napisać wtyczkę dla swojego klienta poczty, aby zamienić wiadomość e-mail w raport o błędzie lub użyć dedykowanej skrzynki pocztowej - bugs @ foo - do przyjmowania raportów o błędach. (Ale to ostatnie oczywiście wymaga przeszkolenia użytkowników ...)

Wewnętrznie mamy szablon witryny dla aplikacji internetowych, który zawiera łącze zwrotne w rogu. Ten link zwrotny zapewnia użytkownikowi okno dialogowe interfejsu użytkownika jQuery, które monituje go o opis błędu, nowej funkcji lub innego napotkanego przez niego problemu, a także przechwytuje niektóre szczegóły dotyczące strony i czasu, z którego się zgłasza. Wszystko to jest przesyłane bezpośrednio do JIRA za kulisami, a użytkownik może otrzymywać aktualizacje o statusie problemu.

W pewnym sensie najlepszym sposobem na zrobienie czegoś jest zwykle uczynienie go tak prostym, jak to możliwe dla użytkowników, jeśli w menu, które obsługuje wysyłanie informacji tam, gdzie musi się znaleźć, znajduje się łącze zwrotne, to jest o wiele bardziej prawdopodobne, że z nich skorzystają.

Cóż, jeśli chcesz użyć globalnego modułu obsługi wyjątków, masz wiele opcji. W przypadku Delphi korzystamy z MadExcept, ale korzystaliśmy również z Eureka Log, z których oba będą (wraz z użytkownikiem) e-mailem lub prześlą przez HTTP zgłoszenie błędu.

Możesz mieć przycisk w swojej aplikacji, który po prostu zgłasza wyjątek i uruchamia funkcje śledzenia błędów. MadExcept jest całkiem fajny, ponieważ wykonuje zrzut ekranu aplikacji i przesyła go wraz z błędem, w ten sposób nawet jeśli użytkownik nie może poprawnie wyjaśnić, co robią, możesz mieć całkiem niezłą tęsknotę.

Należy jeszcze pomyśleć o kodowaniu, aby było oczywiste, skąd pochodzą błędy. Jeśli masz użytkowników wersji beta, być może dołącz do swoich aplikacji informacje o debugowaniu, aby uzyskać od nich dodatkowe dane w przypadku awarii.

Nic z tego nie pomaga w błędach implementacyjnych (tj. Przycisk znajduje się w niewłaściwym miejscu), ale mam nadzieję, że nie masz żadnego z nich.

Największy wzrost absorpcji osiągnęliśmy poprzez skonfigurowanie usługi do pobierania wiadomości e-mail z adresu i automatycznego rejestrowania jej jako problemu. Fajnym efektem ubocznym tego systemu jest to, że możesz łatwo dodawać rozmowy do problemu, włączając specjalną składnię w temacie (np. TeamITNo: 12345). Ponadto, jeśli wyślesz całą swoją wiadomość e-mail za pośrednictwem tego systemu, a oni uderzą odpowiedź, otrzymasz odpowiedź z powrotem do narzędzia do śledzenia błędów, ze zaktualizowanym problemem.

Miało to największy pozytywny efekt, ponieważ wykorzystuje technologię, z którą użytkownicy czują się komfortowo, a także oznacza, że ​​wszystkie problemy masz w jednym miejscu.