Odpowiedzieliśmy w godzinę. Sprawa nadal trwa: co obiecuje czas obsługi

„Odpowiadamy w godzinę” może znaczyć, że klient dostanie numer sprawy, pytanie od konsultanta albo gotową pomoc. Każda z tych rzeczy może wydarzyć się po sześćdziesięciu minutach. Samo słowo „odpowiedź” na stronie nie wyjaśnia, którą z nich firma obiecuje.

Wyobraźmy sobie usługę opieki nad sklepem internetowym. Klient zgłasza, że nie może pobrać zestawienia zamówień. Firma rejestruje wiadomość, prosi o wskazanie konkretnego zestawienia, sprawdza problem i wraca z wynikiem. Ten fikcyjny przebieg posłuży do ustalenia znaczenia czasu obsługi: od jakiego zdarzenia liczymy, przy jakim zatrzymujemy pomiar oraz co dzieje się między nimi.

Nazwa etapu powinna wskazywać zdarzenie

Potwierdzenie odbioru mówi, że wiadomość dotarła do używanego przez firmę kanału. Nie musi oznaczać, że pracownik już ją przeczytał. Automatyczna informacja z numerem może być potrzebna, ale klient powinien umieć odróżnić ją od odpowiedzi odnoszącej się do problemu. Szczególnie gdy oba komunikaty pojawiają się pod tym samym nagłówkiem „otrzymaliśmy odpowiedź”.

Podjęcie obsługi może oznaczać pierwszą ocenę zgłoszenia albo rozpoczęcie konkretnego sprawdzenia. Jeśli firma chce taką czynność obiecywać, powinna umieć ją rozpoznać w swoim obiegu. Samo przypisanie nazwiska do karty nie zawsze oznacza, że osoba zaczęła pracę. Z kolei rozmowa telefoniczna może rozpocząć sprawdzanie, choć w historii wiadomości jeszcze nie ma odpowiedzi.

Zendesk w dokumentacji czasu pierwszej odpowiedzi opisuje pomiar od utworzenia zgłoszenia do pierwszej publicznej odpowiedzi pracownika. Rozróżnia też czas kalendarzowy i godziny pracy. Wskazuje osobne reguły kanałów oraz wyjątków, więc nawet nazwa pola w narzędziu wymaga odczytania definicji używanej w danej konfiguracji.

Rozwiązanie sprawy potrzebuje jeszcze innego warunku. W naszym przykładzie może nim być przekazanie sposobu pobrania zestawienia, przywrócenie działania funkcji albo potwierdzenie wyniku przez klienta. Firma musi wybrać moment odpowiedni dla swojej usługi. Wysyłka wiadomości „powinno już działać” nie jest automatycznie tym samym co sprawdzony rezultat.

Nie próbuj rozstrzygnąć wszystkich etapów jednym zdaniem „czas reakcji do godziny”. Można osobno zapowiedzieć pierwszą odpowiedź oraz sposób ustalania dalszego planu. SLA, od angielskiego service level agreement, oznacza uzgodniony standard obsługi, obejmujący określone zdarzenia i czasy. Sam skrót nie doprecyzuje niejasnej obietnicy.

Jedna sprawa, dwa zegary

Przyjmijmy wyłącznie dla przykładu obsługę od poniedziałku do piątku, od 9:00 do 17:00. Liczymy w tej samej strefie czasu, bez świąt i zmiany czasu w rozpatrywanym weekendzie. Zgłoszenie przychodzi w piątek o 16:30. Potwierdzenie automatyczne wychodzi minutę później. Konsultant odpisuje w poniedziałek o 9:15.

Od utworzenia sprawy do odpowiedzi człowieka minęło czterdzieści pięć minut w przyjętych godzinach obsługi: pół godziny w piątek i kwadrans w poniedziałek. W czasie kalendarzowym to sześćdziesiąt cztery godziny i czterdzieści pięć minut. Obie liczby opisują ten sam przebieg. Różnią się zakresem okresu, który wliczono do pomiaru.

Jeżeli obietnica dotyczy godziny obsługi, w tym fikcyjnym układzie termin odpowiedzi wypada w poniedziałek o 9:30. Jeśli strona obiecuje godzinę bez takiego wyjaśnienia, klient może oczekiwać kontaktu jeszcze w piątek. Nie wystarczy, że właściwy kalendarz jest ustawiony w narzędziu. Odbiorca potrzebuje zrozumieć znaczenie obietnicy przed skorzystaniem z niej.

Ustal, jakiego zespołu dotyczą godziny pracy. Firma może przyjmować wiadomości przez całą dobę, a odpowiadać w ograniczonym przedziale. Może też mieć osobny zakres pilnej pomocy. Dostępny formularz nie oznacza stałego dyżuru specjalisty. Przy współpracy między krajami trzeba również wskazać strefę, zamiast zakładać, że dla obu stron „poniedziałek rano” zaczyna się jednocześnie.

GitLab na stronie własnych poziomów wsparcia zaznacza, że podane czasy SLA dotyczą pierwszej odpowiedzi i nie należy traktować ich jako oczekiwanego czasu rozwiązania. To konkretne rozdzielenie obietnic dostawcy.

Pauza musi mieć powód i moment końca

W poniedziałek o 9:15 nasz konsultant prosi klienta o wskazanie zestawienia, którego dotyczy problem. O 10:00 otrzymuje potrzebną informację. Załóżmy, że firma ustaliła wstrzymywanie wybranego pomiaru na czas oczekiwania na takie dane. Pauza trwa wtedy czterdzieści pięć minut, lecz cała sprawa nadal pozostaje otwarta.

Atlassian w instrukcji warunków SLA opisuje ustawianie początku, opcjonalnej pauzy i końca pomiaru. Jako przykład pauzy wskazuje oczekiwanie na odpowiedź klienta. Firma wybiera, które oczekiwanie uzasadnia pauzę w danym pomiarze.

Firma powinna określić, co uzasadnia taki stan. Czy pytanie dotyczy informacji rzeczywiście potrzebnej do następnego działania? Czy tę informację można już znaleźć w otrzymanym materiale? W naszym przykładzie nie ma sensu zatrzymywać pomiaru z powodu brakującego oznaczenia, jeżeli klient podał je w pierwszej wiadomości, a obsługa go nie zauważyła.

Powrót również wymaga rozpoznawalnego zdarzenia. Odpowiedź o 10:00 może zawierać potrzebne dane, prośbę o wyjaśnienie albo sam podpis. Jeżeli każda nowa wiadomość uruchamia pomiar ponownie, sprawdź zgodność tego działania z przyjętą zasadą. Jeżeli decyduje pracownik po ocenie treści, trzeba uwzględnić sposób i moment tej oceny.

Praca oczekująca na klienta nadal wymaga właściciela oraz warunku dalszego działania. Wyłączenie czasu z jednej miary nie powinno usuwać sprawy z pola widzenia. Klient może również czekać na wyjaśnienie pytania, które firma uważa za wysłaną prośbę o dane. Wtedy etykieta „po stronie klienta” nie opisuje jeszcze całej sytuacji.

Co zamyka pomiar, gdy pomoc już wróciła

Załóżmy, że o 11:00 konsultant przekazuje sprawdzony sposób pobrania zestawienia. Od piątku o 16:30 upłynęło sześćdziesiąt sześć godzin i trzydzieści minut czasu kalendarzowego. W przyjętych godzinach obsługi to dwie i pół godziny. Po wyłączeniu opisanej pauzy pozostaje godzina i czterdzieści pięć minut. To trzy różne pomiary, nie trzy możliwe oceny wysiłku konsultanta.

Żaden z nich nie mówi wprost, ile trwała aktywna praca. Między otrzymaniem danych a wynikiem mogło być oczekiwanie na inną osobę. Jeśli firma potrzebuje poznać nakład, musi go rozpoznać osobno. Czas przebywania sprawy w obsłudze i czas wykonywania czynności nie stają się tą samą wielkością po odjęciu jednej pauzy.

Klient potwierdza o 12:00, że otrzymał potrzebny wynik. Firma powinna wiedzieć, czy standard kończy się o 11:00, czy o 12:00, i zachować oba fakty, jeśli są potrzebne do dalszej oceny. Warunek nie powinien zależeć od tego, która godzina lepiej wygląda w konkretnym raporcie. Musi wynikać z wcześniej ustalonego znaczenia zakończenia.

Zestawienie metryk Zendesk osobno definiuje czas do pierwszego rozwiązania oraz czas od utworzenia zgłoszenia do jego ostatniego rozwiązania. Jeżeli sprawa po ponownym otwarciu zostanie rozwiązana później, ta druga miara obejmie czas do późniejszego rozwiązania. To powód, by przed porównaniem raportów sprawdzić, którego zakończenia dotyczy wybrana liczba.

Jeśli klient wraca z tym samym problemem, zdecyduj, jak zachowujesz związek z wcześniejszą sprawą. Inaczej pierwsze rozwiązanie może być widoczne jako sukces, a dalsza obsługa jako zupełnie nowa potrzeba. Nie trzeba automatycznie łączyć każdego powrotu. Nowe pytanie dotyczące innego zestawienia może wymagać osobnego zgłoszenia. Ważna jest rozpoznawalna podstawa tego wyboru.

Przekazanie do drugiej osoby nie tworzy nowego początku

Załóżmy, że o 10:15 konsultant przekazuje problem specjaliście. Dla drugiego pracownika zaczyna się własny etap, ale potrzeba klienta powstała wcześniej. Firma może mierzyć czas obu zespołów osobno. Powinna jednak zachować również historię całej sprawy. Zastąpienie jej czasem ostatniego przydziału odpowie na inne pytanie niż to zadane przez klienta: jak długo czekam od zgłoszenia?

Podobnie działa zmiana rodzaju sprawy. Na początku zespół uznał ją za pytanie o obsługę, potem rozpoznał problem wymagający sprawdzenia działania funkcji. Trzeba ustalić, czy zmienia się standard oraz jak potraktować czas już upływający. Nie rozwiąże tego samo przesunięcie karty do innej kategorii. Osoba podejmująca decyzję powinna znać wpływ zmiany na obietnicę i na interpretację raportu.

Przy dwóch kanałach wybierz także zdarzenie, od którego liczysz jedną potrzebę. Klient najpierw napisał wiadomość, a później zadzwonił z tym samym problemem. Jeśli system przechowuje oba kontakty osobno, ich połączenie powinno zachować pierwotny początek przyjęty dla całej sprawy. Inaczej po połączeniu kontaktów zgłoszenie może wyglądać na nowsze, chociaż klient czeka od tej samej chwili. Lokalny czas rozmowy może nadal pozostać osobnym użytecznym pomiarem.

Zdarzenie w narzędziu i obietnica dla klienta muszą się spotkać

Do ustalonego standardu przypisz informację, którą firma rzeczywiście posiada. Jeśli narzędzie przechowuje czas pierwszej publicznej wiadomości, nie nazwiesz tej liczby wiarygodnym czasem rozpoczęcia analizy bez dodatkowego sprawdzenia. Być może analiza zaczęła się wcześniej. Być może wiadomość zawierała dopiero prośbę o skierowanie sprawy do innego działu.

To szczególnie istotne przy odpowiedzi przygotowanej przez AI. Wiadomość może zawierać użyteczną pomoc albo tylko potwierdzenie przyjęcia. Ustal, co firma uważa za etap spełniony przez taki komunikat i jak sprawdza dalszy skutek. Nie należy z góry zakładać, że każda automatyczna wiadomość jest rozwiązaniem, ani że każda wiadomość człowieka nim jest.

W miarach prowadzących do niepożądanych zachowań problemem jest wpływ wskaźnika na sposób działania ludzi. Tutaj wcześniejszym zadaniem jest ustalenie, czy odczytujemy ten sam fakt, który obiecujemy. Nawet bez presji na wynik pomiar może mówić o innym etapie niż słowo „reakcja” użyte w ofercie.

Przy pierwszeństwie obsługi w kolejce nazwij, który czas preferencja ma skracać. Wcześniejsza ocena pilności i wcześniejsze rozpoczęcie właściwej pomocy to odrębne zdarzenia. Jeżeli zgłoszenie po ocenie przechodzi do innego zespołu, samo nadanie pierwszeństwa nie potwierdza jeszcze dostępności potrzebnej osoby.

Również rezerwacja usługi i zwolnienie miejsca pokazują różnicę między wiadomością a jej skutkiem. Prośba o nowy termin może wymagać uzgodnienia. Szybka odpowiedź potwierdzająca jej przyjęcie nie powinna brzmieć tak, jakby klient miał już potwierdzoną nową rezerwację.

Odbierz standard na historii jednej sprawy

Przed publikacją deklarowanego czasu poproś dwie osoby, aby niezależnie wskazały początek, pauzy i koniec w tej samej historii. Dodaj wiadomość automatyczną, odpowiedź po godzinach oraz powrót z tą samą potrzebą. Jeżeli otrzymasz różne wyniki, ustal przyczynę: inne rozumienie zasady, brak zdarzenia czy konfigurację narzędzia. Każdy problem wymaga innej poprawki.

Zrób też próbę od strony klienta. Przeczytaj samo zdanie z oferty i potwierdzenie po kontakcie, bez wewnętrznej instrukcji. Czy z tych materiałów wynika, kiedy można oczekiwać odpowiedzi oraz czego ona dotyczy? Jeśli zespół potrzebuje pięciu minut ustnych wyjaśnień do jednego zdania, warto poprawić zdanie przed uruchomieniem kolejnej reklamy.

Informacja o opóźnieniu przyda się wtedy, gdy standardu nie uda się dotrzymać. To osobna sytuacja od samego definiowania czasu. Firma powinna umieć odróżnić przekroczenie obiecanego etapu od dalszej pracy, której terminu jeszcze nie ustalono, i powiedzieć odbiorcy, co wydarzy się dalej.

W Aeneia Audit można zacząć od obecnego raportu, opisu konfiguracji i kilku odtwarzalnych historii. Rozpoznanie roli narzędzi oraz AI powinno pokazać, gdzie powstaje informacja o wyniku i gdzie wymaga ludzkiego potwierdzenia. Zanim firma skróci deklarowaną godzinę do pół godziny, warto ustalić, co dokładnie ma się w niej wydarzyć.