Pracownik sklepu internetowego odpowiedział kupującemu, oznaczył zgłoszenie jako rozwiązane i przeszedł do następnego. Następnego dnia kupujący pisze ponownie: zwrot pieniędzy jeszcze nie dotarł, a z poprzedniej wiadomości nie wynika jasno, kiedy należy się go spodziewać. W raporcie zespół ma już jedną rozwiązaną sprawę, ale dla klienta praca nie została zakończona.
Ponownie otwarte zgłoszenia pomagają dostrzec tę różnicę. Jednak sama zmiana statusu nie dowodzi jeszcze błędu konsultanta: ktoś mógł podziękować, zadać nowe pytanie lub poinformować, że problem powrócił. Jeśli połączy się te sytuacje, wskaźnik będzie jedynie wywierał dodatkową presję na zespół.
Lepiej zbudować niewielki proces, nad którym można zapanować: uzgodnić, co uznawać za ponowne otwarcie, liczyć je według jednakowych zasad i analizować przyczyny. Poniżej przedstawiamy praktyczną metodę dla kierownika wsparcia, który chce ograniczyć zbędną pracę, a nie tylko poprawić liczbę w raporcie.
Co dokładnie uznawać za ponownie otwarte zgłoszenie
Ponowne otwarcie to powrót już rozwiązanego zgłoszenia do obsługi. W poszczególnych systemach nazwy statusów i zasady takiego przejścia mogą się różnić. Dlatego najpierw opisz zdarzenie biznesowe: zespół uznał sprawę za rozwiązaną, ale z tego samego powodu znów potrzebny jest jego udział.
Odróżnij je od ponownego kontaktu. Klient może utworzyć nowe zgłoszenie dotyczące tego samego nierozwiązanego problemu — wtedy status starego się nie zmienia, choć pojawia się dodatkowa praca. I odwrotnie: odpowiedź „Dziękuję” może zmienić status, ale nie wymagać ponownego rozwiązania sprawy. Licznik techniczny i ocena jakości odpowiadają na różne pytania.
Nie sprowadzaj też liczby zgłoszeń i liczby ponownych otwarć do jednego wskaźnika. Jedno zgłoszenie może wracać do obsługi kilka razy. Na przykład w przewodniku po metrykach Zendesk osobno opisano Reopened tickets i Reopens. Ilustruje to różnicę definicji, a nie potwierdza dostępności analogicznych raportów w HelpDeskStar.
Zapisz krótką zasadę dla zespołu: jak postępować z podziękowaniem, nowym tematem w starej rozmowie, omyłkowym zamknięciem i powrotem tej samej usterki. Nie trzeba sztucznie utrzymywać starej rozmowy otwartej ani ukrywać nowego problemu w poprzedniej wyłącznie dla statystyk.
Jak mierzyć odsetek bez błędnego mianownika
Do analizy wewnętrznej wygodnie jest wybrać kohortę — określoną grupę zgłoszeń — i obserwować każde przez taki sam czas. Na przykład wybierz zgłoszenia, które po raz pierwszy oznaczono jako rozwiązane w danym tygodniu, i sprawdź ich powrót do obsługi w ciągu kolejnych siedmiu dni kalendarzowych po pierwszym rozwiązaniu każdego z nich. Siedem dni to tutaj przykład roboczy, a nie norma branżowa.
Odsetek ponownie otwartych zgłoszeń = liczba unikalnych zgłoszeń w kohorcie, które wróciły do obsługi w określonym oknie, / liczba wszystkich unikalnych zgłoszeń w tej kohorcie × 100%. W liczniku i mianowniku muszą znaleźć się zgłoszenia z tej samej grupy. Każde zgłoszenie w liczniku uwzględniaj raz, nawet jeśli wracało wielokrotnie.
Nie dziel wszystkich ponownych otwarć w tym miesiącu przez wszystkie zamknięcia z tego samego miesiąca bez dodatkowych zastrzeżeń. Część powrotów będzie dotyczyć starszych zgłoszeń, a od najnowszych zamknięć nie minie jeszcze wystarczająco dużo czasu na obserwację. Taki bieżący raport operacyjny może być przydatny, ale to inny wskaźnik, nie odsetek kohortowy.
Poczekaj na pełne okno obserwacji
Jeśli ostatnie zgłoszenie kohorty rozwiązano w piątek, podsumowanie z siedmiodniowym oknem można sporządzić dopiero po upływie odpowiedniego terminu dla tego zgłoszenia. Do tego czasu oznaczaj raport jako wstępny. W przeciwnym razie ostatni tydzień niemal zawsze będzie wyglądał lepiej, ponieważ klienci nie zdążyli jeszcze wrócić.
Osobno przechowuj łączną liczbę zdarzeń ponownego otwarcia. Pokaże ona pracochłonność: dwa zespoły z takim samym odsetkiem mogą mieć różną liczbę cykli do ostatecznego rozwiązania. Przy ocenie przyczyn warto uwzględnić również nowe zgłoszenia dotyczące tego samego problemu, ale nie mieszać ich niepostrzeżenie z techniczną metryką statusów.
W małej próbie zawsze pokazuj liczby bezwzględne obok odsetka. Porównuj przede wszystkim te same kategorie spraw i jednakowe okna obserwacji. Ogólna liczba może się zmienić tylko dlatego, że zespół zaczął otrzymywać więcej złożonych zapytań technicznych, a nie z powodu pogorszenia pracy.
Jakie dane są potrzebne do analizy przyczyn
Zacznij od historii zgłoszenia, a nie od nazwiska konsultanta. Dla każdego powrotu potrzebne są identyfikator zgłoszenia, kategoria problemu, moment pierwszego rozwiązania, moment powrotu, ostatnia odpowiedź przed zamknięciem i kolejna wiadomość klienta. Jeśli w systemie nie ma gotowego raportu, ograniczoną próbę można sklasyfikować ręcznie w arkuszu z linkami do zgłoszeń.
Nie kopiuj do takiego arkusza numerów telefonów, danych płatniczych ani pełnych rozmów bez potrzeby. Do analizy zarządczej zwykle wystarczą identyfikator, krótki opis przyczyny oraz dostęp do oryginału wyłącznie dla upoważnionych pracowników. Arkusz ma pomagać w pracy, a nie tworzyć kolejną niekontrolowaną bazę danych klientów.
Do pierwszej analizy wystarczy kilka zrozumiałych kategorii:
- Problemu nie usunięto. Udzielono odpowiedzi pośredniej lub sprawdzono niewłaściwy scenariusz.
- Odpowiedź jest niezrozumiała. Pominięto warunki, termin lub kolejne działanie klienta.
- Potrzebne jest działanie innego działu. Wsparcie zamknęło zgłoszenie przed potwierdzeniem wyniku.
- Problem wystąpił ponownie. Pierwotne rozwiązanie zadziałało, ale usterka się powtórzyła.
- Sprawa nie wymaga ponownego rozwiązania. Podziękowanie, nowy temat lub administracyjna zmiana statusu.
Dopuść oznaczenie „Przyczyna nie została jeszcze ustalona”. Przypisanie sytuacji na siłę do wygodnej kategorii tworzy fałszywą pewność. Jeśli przyczyn jest kilka, wybierz główną do raportu i dodaj krótkie wyjaśnienie, nie zamieniając klasyfikacji w dziesiątki niemal identycznych opcji.
Sprawdzaj wniosek razem z osobą obsługującą zgłoszenie
Kierownik powinien przejrzeć kolejność zdarzeń i omówić ją z pracownikiem. Konsultant mógł zamknąć zgłoszenie zgodnie z obowiązującą instrukcją, podczas gdy sama instrukcja nie uwzględniała opóźnienia płatności lub odpowiedzi podwykonawcy. Ukaranie osoby obsługującej sprawę nie usunie takiej przyczyny.
Podobnie nie każda nowa wiadomość oznacza niską jakość. Jeśli kupujący pyta w starej rozmowie o inne zamówienie, nowy temat wymaga prawidłowego przekierowania. Jeśli informuje o ponownej usterce, trzeba sprawdzić trwałość rozwiązania. Jednakowy status nie sprawia, że te sytuacje są takie same.
Jak ograniczyć ponowne kontakty, zamiast je ukrywać
Dla każdej częstej przyczyny określ jedną zmianę procesu i osobę za nią odpowiedzialną. Gdy odpowiedzi są niezrozumiałe, dopracuj wiadomość końcową. Gdy nie wykonano pracy, od której zależy rozwiązanie — zmień warunek zamknięcia. Gdy powraca błąd produktu — przekaż zespołowi, który może usunąć jego źródło, konkretny opis warunków odtworzenia.
Z końcowej odpowiedzi powinno jasno wynikać, co zrobiono, jaki wynik sprawdzono i co robić dalej. Jeśli działanie nadal trwa, uczciwie podaj jego stan oraz uzgodniony kolejny kontakt zamiast formalnego „Sprawa została rozwiązana”. Nie obiecuj dokładnego terminu w imieniu innego działu, jeśli go nie potwierdzono.
W typowych sprawach przydają się szablony i instrukcje, ale szablon nie zastępuje sprawdzenia konkretnego przypadku. Wyjaśnienie dotyczące zwrotu pieniędzy musi uwzględniać etap transakcji. Porada dotycząca dostępu — obejmować sprawdzenie, czy użytkownik rzeczywiście zdołał się zalogować. Zbyt ogólną odpowiedź wysyła się szybko, ale często przerzuca ona diagnostykę na klienta.
Nie wyznaczaj zespołowi celu „zero ponownych otwarć” bez oceny jakości. Taki wymóg może skłaniać do niezamykania rozwiązanych zgłoszeń lub tworzenia nowych zamiast ponownego otwierania starych. Razem z odsetkiem powrotów analizuj niezakończone zgłoszenia, czas do rzeczywistego rozwiązania i treść odpowiedzi. Lepsza liczba powinna oznaczać mniejszy wysiłek klienta, a nie inny sposób prowadzenia ewidencji.
Przykład: zwrot pieniędzy w sklepie internetowym
Hipotetyczny zespół zauważył, że kupujący piszą ponownie po wiadomości „Zwrot został zlecony”. Analiza pokazuje dwie różne sytuacje: księgowość nie potwierdziła jeszcze transakcji albo płatność już wysłano, ale klient nie rozumie dalszego postępowania. To scenariusz szkoleniowy, a nie studium przypadku firmy ze zmierzonymi wynikami.
W pierwszej sytuacji zespół zmienia zasadę: wiadomość pracownika nie jest potwierdzeniem zakończonej transakcji. W zgłoszeniu pozostają osoba odpowiedzialna, oczekiwane działanie księgowości i moment kolejnej kontroli. W drugiej — doprecyzowuje się treść odpowiedzi: co dokładnie już zrobiono, jakie są potwierdzone warunki oczekiwania i kiedy skontaktować się ponownie, jeśli pieniądze nie dotarły.
Po zmianie porównuje się dwie zakończone kohorty właśnie z tej kategorii, z jednakowym oknem obserwacji. Dodatkowo czyta się pozostałe powroty: być może teraz dominuje inna przyczyna. Nie należy z góry obiecywać określonego procentu poprawy — można go ustalić wyłącznie na podstawie rzeczywistych danych.
Jakie narzędzia wybrać i gdzie pomoże HelpDeskStar
Przy niewielkiej liczbie zgłoszeń i jednej osobie zajmującej się ich obsługą można zacząć od ręcznego rejestru. Pozwoli on sprawdzić definicje i kategorie bez osobnego projektu automatyzacji. Ograniczenia tego podejścia to nakład czasu, ryzyko pominięcia zdarzenia i trudność w uzgadnianiu historii między pracownikami.
Gdy zgłoszenia napływają różnymi kanałami i wymagają udziału kilku osób, ważne jest zachowanie kontekstu we wspólnym systemie. W artykule o wyborze helpdesku dla małej firmy opisano podstawowe możliwości HelpDeskStar: pracę ze statusami, osobami odpowiedzialnymi, historią komunikacji i zadaniami wewnętrznymi. Pomagają one zorganizować sam proces analizy i realizację ustaleń.
Przed wdrożeniem sprawdź na własnym scenariuszu, jak w Twojej konfiguracji zmienia się status po odpowiedzi klienta, kto otrzymuje takie zgłoszenie i gdzie widać wcześniejsze działania. Osobno ustal możliwość uzyskania danych potrzebnych do obliczeń. Samo istnienie statusów nie oznacza, że system ma gotowy raport kohortowy lub automatycznie określa przyczynę powrotu.
Nie warto zmieniać całej platformy wyłącznie dla jednego wskaźnika. Jeśli obecne narzędzie niezawodnie przechowuje historię i pozwala zebrać potrzebne dane, najpierw popraw proces. Jeśli jednak kontekst ginie między czatami i działami, problem wykracza poza analitykę: zespół potrzebuje wspólnego miejsca do obsługi zgłoszeń.
Od czego powinien zacząć kierownik wsparcia
Wybierz jedną kategorię zgłoszeń, uzgodnij definicję ponownego otwarcia i ustal jednakowe okno obserwacji. Przejrzyj zakończoną kohortę, oddziel techniczne zmiany statusu od powrotów nierozwiązanego problemu i znajdź przyczynę, na którą zespół może wpłynąć. Wprowadź jedną konkretną zmianę i sprawdź ją na następnej porównywalnej grupie.
Jeśli brakuje do tego wspólnej historii i jasnej odpowiedzialności, omów z zespołem HelpDeskStar demonstrację na przykładzie jednego z Twoich ponownych zgłoszeń. Sprawdzaj nie abstrakcyjną liczbę funkcji, lecz całą ścieżkę: powrót klienta, odtworzenie kontekstu, działanie osoby obsługującej i potwierdzenie wyniku.