Jak przygotować raport zgłoszeń wsparcia: krok po kroku

Raport ze zgłoszeń wsparcia to w głównej mierze kwestia definicji. Utworzone zgłoszenia, rozwiązane zgłoszenia, czas pierwszej odpowiedzi i czas rozwiązania – wszystko to brzmi dość oczywiście. Jednak każdy z tych wskaźników ma więcej niż jedno oficjalne znaczenie w obrębie tego samego help desku.

Ustal zasady zliczania, a raport napisze się sam. Pomiń ten krok, a dwie uczciwe osoby pobiorą ten sam plik eksportu i ich wyniki będą się różnić o całe godziny.

Ten przewodnik wyjaśnia, co powinno znaleźć się w raporcie, w których czterech miejscach rozchodzą się definicje oraz jak go przygotować na podstawie eksportu zgłoszeń.

Co powinno znaleźć się w raporcie ze zgłoszeń wsparcia

Sama liczba zgłoszeń niewiele mówi. Dopiero odpowiednie zestawienie danych sprawia, że liczby te stają się wiarygodne.

Element	Dlaczego się tu znajduje
Zgłoszenia utworzone w danym okresie	Strona popytu
Zgłoszenia rozwiązane w danym okresie	Strona podaży, według określonej reguły statusu
Backlog na koniec okresu	Wszystko, co nie zostało rozwiązane lub zamknięte
Czas pierwszej odpowiedzi	Według określonego czasu pracy i zdefiniowanej reguły
Czas rozwiązania	Pierwsze lub pełne, jasno określone
Ponownie otwarte zgłoszenia	Sygnał jakości, który ukrywają inne liczby
Zgłoszenia bez odpowiedzi	Miejsca, w których proces całkowicie zawiódł
Określony przedział czasowy i zakres	Które kanały, marki i kolejki zostały uwzględnione

Dwa wiersze mają większe znaczenie, niż mogłoby się wydawać. Ponownie otwarte zgłoszenia oraz te bez odpowiedzi to miejsca, w których raport przestaje być tylko tablicą wyników, a staje się użytecznym narzędziem.

Zendesk publikuje stosowane formuły, dzięki czemu definicje można zweryfikować, zamiast opierać się na opiniach. Ich dokumentacja metryk i atrybutów szczegółowo opisuje każdą z nich.

Zacznijmy od najprostszego. Rozwiązane zgłoszenia to „liczba rozwiązanych lub zamkniętych zgłoszeń”, więc metryka ta obejmuje dwa statusy zamiast jednego.

„Czas pierwszej odpowiedzi” ma dwie oficjalne definicje

To właśnie ta rozbieżność wywołuje najwięcej sporów, przed czym bezpośrednio ostrzega sam dostawca.

W dokumentacji SLA firmy Zendesk ujęto to w jednym zdaniu: „Nie należy mylić czasu odpowiedzi SLA z natywną metryką czasu odpowiedzi Zendesk”.

Natywna metryka rygorystycznie podchodzi do tego, kto odpowiada. Zendesk wskazuje, że „czas pierwszej odpowiedzi jest obliczany wyłącznie na podstawie odpowiedzi agentów”. Działania automatyczne oraz te wykonywane przez boty „nie są brane pod uwagę przy obliczaniu czasu pierwszej odpowiedzi”.

W przypadku metryki SLA jest inaczej. Tam czas pierwszej odpowiedzi to „czas między utworzeniem zgłoszenia a pierwszym publicznym komentarzem agenta (lub automatyczną odpowiedzią)”. Zendesk dodaje, że „metryki czasu odpowiedzi są spełnione, jeśli skonfigurujesz regułę (trigger) do automatycznego odpowiadania publicznym komentarzem”.

Zestawienie tych dwóch faktów prowadzi do jasnego wniosku. Automatyczna odpowiedź może spełnić wymogi celu SLA, podczas gdy natywny czas pierwszej odpowiedzi będzie nadal naliczany.

Raport wykazujący 98% realizacji SLA i medianę czasu pierwszej odpowiedzi na poziomie czterech godzin nie jest więc wewnętrznie sprzeczny. Przedstawia on dwie różne kwestie i obie robi to poprawnie.

Warto znać jeszcze dwa mniejsze wyjątki. W przypadku, gdy to agent tworzy zgłoszenie, a pierwszy komentarz jest publiczny, dokumentacja metryk czasu trwania wskazuje, że drugi znacznik czasu „przesuwa się na drugi publiczny komentarz agenta”.

Udostępnione zgłoszenia również się nie liczą. Zendesk zaznacza, że gdy agent dodaje publiczny komentarz z innego konta przy użyciu funkcji udostępniania zgłoszeń, „nie wlicza się to do czasu pierwszej odpowiedzi na Twoim koncie”.

„Czas rozwiązania” również ma dwie definicje

Ten sam podział dotyczy metryk czasu rozwiązania i w tym przypadku obie wersje są dostępne domyślnie.

Czas pierwszego rozwiązania to „czas między utworzeniem zgłoszenia a jego pierwszym rozwiązaniem”, kończący się w momencie, „gdy status zgłoszenia po raz pierwszy zostanie ustawiony jako rozwiązany”.

Czas pełnego rozwiązania to „czas między utworzeniem zgłoszenia a jego ostatnim rozwiązaniem”. Kończy się on w momencie, „gdy status zgłoszenia po raz ostatni zostanie ustawiony jako rozwiązany”.

Dla zgłoszenia rozwiązanego tylko raz obie te wartości są identyczne. W przypadku zgłoszenia, które zostało rozwiązane, otwarte ponownie i rozwiązane jeszcze raz, wartości te będą się różnić o czas, jaki zajęła druga runda.

Dokładnie dlatego ponownie otwarte zgłoszenia powinny znaleźć się w raporcie. Zendesk definiuje je jako zgłoszenia „ponownie otwarte po uprzednim rozwiązaniu” i zaznacza, że metryka ta „nie obejmuje zgłoszeń rozwiązanych i ponownie otwartych w ramach tej samej aktualizacji”.

Istnieje też efekt drugiego rzędu, który często umyka uwadze. Dzienna średnia rozwiązanych zgłoszeń uwzględnia je „tylko wtedy, gdy są one obecnie rozwiązane lub zamknięte”. Zatem zgłoszenie otwarte ponownie dzisiaj po cichu znika z liczby rozwiązanych zgłoszeń z zeszłego miesiąca.

Raport wygenerowany w czerwcu nie pokryje się więc z raportem wygenerowanym w sierpniu. Nic się nie zepsuło – po prostu zmienił się status bazowy zgłoszenia.

Dwie kolejne metryki pozwalają oddzielić czas oczekiwania od czasu pracy. Czas oczekiwania zgłaszającego to łączny czas spędzony w statusach: nowe (new), otwarte (open) i wstrzymane (on-hold), natomiast czas oczekiwania agenta to łączny czas w statusie oczekujące (pending).

Ta para wskaźników odpowiada na pytanie, na które średni czas rozwiązania nie potrafi odpowiedzieć. Długi czas rozwiązania wynikający z oczekiwania na klienta to zupełnie inny problem niż długi czas rozwiązania spowodowany przepełnieniem kolejki.

Godziny kalendarzowe czy godziny robocze

Każda wartość dotycząca odpowiedzi i rozwiązania może być mierzona według dwóch różnych zegarów, a wybór jednego z nich jest koniecznością.

Zendesk zapisuje obie te wartości. Po pierwszej publicznej odpowiedzi „system oblicza czas pierwszej odpowiedzi w godzinach kalendarzowych oraz roboczych”. Obie te metryki „są przechowywane wraz z danymi zgłoszenia”.

Domyślny widok nie jest neutralny. Zendesk zaznacza, że gotowe raporty Explore „wyświetlają informacje w godzinach kalendarzowych”. Metryki oparte na godzinach roboczych „są dostępne i mogą być używane w Twoich własnych raportach”.

Z tego względu zespół pracujący w godzinach od dziewiątej do siedemnastej będzie wyglądał na mało wydajny w domyślnym raporcie. Zgłoszenie, które wpłynie w piątek o 6 wieczorem, przed poniedziałkowym porankiem naliczy około 63 godzin kalendarzowych i niemal zero godzin roboczych.

Kanały komunikacji na żywo wprowadzają dodatkową komplikację. Metryka czasu pierwszej odpowiedzi (w sekundach) dla wiadomości i czatu „ignoruje ustawienia godzin roboczych dla wiadomości oraz godzin pracy czatu na żywo”.

Ponadto SLA dla czasu odpowiedzi na czacie wymaga aktywacji. Zendesk informuje, że SLA czasu odpowiedzi dla czatu na żywo „są domyślnie wyłączone”, więc ich brak wynika z konfiguracji systemu, a nie z idealnych wyników zespołu.

Jak zrobić to ręcznie

Opcja 1: Jedna karta dla każdej rodziny metryk

Wyeksportuj listę zgłoszeń wraz z polami metryk, a następnie rozdziel wolumen, czas odpowiedzi i czas rozwiązania na osobne karty, zanim zaczniesz cokolwiek podsumowywać.

Umieść kolumny z godzinami kalendarzowymi i roboczymi obok siebie, zamiast wybierać tylko jedną podczas eksportu. Z pewnością padnie pytanie o tę drugą.

Dla metryk czasowych obliczaj medianę, a nie średnią. Kilka zgłoszeń pozostawionych bez obsługi podczas świąt może zawyżyć średnią do poziomu, który nie ma nic wspólnego z rzeczywistością większości zgłoszeń.

Głównym ograniczeniem jest to, że arkusz kalkulacyjny nie widzi historii statusów. Otrzymujesz aktualny stan każdego zgłoszenia, więc dane o ponownych otwarciach muszą pochodzić z liczby ponownych otwarć, a nie z próby odtworzenia historii.

Opcja 2: Karta definicji przygotowana na samym początku

Zapisuj definicję czasu odpowiedzi, wybrany zegar, metrykę rozwiązania, regułę statusu dla zgłoszeń rozwiązanych, uwzględnione kanały oraz podstawę datowania.

Następnie odnotuj to, czego raport nie wykazuje. Jasne określenie, że realizacja SLA i natywny czas pierwszej odpowiedzi mierzą zupełnie inne rzeczy, zapobiegnie sytuacji, w której ktoś z zespołu przedstawi je jako jedną i tę samą wartość.

Ograniczenie jest tu typowe: samo spisanie reguły nie oznacza jej automatycznego stosowania, a w kolejnym kwartale ktoś może odtworzyć tabelę przestawną z pamięci.

Opcja 3: Segmentacja przed wyliczeniem średniej

Podziel dane według kanałów przed obliczeniem jakiejkolwiek metryki czasowej. Zgłoszenia mailowe, czatowe i telefoniczne rządzą się zupełnie innymi prawami, a ogólna mediana nie powie prawdy o żadnym z nich.

Następnie wyklucz lub oznacz zgłoszenia, które zaburzają obraz. Zgłoszenia oczekujące na odpowiedź klienta przez wiele tygodni powinny znaleźć się w osobnym wierszu, a nie wpływać na średni czas rozwiązania.

Pokaż, co zostało wykluczone i jak duża była to grupa. Czytelnik, który nie widzi nałożonego filtra, założy, że żadnego nie było.

Ograniczeniem jest fakt, że segmentacja drastycznie zwiększa ilość pracy. Trzy kanały pomnożone przez dwa zegary i dwie metryki czasu rozwiązania dają dwanaście różnych liczb, nad którymi trzeba zapanować.

Wspólne ograniczenie. Wszystkie trzy opcje zakładają, że eksport obejmuje jeden zakres dat i jedną podstawę datowania dla każdej kolejki. Różne zakresy dat w poszczególnych kartach to najczęstszy, niewidoczny na pierwszy rzut oka błąd w tego typu raportach.

Gdzie ręczna metoda zaczyna zawodzić

Przygotowanie pierwszego raportu zajmuje jedno popołudnie. Czwarty zajmie już więcej czasu, ponieważ w międzyczasie zmieniła się konfiguracja help desku.

Uruchomienie nowego kanału sprawia, że ogólna mediana zmienia się z przyczyn niezwiązanych z samą wydajnością. Godziny robocze zostają zmodyfikowane dla nowego regionu, a wraz z nimi przesuwają się wszystkie historyczne dane oparte na godzinach roboczych.

Do tego dochodzi efekt ponownego otwarcia zgłoszeń. Dane z zeszłego kwartału nagle przestają się zgadzać, a wyjaśnienie tego zjawiska zajmuje więcej czasu niż ponowne przygotowanie raportu.

Istnieje też czwarty koszt, który ujawnia się pod presją czasu. Gdy ktoś pyta, czy wsparcie działało w tym kwartale szybciej, rzetelna odpowiedź wymaga uprzedniego określenia zegara, definicji oraz struktury kanałów.

Aby poznać drugą stronę medalu, czyli satysfakcję klientów, zobacz nasz przewodnik po tworzeniu raportu NPS. Jeśli problemem jest sam wolumen zgłoszeń, nasz poradnik dotyczący budowy agenta AI do obsługi klienta przed sprzedażą omawia kwestię odciążenia zespołu.

Jak zbudować raport za pomocą Powerdrill Bloom

Krok 1: Prześlij wyeksportowane dane zgłoszeń

Prześlij plik eksportu zgłoszeń lub połączone eksporty zgłoszeń i SLA. Powerdrill Bloom analizuje kolumny zaraz po przesłaniu, dzięki czemu puste znaczniki czasu, różne formaty dat czy zgłoszenia bez pierwszej odpowiedzi zostaną wykryte jeszcze przed obliczeniem jakiejkolwiek mediany.

Krok 2: Opisz raport językiem naturalnym

Zamiast od nowa tworzyć reguły, po prostu wskaż definicje. Określ definicję czasu odpowiedzi, zegar, pożądaną metrykę czasu rozwiązania, regułę statusu dla zgłoszeń rozwiązanych oraz uwzględnione kanały.

Następnie zadaj pytania, które pozwolą wyłapać błędy. Zapytaj, ile zgłoszeń w ogóle nie doczekało się odpowiedzi agenta. Dowiedz się, które zgłoszenia zostały otwarte ponownie. Poproś o medianę dla każdego kanału osobno, a nie o jedną ogólną wartość.

Krok 3: Wyeksportuj wykres, raport lub prezentację

Wygeneruj tabelę metryk dla poszczególnych kanałów lub wykres porównujący zgłoszenia utworzone z rozwiązanymi, z uwzględnieniem backlogu. W tym samym kroku możesz przygotować slajdy zawierające definicje tuż obok prezentowanych liczb.

Najczęstsze błędy

Podawanie poziomu realizacji SLA jako czasu pierwszej odpowiedzi. Pierwszy wskaźnik akceptuje automatyczną odpowiedź, podczas gdy drugi całkowicie wyklucza działania automatyczne.

Porównywanie godzin kalendarzowych z roboczymi. Domyślny raport przedstawia te pierwsze, podczas gdy Twój cel prawdopodobnie opiera się na tych drugich.

Używanie średniej dla czasu odpowiedzi i rozwiązania. Kilka porzuconych zgłoszeń może przesunąć średnią do poziomu, który nie odzwierciedla rzeczywistej obsługi żadnego realnego zgłoszenia.

Łączenie kanałów. Mediany dla czatu i e-maila różnią się z założenia, a ich połączenie zaciera obraz obu tych kanałów.

Raportowanie czasu rozwiązania bez wskazania jego rodzaju. Czas pierwszego i pełnego rozwiązania to dwie osobne, niezależnie zapisywane metryki, a nie tylko kwestia zaokrąglenia.

Traktowanie liczby rozwiązanych zgłoszeń jako ostatecznej. Liczba ta obejmuje wyłącznie zgłoszenia, które są aktualnie rozwiązane lub zamknięte, więc ponowne otwarcia zmieniają dane historyczne.

Pomijanie zgłoszeń bez odpowiedzi. Są one definiowane jako zgłoszenia z mniej niż jedną odpowiedzią agenta i stanowią najbardziej ewidentny dowód na błędy w procesie, jaki może wykazać raport.

Podsumowanie

Określ definicję odpowiedzi, wskaż zegar, wybierz pierwsze lub pełne rozwiązanie, podaj regułę statusu, podziel dane na kanały i uwzględnij zgłoszenia ponownie otwarte oraz te bez odpowiedzi. W ten sposób stworzysz raport ze zgłoszeń wsparcia, na podstawie którego można podjąć realne działania.

Raport ten może jednak nie nadawać się do bezpośredniego porównania z wynikami innej firmy. Definicje są w pełni konfigurowalne, więc benchmark, o którym gdzieś czytałeś, niemal na pewno został obliczony na podstawie innych reguł.

Zamiast tego śledź zmiany w odniesieniu do własnych danych historycznych, stosując stały zestaw reguł. Tylko taka wersja raportu odpowie na pytanie, czy nastąpiła realna poprawa.

Jeśli ponowne przygotowywanie raportu co miesiąc zabiera Ci cały dzień, wypróbuj Powerdrill Bloom do analizy eksportu zgłoszeń. Zobacz również stronę generatora raportów AI oraz voice of customer summarizer.

Najczęściej zadawane pytania

Dlaczego mój poziom realizacji SLA nie pokrywa się z czasem pierwszej odpowiedzi?

Metryki te mierzą różne zdarzenia. Czas pierwszej odpowiedzi SLA w Zendesk może zostać zaliczony dzięki automatycznej odpowiedzi, podczas gdy natywna metryka czasu pierwszej odpowiedzi całkowicie wyklucza działania automatyczne i boty.

Czy powinienem raportować czas pierwszego rozwiązania, czy czas pełnego rozwiązania?

Raportuj ten wskaźnik, który jasno zdefiniujesz. Czas pierwszego rozwiązania kończy się w momencie pierwszego oznaczenia zgłoszenia jako rozwiązane. Czas pełnego rozwiązania kończy się przy ostatnim takim oznaczeniu, więc różnicę między nimi wyznaczają zgłoszenia otwarte ponownie.

Czy metryki wsparcia są mierzone w godzinach kalendarzowych, czy roboczych?

Zapisywane są obie te wartości. Gotowe raporty Explore w Zendesk wyświetlają godziny kalendarzowe, natomiast metryki oparte na godzinach roboczych są dostępne dla raportów, które tworzysz samodzielnie.

Dlaczego zmieniła się liczba rozwiązanych zgłoszeń z zeszłego kwartału?

Liczba rozwiązanych zgłoszeń obejmuje te, które są aktualnie rozwiązane lub zamknięte. Zgłoszenie otwarte ponownie po zakończeniu danego okresu znika z jego statystyk.

Czy mogę porównać mój czas rozwiązania z benchmarkiem branżowym?

Tylko w przybliżeniu. Definicje, wybrany zegar oraz struktura kanałów są w pełni konfigurowalne, więc opublikowane dane branżowe były najprawdopodobniej mierzone według innych reguł niż Twoje.