Zgłaszam naprawę, nie kupuję od nowa. Jak zaprojektować drogę serwisową

„Wybierz uszkodzony podzespół”. Klient patrzy na drewniany stojak, który nie utrzymuje ustawionego kąta. Zna skutek, ale nie wie, czy winny jest przegub, pokrętło czy element o nazwie zarezerwowanej dla magazynu. Formularz prosi go o diagnozę przed przyjęciem zgłoszenia. To dość odważny sposób organizowania serwisu.

W tym hipotetycznym przykładzie producent pomaga użytkownikom stojaków do ekspozycji ilustracji. Projekt strony powinien dostarczyć zespołowi dane identyfikujące egzemplarz oraz opis objawu. Klient ma przekazać to, co wie i może zaobserwować. Dopiero osoba zajmująca się serwisem ustali dalszy zakres sprawdzenia.

Produkt klienta zaczyna się poza bieżącym katalogiem

Droga do pomocy nie powinna wymagać ponownego kupowania. Na stronie produktu i w sekcji wsparcia przydaje się wyraźne wejście „Zgłoś problem z posiadanym stojakiem”. Zapisz, jakie sprawy przyjmuje ten kanał. Pytanie o dobór nowego rozmiaru może prowadzić do innej rozmowy niż zgłoszenie egzemplarza, który przestał zachowywać pozycję.

Pierwsze pole nie musi być numerem zamówienia. Klient mógł dostać produkt od firmy, kupić go przez partnera albo zgubić dawną wiadomość. Jeżeli numer jest potrzebny w dalszej obsłudze, wyjaśnij jego rolę i dopuszczalną drogę bez niego. Obowiązkowe pole z wymyślonym numerem nie dostarcza serwisowi lepszych danych niż jawne „nie mam zamówienia”.

Rozróżnij nazwę modelu, numer egzemplarza i numer zakupu. W katalogu mogą oznaczać trzy różne rzeczy. Pokaż przykład odpowiedniego oznaczenia na zdjęciu własnego produktu, z podpisem, gdzie go szukać. Ilustracja powinna pomagać odnaleźć etykietę, a nie sugerować demontaż lub czynność, której producent nie przewidział w instrukcji.

Apple opisuje dla komputerów Mac kilka dróg odczytania nazwy modelu i numeru seryjnego, w tym nadruk oraz opakowanie. Wskazuje także ograniczenie: po wymianie płyty głównej nadrukowany numer może nie być aktualny. To przykład identyfikacji konkretnego produktu, nie gotowy zestaw reguł dla naszego stojaka.

Własne reguły walidacji muszą wynikać z rzeczywistych oznaczeń. Apple wyjaśnia między innymi użycie cyfr 0 i 1 zamiast liter O i I oraz możliwy prefiks S w skanie kodu opakowania. Takich zasad nie należy kopiować do formularza innego producenta. Pozwalają natomiast zauważyć, że wpisany lub zeskanowany ciąg wymaga sprawdzenia według właściwego formatu.

Jeśli klient wybierze model z katalogu, pokaż nazwę i cechę rozróżniającą przed przejściem dalej. Stojak o podobnym wyglądzie może mieć inne mocowanie. Gdy system nie rozpoznaje numeru, nie podmieniaj go samoczynnie na najbliższy wynik. Można zaproponować pomoc w identyfikacji lub przyjąć zdjęcie oznaczenia, jeśli serwis rzeczywiście pracuje taką drogą.

Wyobraźmy sobie etykietę startą podczas kilku lat użytkowania. Klient potrafi wskazać stojak i dołączyć zdjęcie, lecz nie odczyta numeru nawet po powiększeniu. Ta ścieżka powinna prowadzić do innego kompletu danych, a nie do ponownego żądania tego samego numeru na końcu formularza. W podsumowaniu można zapisać „Model wymaga potwierdzenia przez serwis”. Zespół dostaje wtedy jawną niewiadomą. Jeśli bez identyfikacji nie może jeszcze zaproponować dalszego działania, odpowie w sprawie rozpoznania produktu, zamiast otrzymać losowo wybrany model i pozornie kompletny rekord.

Pamiętaj o starszych wyrobach. Aktualna oferta sprzedaży nie opisuje całego zbioru rzeczy używanych przez klientów. Powiązanie zgłoszenia z obsługą części do starej serii wymaga po stronie firmy danych o dawnych oznaczeniach. Na stronie wystarczy uczciwie pokazać drogę rozpoznania, zamiast usuwać starszy produkt z listy i pozostawiać klienta bez odpowiedzi.

Pytaj o zdarzenie, które człowiek potrafi opisać

Dla stojaka przydatne może być pytanie „Co się dzieje podczas używania?”. Odpowiedź „ramię opada po puszczeniu” przekazuje obserwację. Nazwa „uszkodzony mechanizm blokujący” jest już interpretacją. Formularz nie powinien zmuszać do wybrania tej drugiej tylko dlatego, że wewnętrzny system przydziela sprawy według części.

GOV.UK zaleca przygotowanie protokołu pytań, czyli ustalenie, po co potrzebna jest każda odpowiedź i jak zostanie wykorzystana. Wskazuje również rozgałęzienia pozwalające zadawać pytania odpowiednie dla danej osoby. W naszym projekcie oznacza to uzgodnienie pól z ludźmi, którzy faktycznie przyjmują sprawę, zanim powstanie ekran.

Przy każdym pytaniu wskaż dalszą decyzję serwisu. Model pozwala znaleźć właściwą dokumentację. Opis objawu pomaga przygotować rozmowę. Zdjęcie etykiety ułatwia identyfikację. Jeśli nikt nie potrafi powiedzieć, do czego użyje pola „dodatkowe parametry”, usuń je z obowiązkowego zestawu albo nazwij konkretną potrzebną informację.

Dobrze dobrana lista objawów może ułatwić odpowiedź. Powinna jednak zawierać drogę „Inny problem” z opisem, a czasem „Nie potrafię określić”. Wskazówki GOV.UK o pytaniach dopuszczają odpowiedzi wyrażające niepewność, jeśli są one prawidłowe dla danej sprawy. Takie pole nie zwalnia z dalszej obsługi; chroni przed wymuszoną, pozornie dokładną diagnozą.

W naszym przykładzie pytanie o częstotliwość może odróżniać „za każdym razem”, „czasami” i „zdarzyło się raz”. Nie dodawaj każdej możliwej odpowiedzi na zapas. Jeśli serwis pyta później o okoliczności tylko przy jednym objawie, pokaż to pytanie po właściwym wyborze. Zbyt rozbudowana lista podobnych usterek wymaga od klienta wiedzy, którą miał dopiero przekazać specjalista.

Przy zmianie objawu usuń z bieżącego podsumowania odpowiedzi, które należały wyłącznie do poprzedniej gałęzi. Jeżeli klient najpierw wybrał pęknięcie powierzchni, a następnie opadanie ramienia, odpowiedź o miejscu pęknięcia nie powinna zostać przedstawiona jako część aktualnego zgłoszenia. Opis wpisany własnymi słowami zachowaj do ponownego sprawdzenia przez klienta. Projekt powinien wyjaśnić zmianę zakresu pytań i pokazać nowy komplet przed wysłaniem. Dzięki temu cofnięcie do wcześniejszego ekranu nie tworzy sprzecznej historii, którą serwis będzie później próbował wyjaśniać telefonicznie.

Opis własnymi słowami zachowaj jako wypowiedź klienta. Przy podsumowaniu nie zmieniaj „wydaje mi się, że element jest luźny” w „stwierdzono luz”. Automatyczne uporządkowanie tekstu może być pomocne, lecz nie powinno podnosić pewności obserwacji. Dotyczy to także wykorzystania AI w obsłudze zgłoszeń i reklamacji, gdy firma później włącza takie narzędzie do procesu.

Opis objawu i oczekiwany dalszy krok odpowiadają na różne pytania. Klient może chcieć ustalić możliwość naprawy, zapytać o właściwy element lub otrzymać wyjaśnienie. Formularz ma przekazać ten zamiar zespołowi. Nie powinien przez samą etykietę przycisku rozstrzygać diagnozy ani zasad wykonania usługi.

Dane kontaktowe dobierz do następnego rzeczywistego kroku. Jeśli zespół odpowiada pocztą, numer telefonu nie musi być obowiązkowy tylko dlatego, że jest miejsce w makiecie. Jeżeli potrzebuje rozmowy, wyjaśnij to przy polu i pozwól wskazać warunki kontaktu, które potrafi uwzględnić. Osoba korzystająca z produktu nie zawsze jest nabywcą. Formularz powinien rozróżniać dane do odpowiedzi od danych dawnego zamówienia. W przeciwnym razie wiadomość o sprawie może trafić do osoby, która zna zakup, lecz nie zna opisywanego problemu.

Materiały mają pomóc, a nie stać się przeszkodą

Zdjęcie całego produktu i zdjęcie oznaczenia służą różnym celom. Zamiast dwóch pustych ramek pokaż, czego potrzebuje odbiorca zgłoszenia. Jeśli fotografia jest opcjonalna, powiedz, co serwis może zrobić bez niej. Jeżeli wymaga jej konkretny etap, uzasadnij ten warunek przy właściwym pytaniu, a nie dopiero po próbie wysłania formularza.

Zasady dodawania załączników i poprawiania pojedynczych plików pozwalają zachować opis mimo błędu zdjęcia. Klient powinien rozpoznać, czy fotografia dopiero została wybrana, czy dotarła do sprawy. Usunięcie starego zdjęcia i dodanie nowego nie może pozostawić w podsumowaniu obu jako aktualnych materiałów.

Przejście na telefon bywa naturalne: opis powstaje przy komputerze, a zdjęcie przy produkcie. Jeśli przewidujesz taką możliwość, zaprojektuj przekazanie zadania między urządzeniami. Osoba robiąca zdjęcie musi rozpoznać, do którego zgłoszenia ono trafi. Sam otwarty aparat nie potwierdza zachowania wcześniejszego kontekstu.

Materiały pomocnicze powinny dotyczyć właściwego modelu. Instrukcja produktu i pierwsze kroki mogą wyjaśnić oznaczenia lub pokazać przewidziany sposób korzystania. Nie każ jednak klientowi przechodzić całej instrukcji ponownie tylko po to, żeby otworzyć formularz. Jeśli zgłasza objaw występujący po kilku miesiącach, droga do kontaktu ma pozostać widoczna.

Przy pytaniu o zamiennik potrzebne jest osobne sprawdzenie zgodności z posiadanym produktem. Podobne zdjęcie części nie potwierdza dopasowania. W formularzu można zebrać oznaczenie i pytanie, pozostawiając potwierdzenie osobie lub systemowi dysponującemu właściwymi danymi. Nie wyświetlaj przyjęcia wiadomości jako potwierdzenia zgodności dodatku.

W Aeneia Design punktem wyjścia do takiej ścieżki są rzeczywiste pytania serwisu oraz możliwości obiegu zgłoszeń. Projekt może połączyć rozpoznanie modelu, opis i materiały w czytelną drogę. Przydatnym materiałem od firmy jest przykład poprawnie przyjętej sprawy oraz sprawy wymagającej uzupełnienia, przygotowany bez niepotrzebnych danych klienta.

Co właściwie zostało przyjęte

Przed wysłaniem pokaż wybrany produkt, opis objawu i listę materiałów. Poprawka jednej odpowiedzi powinna zachować pozostałe. Jeśli klient zmieni model, sprawdź, które wcześniejsze pola nadal mają sens. Nie przenoś automatycznie odpowiedzi o innej konstrukcji do nowego zgłoszenia tylko dlatego, że oba produkty są stojakami.

Po przyjęciu podaj rozpoznawalne oznaczenie sprawy oraz potwierdzony następny krok.

Jeśli po wysłaniu przerwie się połączenie, zachowaj rozróżnienie między brakiem potwierdzenia a odrzuceniem zgłoszenia. Gdy system potrafi sprawdzić stan wcześniejszej próby, pokaż wynik tego sprawdzenia przed propozycją ponowienia. Klient nie powinien dostać dwóch numerów sprawy tylko dlatego, że pierwsza odpowiedź nie dotarła do przeglądarki. „Otrzymaliśmy zgłoszenie” nie oznacza „produkt został zakwalifikowany do naprawy”. Jeśli serwis dopiero przejrzy materiały i skontaktuje się z klientem, właśnie tak opisz sytuację. Termin odpowiedzi może pojawić się tylko wtedy, gdy firma rzeczywiście go ustaliła dla tej ścieżki.

Uzupełnienie powinno należeć do istniejącej sprawy. Gdy serwis prosi o wyraźniejsze zdjęcie etykiety, klient nie powinien wypełniać formularza od nowa i przypadkiem utworzyć drugiego zgłoszenia. W wiadomości z prośbą pokaż numer sprawy oraz brakującą informację. Po dosłaniu fotografii potwierdź jej przyjęcie, zachowując wcześniejszy opis. Przy odbiorze strony przejdź także tę krótką dalszą drogę: pracownik prosi o jeden materiał, klient go przekazuje, a zespół odnajduje go przy odpowiedniej sprawie. To inny wynik niż samo poprawne wysłanie pierwszego formularza.

Dobrze zaprojektowana strona potwierdzenia po formularzu pozwala wrócić do sprawy. Pokaż także, czy na tym etapie klient powinien cokolwiek wysyłać fizycznie. Samo przyjęcie opisu nie może wyglądać jak polecenie nadania produktu pod domyślny adres firmy. Taka instrukcja musi pochodzić z uzgodnionego procesu obsługi.

Odbiór można zakończyć prostym zadaniem: osoba znająca wyłącznie model i objaw przekazuje sprawę bez wymyślania diagnozy. Zespół otrzymuje dane pozwalające rozpoznać egzemplarz, widzi brakujące informacje i potrafi wskazać dalszy krok. Formularz wykonał swoją pracę, jeśli specjalista nie musi zaczynać rozmowy od pytania, jaki produkt klient miał na myśli.