To nie był problem dla AI, to był problem procesu. Czyli o tym, jak stracić stałego klienta?

Od kilku lat pomagam różnym firmom w ustabilizowaniu, skalowaniu i ustrukturyzowaniu pracy działów obsługi klienta i nie tylko. Tym bardziej odczuwam fizyczny ból za każdym razem, gdy obsługa klienta w ogromnych firmach działa tragicznie. Żeby artykuł był ciekawszy, oprę swoje rozważania na przykładzie, w którym to ja byłem osobą zgłaszającą problem.

Od dawna rozważałem zakup drukarki 3D i w końcu moja niska odporność na promocję połączyła się z chęcią zakupu. Voilà, dostałem swoją wymarzoną drukarkę.

Cieszyłem się nią przez półtora miesiąca. Po tym czasie przy każdej próbie druku urządzenie zgłaszało problemy z temperaturą hotendu, czyli kluczowej części odpowiedzialnej za podawanie filamentu podczas druku.

Zgłosiłem sprawę do sklepu. Drukarkę odebrał kurier w umówionym terminie, a ja zacząłem czekać. Czekałem tydzień, dwa, trzy, cztery. Ze sklepu otrzymałem jedynie informację, że drukarka dotarła do serwisu, a następnie, że jest w trakcie diagnozy. Zgłoszenie tkwiło jednak w tym statusie przez trzy tygodnie. Jako zatroskany klient zadzwoniłem więc do biura obsługi klienta. Przemiła pani z BOK-u wysłała eskalację do serwisu, ale minął kolejny tydzień. Zadzwoniłem ponownie. Kolejna eskalacja do serwisu.

Przez następny dzień zastanawiałem się, co z tym fantem zrobić, aż doszedłem do wniosku, że nie będę już dłużej czekał. Napisałem pięknego maila z pomocą najlepszego pomocnika prawnego XXI wieku, czyli ChatGPT. Grzecznie poinformowałem w nim, że czas rozsądnej naprawy został już przekroczony, dlatego rezygnuję z zakupu, proszę o zwrot środków oraz potwierdzenie przyjęcia mojego maila.

Otrzymałem autoresponder, w którym potwierdzono otrzymanie wiadomości oraz poinformowano mnie, że firma daje sobie cztery dni na rozpatrzenie sprawy.

Niestety cztery dni robocze minęły, a odpowiedź nie nadeszła. Piątego dnia napisałem więc kolejnego maila z ponownym wezwaniem do odpowiedzi oraz informacją, że żądam rozwiązania umowy i zwrotu wszystkich środków.

Dzień później zadzwoniła do mnie pewna pani, nazwijmy ją Kasią. Pani Kasia nie usłyszała nic w mojej słuchawce, ponieważ automat przełączył mikrofon na słuchawki, które leżały trochę dalej, więc się rozłączyła.

Co chciała mi przekazać? Że wysyłają mi nowiutką drukarkę. 😀

Dlaczego? Ponieważ zgubiły im się wszystkie moje maile.

W poniedziałek spokojnie zadzwoniłem i ponownie poinformowałem o wysłanych wiadomościach. Pani Kasia była bardzo zmartwiona i nie wiedziała, co ma z tym zrobić. Na szczęście po 20 minutach oddzwoniła i powiedziała, że zamawia kuriera, który po dostarczeniu mi nowej drukarki od razu ją ode mnie odbierze. 😀Wniosłem również o zadośćuczynienie w postaci bonu. Pani złożyła odpowiedni wniosek. Spoiler: o bon również musiałem się upominać, ponieważ w przeciwnym razie niczego bym nie dostał.

Ostatecznie wszystko zakończyło się dobrze, ale od momentu zgłoszenia problemu do chwili, w której otrzymałem bon, minęły dwa miesiące.

No dobrze. Wiemy już, że cały proces nie działał najlepiej.

Pytanie brzmi: co właściwie można było naprawić za pomocą Salesforce?

I od razu zaznaczę jedną rzecz. Nie każdy problem obsługi to problem dla AI. Naszą rolą jest dobrać właściwe narzędzie.  Czasem to porządny proces i kilka automatyzacji z RPA, czasem agent AI. O tym kiedy opłaca się stosować daną technologię szczegółowo pisał Robert tutaj.

Potrzebny jest dobrze poukładany proces, jasna odpowiedzialność i system, który pilnuje rzeczy, o których człowiek prędzej czy później zapomni.

Problem

Moja drukarka przez kilka tygodni znajdowała się w statusie „diagnoza w serwisie”.

Nikt nie zauważył, że sprawa utknęła. Nikt nie wysłał automatycznego przypomnienia. Nikt nie podniósł alarmu.

Dopiero mój telefon sprawił, że ktoś zaczął sprawdzać, co właściwie dzieje się z urządzeniem.

Jak powinno to wyglądać?

W Salesforce Service Cloud można wykorzystać Entitlement Process, Milestones, Flow oraz Escalation Rules.

Ustalamy, że diagnoza w serwisie może trwać na przykład maksymalnie określoną liczbę dni.

Jeżeli zgłoszenie zbyt długo pozostaje w tym samym statusie, system automatycznie:

wysyła przypomnienie do serwisu, tworzy zadanie dla konsultanta, podnosi priorytet sprawy i przekazuje ją do team leadera albo odpowiedniej kolejki.

Można również wykorzystać Omni-Channel, żeby taka eskalacja od razu trafiła do osoby, która ma odpowiednie kompetencje i aktualnie może się nią zająć.

I znowu: To nie jest zadanie dla AI. To po prostu dług procesowy, a dług się spłaca porządkiem, nie kolejnym agentem.

To jest zwykłe pilnowanie terminów przez system.

Benefit

• Firma reaguje, zanim klient zacznie dzwonić. Zwłaszcza, jeśli 30% połączeń do BOK to pytania ’ A jaki jest status mojej sprawy?’, automatyczne aktualizacje zdejmują ten ruch z konsultantów w Call Center.
• Konsultanci nie muszą codziennie ręcznie przeglądać setek zgłoszeń i zastanawiać się, które z nich stoją zbyt długo.
• Mniej telefonów, mniej eskalacji i mniej klientów, którzy zaczynają podejrzewać, że ich sprzęt po prostu zaginął.

Problem

Wysłałem dwa maile, w których jasno poinformowałem, że nie chcę już naprawy ani wymiany. Chcę rozwiązania umowy i zwrotu pieniędzy.

Obie wiadomości zostały pominięte.

Firma działała więc dalej na podstawie nieaktualnych informacji i zamówiła dla mnie nową drukarkę.

Jak powinno to wyglądać?

Wiadomości wysyłane przez klienta powinny trafiać do Salesforce przez Email-to-Case i być zapisywane bezpośrednio w historii zgłoszenia.

Jeżeli klient odpowiada w tym samym wątku, Lightning Threading pomaga połączyć wiadomość z istniejącym Case’em.

Po otrzymaniu nowego maila Record-Triggered Flow może automatycznie:

zmienić status zgłoszenia na „Odpowiedź klienta”, powiadomić właściciela sprawy, zwiększyć licznik ponagleń i utworzyć zadanie wymagające reakcji.

W ten sposób mail przestaje być kolejną wiadomością leżącą gdzieś w skrzynce.

Staje się elementem procesu, który ktoś musi obsłużyć.

Benefit

• Cała historia korespondencji znajduje się w jednym miejscu.
• Konsultant nie musi przeszukiwać skrzynki mailowej ani pytać innych pracowników, czy klient przypadkiem wcześniej czegoś nie wysłał.
• Ryzyko pominięcia wiadomości spada, a klient nie musi pisać tego samego drugi, trzeci i czwarty raz.

Problem

Załóżmy nawet, że moje kolejne wiadomości utworzyły nowe zgłoszenia.

To nadal nie powinno oznaczać, że konsultant widzi wyłącznie jeden Case i nie ma pojęcia o pozostałych.

Jeżeli ten sam klient ma kilka zgłoszeń dotyczących tej samej drukarki, system powinien od razu to zauważyć.

Jak powinno to wyglądać?

Po wejściu na nowy Case system powinien automatycznie sprawdzić, czy ten klient ma już inne otwarte albo podobne zgłoszenie.

Można porównywać między innymi:

adres e-mail, numer telefonu, numer zamówienia, numer seryjny urządzenia, temat zgłoszenia i powiązany produkt.

Do zbudowania takiej logiki można wykorzystać Flow Builder, odpowiednie reguły dopasowania i komponent wyświetlany na stronie Case’a.

Konsultant od razu widzi komunikat:

„Ten klient ma już podobne zgłoszenie”.

Ale sam komunikat to jeszcze za mało.

Proces powinien wymagać od konsultanta wykonania jednej z trzech rzeczy:

połączenia Case’ów, potwierdzenia, że są to dwie różne sprawy, albo przekazania ich do ręcznej weryfikacji.

Dopiero później można przejść dalej.

Jeżeli zgłoszenia faktycznie są duplikatami, można wykorzystać Merge Cases i połączyć je w jedną historię.

Benefit

• Każdy nowy Case zostaje sprawdzony przed rozpoczęciem obsługi.
• Konsultant widzi całą historię klienta, a firma nie podejmuje trzech różnych decyzji w trzech różnych zgłoszeniach dotyczących dokładnie tego samego problemu.
• Mniej duplikatów, mniej nieporozumień i mniej pracy wykonywanej kilka razy.

Problem

Obsługa klienta, serwis i logistyka wyglądały tak, jakby działały w trzech oddzielnych firmach.

Jedna osoba wysyłała eskalację.

Druga zamawiała nową drukarkę.

Ktoś inny miał zająć się zwrotem.

A klient musiał tłumaczyć wszystkim, co wydarzyło się wcześniej.

Jak powinno to wyglądać?

W Service Console konsultant powinien widzieć w jednym miejscu:

dane klienta, zamówienie, reklamowane urządzenie, numer seryjny, historię Case’ów, całą korespondencję, aktualne oczekiwanie klienta, otwarte zadania i wcześniejsze eskalacje.

Warunkiem oczywiście jest integracja Salesforce z systemem zamówień/ERP oraz wymiana statusów z zewnętrznym serwisem. To zwykle najtrudniejszy element do wprowadzenia, poza dobrze przemyślaną konfiguracją Service Cloud.

Sama drukarka może być zapisana w Salesforce jako Asset i powiązana z konkretnym klientem, zamówieniem i reklamacją.

Za odpowiedzialność można wykorzystać Case Owner, Queues, Case Teams oraz Omni-Channel.

Każda sprawa powinna mieć właściciela, kolejny krok i termin wykonania.

Nie „wysłałem do serwisu”.

Tylko:

„Sprawa została przypisana do konkretnej osoby, która ma odpowiedzieć do konkretnego dnia”.

Benefit

• Każda osoba otwierająca Case widzi ten sam stan faktyczny.
• Klient nie musi po raz kolejny opowiadać całej historii, a konsultant nie musi prowadzić śledztwa po skrzynkach, notatkach i wiadomościach na Teamsie.

Na przykład: jeśli konsultant obsługuje 40 zgłoszeń dziennie i 1/4 to pytania o status, automatyczne aktualizacje zwalniają ~2 godziny jego czasu dziennie to policz to razy liczba konsultantów. Wtedy wyjdzie realny zysk.

Problem

Na początku chciałem naprawy.

Później zmieniłem decyzję i poprosiłem o rozwiązanie umowy oraz zwrot pieniędzy.

Firma nadal realizowała wcześniejszy scenariusz, czyli wymianę drukarki.

I właśnie dlatego kurier miał dostarczyć mi nowe urządzenie tylko po to, żeby chwilę później je odebrać.

Jak powinno to wyglądać?

Na Case powinno znajdować się obowiązkowe pole, na przykład Oczekiwane rozwiązanie.

Do wyboru: naprawa, wymiana, zwrot pieniędzy, rezygnacja albo inne rozwiązanie.

Zmiana tej wartości powinna uruchamiać Record-Triggered Flow.

Jeżeli klient zmienia decyzję z wymiany na zwrot pieniędzy, system powinien automatycznie zatrzymać otwarte zadania związane z wysyłką, poinformować logistykę i przekazać sprawę do zespołu odpowiedzialnego za refundację.

Dodatkowo Validation Rule może zablokować zamówienie wysyłki, jeżeli aktualnym rozwiązaniem jest zwrot środków albo istnieje nieobsłużona wiadomość klienta.

Benefit

• Firma nie wykonuje działań, które są już nieaktualne.
• Nie płaci za niepotrzebnego kuriera, pracę magazynu, ponowny odbiór urządzenia i dodatkową obsługę klienta.
• A klient nie ogląda procesu, w którym lewa ręka nie wie, co robi prawa.

Problem

Przez kilka tygodni nie wiedziałem, co dzieje się z drukarką.

Firma kontaktowała się ze mną głównie wtedy, kiedy sama miała nową informację.

Jeżeli informacji nie było, była cisza.

W efekcie to ja musiałem pilnować procesu i co jakiś czas pytać, czy ktoś nadal pamięta o mojej sprawie.

Jak powinno to wyglądać?

Za pomocą Flow Builder, Scheduled Paths, Email Alerts i Email Templates można ustawić automatyczne aktualizacje dla klienta.

I nie muszą one zawierać przełomowych informacji.

Czasem wystarczy wiadomość:

„Twoje urządzenie nadal znajduje się w serwisie. Nie otrzymaliśmy jeszcze wyniku diagnozy. Kolejną aktualizację wyślemy najpóźniej za trzy dni”.

To nadal jest lepsze niż cisza.

Benefit

• Klient wie, że jego sprawa nadal jest obsługiwana.
• Spada liczba telefonów z pytaniem „co z moją reklamacją?”, a konsultanci mogą zajmować się rozwiązywaniem problemów zamiast odpowiadać po raz dziesiąty na pytanie o status.

Problem

Podczas rozmowy usłyszałem, że konsultantka wysłała eskalację do serwisu.

• Tylko co to właściwie znaczy?
• Czy ktoś dostał zadanie?
• Czy miał określony termin?
• Czy po przekroczeniu terminu sprawa trafiła wyżej?
• Czy może po prostu wysłano wiadomość i wszyscy liczyli, że ktoś kiedyś na nią odpowie?

Jak powinno to wyglądać?

Eskalacja powinna być normalnym etapem procesu, a nie tylko mailem wysłanym do innego działu.

Za pomocą Escalation Rules, Queues, Tasks, Milestones i Flow można określić:

kto odpowiada za eskalację, do kiedy ma zareagować, co dzieje się po przekroczeniu terminu i kto przejmuje sprawę na kolejnym poziomie.

Każda eskalacja powinna mieć właściciela.

Bo „serwis” nie jest właścicielem.

Właścicielem jest konkretna osoba albo konkretny zespół.

Benefit

• Sprawa nie znika w bliżej nieokreślonym miejscu między obsługą klienta a serwisem.
• Wiadomo, kto ma wykonać kolejny krok i kiedy powinien to zrobić.

Problem

Po całym zamieszaniu poprosiłem o rekompensatę w postaci bonu.

Wniosek podobno został złożony.

Problem w tym, że o bon również musiałem później dopytywać.

Czyli nawet kiedy firma obiecała mi coś na zakończenie sprawy, nadal to ja musiałem pilnować, czy obietnica zostanie spełniona.

Jak powinno to wyglądać?

W Salesforce można utworzyć osobny rekord albo proces dotyczący rekompensaty.

Może to być na przykład Compensation Request, zadanie albo prosty Screen Flow, który prowadzi konsultanta przez cały proces.

Taki wniosek powinien zawierać:

rodzaj rekompensaty, wartość bonu, osobę zatwierdzającą, termin realizacji i aktualny status.

Case nie powinien zostać zamknięty, dopóki bon nie zostanie faktycznie wysłany.

Benefit

• Firma kontroluje obietnice składane klientom.
• Konsultant nie musi pamiętać, komu obiecał bon, a klient nie musi kolejny raz dzwonić i przypominać, że coś miało do niego trafić.

Problem

Moja reklamacja trwała tygodniami, a mimo to nikt wcześniej nie zauważył, że zaczyna wymykać się spod kontroli.

To oznacza, że kierownik prawdopodobnie nie miał prostego widoku pokazującego sprawy zagrożone.

Jak powinno to wyglądać?

Za pomocą Reports and Dashboards można przygotować widok pokazujący między innymi:

zgłoszenia bez zmiany statusu, przekroczone terminy, sprawy z kilkoma ponagleniami, otwarte eskalacje, Case’y bez właściciela i obiecane rekompensaty, które nadal nie zostały wysłane.

Team leader nie musi przeglądać każdego zgłoszenia osobno.

Powinien od razu widzieć, które sprawy wymagają reakcji.

Benefit

• Firma reaguje wcześniej.
• Zanim klient napisze skargę.
• Zanim poprosi o zwrot.
• Zanim kurier pojedzie w obie strony z drukarką, której nikt już nie chce.

Salesforce nie naprawiłby uszkodzonego hotendu.

Nie sprawiłby też magicznie, że zewnętrzny serwis wykona diagnozę w jeden dzień.

Mógłby jednak dopilnować, żeby firma zauważyła, że naprawa trwa za długo, przypisała sprawę konkretnej osobie, poinformowała klienta, zauważyła jego maile i zatrzymała wysyłkę urządzenia, którego klient już nie chciał.

I większość tych rzeczy nie wymaga żadnego AI.

Wymaga dobrze poukładanego procesu, kilku automatyzacji i jednego miejsca, w którym znajduje się cała historia klienta.

Jeśli Twój dział obsługi wygląda jak ten opisany wyżej, umów bezpłatny audyt procesu reklamacyjnego na Service Cloud — w tydzień pokażemy, gdzie sprawy utykają i które automatyzacje odzyskają najwięcej czasu zespołu… Bo nawet najlepszy konsultant niewiele zrobi, jeżeli system pokazuje mu tylko część informacji, a pełną historię zna wyłącznie zdenerwowany klient.