Wiadomość, zgłoszenie i zadanie: trzy elementy jednej obsługi

Wiadomość: pojedynczy element kontaktu

E-mail z opisem usterki jest wiadomością. Kolejny e-mail ze zdjęciem także jest wiadomością, nawet jeśli dotyczy tej samej potrzeby. Z samej liczby wiadomości nie wynika liczba zgłoszeń ani zadań. Jedna wiadomość może zawierać kilka próśb, a jedna prośba może wymagać wielokrotnego doprecyzowania.

W proponowanym przez nas słowniku wiadomość odpowiada przede wszystkim na pytania: kto napisał, kiedy i co przekazał. Nie musi określać osoby odpowiedzialnej za wykonanie pracy ani kryterium jej zakończenia. Przy czytaniu kontaktu warto oddzielić opis klienta od ustalenia zespołu: klient może poprosić o naprawę, ale zakres usługi może nadal wymagać uzgodnienia. To ważne także wtedy, gdy wszystko mieści się w jednym wątku pocztowym.

Uzupełnij ten temat: Zrozumiała odpowiedź e-mail do klienta: konkret, instrukcja i następny krok.

Zgłoszenie: potrzeba i odpowiedzialność za obsługę

Zgłoszenie proponujemy rozumieć jako jednostkę obsługi: ma temat, opiekuna, stan i następny krok. Może obejmować pierwszą wiadomość, pytania uzupełniające oraz odpowiedź końcową. Taki słownik pomaga powiedzieć, co nadal wymaga uwagi, niezależnie od liczby e-maili.

Dokumentacja Zendesk pokazuje konkretną realizację tego podejścia: przy zgłoszeniu występują komentarze publiczne i notatki wewnętrzne, a odpowiedź klienta na powiadomienie może dołączyć do zgłoszenia. To funkcje opisane dla danego produktu, nie powszechna definicja wszystkich systemów. Organizacyjnie warto ustalić, które informacje są przeznaczone dla klienta, a które służą zespołowi. Wewnętrzna hipoteza diagnozy nie jest jeszcze uzgodnionym wynikiem usługi.

Źródło: Zendesk Help — Adding comments to tickets

Zadanie: działanie z określonym rezultatem

Asana w dokumentacji tworzenia zadań opisuje tytuł, osobę wykonującą, opis i termin. Większą pracę można rozbić na podzadania. Ten model dobrze ilustruje odrębną rolę zadania: wskazanie, co ktoś ma zrobić i jaki rezultat ma przekazać.

Nasza propozycja to nazywanie zadań działaniem, na przykład sprawdzenie zasilacza lub przygotowanie wyceny. Opiekun zgłoszenia może być inną osobą niż wykonawca zadania. Pierwszy pilnuje kontaktu i ustaleń z klientem, drugi odpowiada za powierzony rezultat. To podział ról, który możecie zastosować w wybranym narzędziu. Zakończenie diagnozy nie musi kończyć obsługi, jeśli trzeba jeszcze uzyskać zgodę klienta albo przekazać mu informację.

Źródło: Asana Help Center — Create tasks in Asana

Uzupełnij ten temat: Organizacja pracy serwisowej: jak zapisać plan i wrócić do pracy po przerwie.

Własny przykład: od e-maila do rozliczenia

Klient pisze, że urządzenie przerywa pracę. To pierwsza wiadomość. Opiekun przyjmuje zgłoszenie i prosi o model oraz opis warunków, w których występuje problem. Klient dosyła dane. Nadal obsługujemy tę samą potrzebę, choć mamy już kilka wiadomości.

Następnie opiekun uzgadnia zakres diagnozy, a technik otrzymuje zadanie sprawdzenia urządzenia. Technik zapisuje wynik i czas pracy. Po diagnozie klient akceptuje dalszą usługę; powstaje kolejne zadanie wykonawcze. Opiekun przekazuje wynik klientowi. Ewidencja czasu może być materiałem do rozliczenia według wcześniej ustalonych zasad, ale nie zastępuje uzgodnienia zakresu ani dokumentu księgowego. Ten scenariusz jest ilustracją organizacyjną, nie opisem rezultatów konkretnego wdrożenia.

Co zamykamy i czego jeszcze nie zamykamy

Proponujemy osobno ustalić warunek zakończenia zadania, zgłoszenia i rozliczenia. Zadanie może być gotowe po przekazaniu wyniku technicznego. Zgłoszenie może pozostać otwarte do wyjaśnienia pytania klienta. Rozliczenie może nadal oczekiwać na zatwierdzenie ewidencji lub wystawienie dokumentu w używanym programie księgowym.

Przy zmianie opiekuna potrzebna jest krótka informacja o zależnościach: które zadanie blokuje odpowiedź i kto potwierdza wykonanie. Nie trzeba zakładać osobnego zgłoszenia dla każdej czynności. Ważniejsze, aby zespół umiał odróżnić zakończoną pracę wewnętrzną od zakończonej obsługi klienta. Reguły te są propozycją do dopasowania do waszych usług.

• Wiadomość: jaka informacja dotarła i od kogo?
• Zgłoszenie: jaka potrzeba wymaga obsługi i kto jej pilnuje?
• Zadanie: jaki rezultat ma powstać i kto go wykona?
• Rozliczenie: co zostało zaakceptowane i gdzie powstaje dokument?

Uzupełnij ten temat: Rozliczanie pracy serwisowej: od maila i zadania do zestawienia czasu.

Jak wykorzystać rozróżnienie w codziennej pracy

Na odprawie warto pytać o potrzeby oczekujące na obsługę oraz zadania oczekujące na wykonanie. Liczenie samych wiadomości nie pokazuje, czy klient otrzymał rozwiązanie. Liczenie samych zakończonych zadań nie pokazuje, czy opiekun przekazał wynik. Nie proponujemy tu określonego wskaźnika skuteczności; najpierw potrzebne są wspólne definicje.

W ABCare kontakt z obsługiwanych kanałów e-mail i Allegro jest organizowany w zgłoszeniach. Opcjonalne Zadania i Obsługa wspierają dalszą pracę oraz ewidencję czasu, zależnie od modułów i uprawnień. W rozliczeniu można zapisać numer faktury wystawionej poza ABCare; aplikacja nie wystawia tej faktury. Ten przykład pokazuje, dlaczego wiadomość, wykonanie i dokument finansowy warto rozumieć jako powiązane, lecz odrębne elementy.

Źródła

• Zendesk Help — Adding comments to tickets
• Asana Help Center — Create tasks in Asana

Źródła i praktyczne wskazówki pełnią różne role: badania opisują własny zakres, a materiały platform — ich zasady. Wskazówki pracy w ABCare są propozycją organizacji obsługi. Jak sprawdzamy poradniki.