Cykl życia zgłoszenia i komunikacja z Klientami w Helpdesku
Wprowadzenie
W tym artykule omówimy proces tworzenia zgłoszenia w zależności od sposobu utworzenia zgłoszenia w Help Desk i dostępu klienta do Twojego systemu. Znajdziesz tu wskazówki, na co zwrócić uwagę w różnych konfiguracjach procesu zgłoszeń.
W tym artykule znajdują się wskazówki i sugestie dotyczące różnych konfiguracji, ale nie podano bezpośrednio sposobu ich tworzenia. Oto odpowiednie artykuły:
- Dokumentacja Help Desku
- Instrukcja obsługi (przepływ pracy, ustawienia powiadomień)
Trzy główne szlaki komunikacyjne
Zaczynając od schematu cyklu życia biletu w prostych sytuacjach – gdy bilet podlega tylko jednemu rodzajowi przepływu od początku do końca.
- Pełny użytkownik w aplikacji
- Użytkownik pomocy technicznej w aplikacji
Tworzenie i dalsza komunikacja w ramach zgłoszenia
Tworzenie zgłoszeń i dalsza komunikacja mogą łączyć powyższe podejścia.
Możliwe jest utworzenie zgłoszenia za pośrednictwem poczty elektronicznej, a następnie śledzenie go w aplikacji (czy to przez użytkownika pełnego, czy przez użytkownika pomocy technicznej). Możliwe jest także utworzenie zgłoszenia za pośrednictwem systemu, a następnie śledzenie wyłącznie wiadomości e-mail.
1 przykład
- Zgłoszenia tworzone są poprzez e-mail – klient wysyła nowy e-mail na adres helpdesku.
- Klient loguje się do systemu i tam może zobaczyć bilet, gdyż jest jego autorem.
- Klienci mogą zmieniać statusy i inne pola oraz dodawać komentarze, zgodnie ze swoimi uprawnieniami.
2 przykład
- Klient loguje się do systemu i tworzy nowe zgłoszenie.
- Klient otrzymuje aktualizacje drogą mailową i jedynie je obserwuje i nie czuje już potrzeby logowania się do systemu.
3 przykład
- Klient tworzy zgłoszenie za pośrednictwem portalu pomocy technicznej
- Klient decyduje, że chce śledzić wyłącznie e-maile i nie loguje się już do portalu
- Następnie klient decyduje, że chce śledzić przez portal, loguje się i wprowadza kilka odpowiedzi za pośrednictwem portalu.
W trosce o wygodę Twoich Klientów możesz zdecydować w jaki sposób chcesz umożliwić im tworzenie i/lub aktualizację zgłoszeń. Ale co najważniejsze, trzeba objąć każdą możliwą sytuację, aby bilety nie zaginęły w ślepy zaułek. Przepływ pracy i inne konfiguracje zapewniają wszystkie niezbędne opcje.
Powszechne problemy
Klient odpowiada na zwykłe powiadomienie o zadaniu, ale odpowiedź nie jest poprawnie przetwarzana.
Ta historia dotyczy Przykładu 2. Klienci myślą, że odpowiadają na zgłoszenie e-mailem, ale wiadomość e-mail nie jest powiązana z istniejącym zgłoszeniem i zamiast tego tworzony jest nowy lub wiadomość w ogóle nie dociera do systemu. Klient odpowiada na powiadomienie lub przez pomyłkę tworzy nowy e-mail.
Przyczyna: Ustawienia powiadomień e-mail nie oczekują odpowiedzi na adres powiadomień.
Rozwiązanie: Odpowiedź klienta musi zostać wysłana na podany adres centrum pomocy i musi zawierać numer zgłoszenia. Adres e-mail powiadomień (Administracja >> Ustawienia >> Powiadomienia e-mail >> Adres e-mail powiadomień (FROM)) może być taki sam jak adres e-mail centrum pomocy, aby przechwycić wszelkie odpowiedzi od klientów i powiązać je ze zgłoszeniem, z którego pierwotnie wysłano powiadomienie.
Inną opcją jest po prostu wyłączenie regularnych powiadomień e-mail dla użytkowników klienta. Jedyne e-maile dotyczące zgłoszeń, które otrzymają, będą aktywnie wysyłane przez operatorów za pośrednictwem szablonów e-maili pomocy technicznej.
Kluczowy wniosek: Twoi klienci będą naturalnie kuszeni, aby odpowiedzieć na każdą otrzymaną wiadomość e-mail. Upewnij się, że otrzymują tylko wiadomości, na które odpowiedzi mogą zostać poprawnie przetworzone.
Klient zmienił zgłoszenie na „nieprawidłowe”.
Dzieje się tak najczęściej w sytuacjach, gdy klient posiada w aplikacji pełnego użytkownika (a nie użytkownika Help Desk). Klient może mieć możliwość edycji wielu pól, w tym statusu oraz może błędnie zinterpretować znaczenie poszczególnych statusów. Lub z drugiej strony może nie zmienić statusu, kiedy spodziewasz się, że zostanie on zmieniony.
Przyczyna: Klient jest odpowiedzialny za ustawienie prawidłowego statusu.
Rozwiązanie: Jest to przejrzysty antywzorzec, klient nie powinien pamiętać żadnych reguł dotyczących statusów zadań.
Jednym z rozwiązań jest przeniesienie konta klienta na użytkowników Help Desk, zamiast na pełnoprawnych użytkowników. Użytkownicy Help Desku mogą tworzyć zgłoszenia i wprowadzać komentarze do istniejących zgłoszeń, zmiany statusów bazują na konfiguracjach Help Desku, więc nie ma ryzyka, że klient "przerwie" jakiś poprawny proces. Aktualizacje zgłoszeń użytkowników działu pomocy technicznej są praktycznie zaprojektowane tak, aby były zgodne z logiką i ustawieniami komunikacji e-mailowej działu pomocy technicznej. Jedyna różnica polega na tym, że użytkownik może faktycznie zobaczyć fizyczną formę biletu i pracować z nią.
Jeśli chcesz zachować pełnych użytkowników dla swoich klientów, sugerujemy całkowite wyłączenie wszelkich zmian statusu (lub zmian innych pól), które mogą zakłócić niektóre Twoje wewnętrzne procesy. Skorzystaj z innych sposobów śledzenia zgłoszeń wymagających aktualizacji - na przykład według pola Zadanie ostatnio zaktualizowane (data ostatniej aktualizacji), Ostatnia aktualizacja przez (kto dokonał ostatniej aktualizacji), możesz pokazać na liście ostatni komentarz do zgłoszenia, aby było jasne, że aktualizacji dokonał klient.
Nieco bardziej skomplikowany scenariusz pochodzi z Przykładu 1, kiedy pozwalasz na komunikację zgłoszeń za pośrednictwem poczty elektronicznej, ale jednocześnie pozwalasz klientom na logowanie się jako pełny użytkownik. Oto, na co należy zwrócić uwagę:
- Zmiana statusu po odpowiedziach klientów e-mailem jest ustawiana w globalnych ustawieniach pomocy technicznej
- Nie ma wymuszania zmiany statusu dla zalogowanych użytkowników - zawsze istnieje opcja zachowania statusu bez zmian
W takim przypadku upewnij się, że w Twoich kolejkach do odpowiedzi znajdują się zarówno sytuacje aktualizowane e-mailem (np. filtrowanie dla konkretnego statusu), jak i zgłoszenia aktualizowane przez klientów z poziomu aplikacji (np. lista zgłoszeń z kolumną Ostatni komentarz).
Kluczowy wniosek: Klient nigdy nie powinien martwić się o Twoje wewnętrzne procesy, potrzebuje po prostu miejsca, w którym może zgłaszać swoje problemy i komunikować się z Tobą, procesy są w Twojej gestii, a aplikacja ma różne opcje, aby je ściśle ustawić.
Mieszanie pełnych użytkowników i użytkowników pomocy technicznej
To tylko mocne ostrzeżenie, aby nie łączyć rozwiązań, które nigdy nie miały być łączone. Możesz zdecydować, czy użyć
- Użytkownicy działu pomocy technicznej — bezpłatnie, z zakodowanym na stałe ograniczonym dostępem lub
- Pełni użytkownicy - zwykli licencjonowani użytkownicy, w których decydujesz, do czego mają dostęp
, ale nie powinieneś używać obu jednocześnie, szczególnie w przypadku tych samych klientów. Technicznie rzecz biorąc, użytkownicy pełnoprawni i użytkownicy działu pomocy technicznej nie są w żaden sposób połączeni. Mają nawet inną stronę logowania. Reprezentują inną dziedzinę zadań (autor vs autor pomocy technicznej). Nie ma więc powodu dezorientować klienta, udostępniając mu obie opcje dostępu.
Jeśli chodzi o procesy wewnętrzne, technicznie możliwe jest zapewnienie niektórym klientom pełnych użytkowników, a innym jedynie użytkowników pomocy technicznej. Wymaga to jednak precyzyjnych opisów procesów i szkoleń dla agentów, aby mieć pewność, że nie pomylą przetwarzania zgłoszeń z tych bardzo różnych kanałów. Ze względu na trudności organizacyjne zdecydowanie zalecamy wybranie tylko jednej opcji dostępu klienta.
Podsumowanie
Przywróćmy dotychczasowe informacje do zrozumiałej formy. Poniżej znajduje się tabela sytuacji, które mogą wystąpić w zależności od rodzaju dostępu klientów do systemu.
| Dostęp klienta do aplikacji | Opcje przesłania zgłoszenia (klient) |
Powiadomienia z biletu (agenta) |
Opcje aktualizacji zgłoszenia (klient) |
Nasze rekomendacje |
| Bez dostępu | Wyślij wiadomość e-mail na adres e-mail centrum pomocy. | Agent wysyła wiadomość e-mail za pomocą szablonu ze zgłoszenia. |
|
|
| Pełny użytkownik |
|
|
|
|
| Użytkownik działu pomocy technicznej |
|
Agent wysyła wiadomość e-mail za pomocą szablonu ze zgłoszenia. |
|
|
