System obsługi gwarancji producenta: jak powiązać zgłoszenie z egzemplarzem produktu

Najpierw ustal, czego dotyczy zgłoszenie

Klient zgłasza problem z urządzeniem i podaje nazwę modelu. Producent ma jednak kilka wersji produktu, różne warunki gwarancji oraz historię wcześniejszej naprawy konkretnego egzemplarza. Jeśli konsultant widzi tylko nazwę modelu, musi odtwarzać kontekst z korespondencji. To wydłuża rozmowę i zwiększa ryzyko, że decyzja zostanie oparta na niewłaściwych warunkach.

System obsługi gwarancji powinien powiązać zgłoszenie z właściwym egzemplarzem, dokumentem dotyczącym gwarancji i osobą uprawnioną do podjęcia decyzji. Powinien też pozwolić wskazać brak informacji bez zamykania sprawy. Sam numer seryjny nie rozstrzyga jeszcze, jakie działania przysługują klientowi ani jak należy obsłużyć problem.

Poniższy przykład producenta urządzeń jest fikcyjny. Opisujemy organizację procesu, a nie gotową odpowiedź na konkretne roszczenie. Warunki gwarancji, rodzaj zakupu i właściwe przepisy należy sprawdzić dla danej sprawy. Nie każda reklamacja musi opierać się na gwarancji.

Gwarancja i inne podstawy reklamacji

UOKiK opisuje gwarancję jako dobrowolne oświadczenie gwaranta dotyczące jakości towaru. Dla konsumenta odrębną podstawą reklamacji może być niezgodność towaru z umową. To ważne rozróżnienie dla formularza i zespołu obsługi. Klient nie powinien być kierowany do jednej ścieżki wyłącznie dlatego, że jest wygodniejsza dla systemu.

Jeżeli firma obsługuje różne rodzaje zgłoszeń, nazwijcie je zrozumiale i zapewnijcie sposób wyjaśnienia niepewności. Klient może nie wiedzieć, jaką podstawę chce wybrać. Osoba prowadząca sprawę powinna móc ustalić potrzebne informacje zgodnie z właściwymi zasadami, a system zachować tę decyzję bez dopisywania jej za użytkownika.

Warunki gwarancji mogą być różne dla produktów, dat sprzedaży i wersji oświadczeń. Nie oznacza to, że aplikacja może z góry zakładać jedną odpowiedź dla każdej sytuacji. Przed automatyzacją sprawdźcie treść konkretnej gwarancji oraz właściwe przepisy. Jeśli powstaje wątpliwość, potrzebna jest droga do oceny przez uprawnioną osobę.

UOKiK wskazuje również, że gwarancja nie pozbawia konsumenta przewidzianych praw wynikających z niezgodności towaru z umową. W projekcie nie należy ukrywać tej odrębnej drogi ani sugerować, że brak dokumentu zawsze zamyka możliwość rozmowy. Zespół powinien znać właściwy proces i aktualne źródła informacji.

Model, egzemplarz i historia produktu

Model opisuje rodzaj urządzenia. Egzemplarz to konkretna sztuka, którą klient zgłasza do obsługi. Numer seryjny lub inny identyfikator może pomóc je powiązać, ale najpierw trzeba ustalić, skąd pochodzi i w jakiej postaci jest zapisywany. Nie każdy produkt ma identyczny sposób oznaczenia, a etykieta może być uszkodzona lub trudno dostępna.

W fikcyjnym przykładzie producent sprzedaje urządzenia przez kilku partnerów. Klient podaje numer z obudowy i przybliżoną datę zakupu. System odnajduje dwa podobne zapisy, ponieważ jeden zawiera dodatkowy znak. Zamiast łączyć je automatycznie, powinien pokazać niepewność osobie obsługującej sprawę oraz umożliwić sprawdzenie źródła.

Przy egzemplarzu mogą znajdować się wcześniejsze naprawy, wymiany części lub informacje o obsłudze. Ustalcie, które zdarzenia rzeczywiście są dostępne i kto może je zobaczyć. Brak wpisu w historii nie musi oznaczać, że naprawa nigdy się nie odbyła. Może oznaczać, że wykonano ją poza systemem producenta albo nie przeniesiono wcześniejszych danych.

Jeżeli dane pochodzą od sprzedawcy, serwisu i producenta, uzgodnijcie ich znaczenie oraz źródło. W tekście o źródle danych w integracji opisujemy pytania, które pomagają rozpoznać rozbieżności. Identyfikator powinien prowadzić do konkretnej sztuki, a nie jedynie do podobnego produktu w katalogu.

Przed przeniesieniem wcześniejszych zgłoszeń sprawdźcie jakość powiązań między produktem i naprawą. Dwa urządzenia tego samego modelu mogą mieć podobne oznaczenia, ale różną historię. Jeżeli nie uda się potwierdzić relacji, wpis powinien pozostać do wyjaśnienia. Domyślne przypisanie do pierwszego pasującego rekordu może wprowadzić kolejnego konsultanta w błąd.

Wersja warunków i brakujące informacje

Przy zgłoszeniu zapiszcie, jakie warunki są sprawdzane oraz z jakiego dokumentu pochodzą. Jeśli firma aktualizowała oświadczenie gwarancyjne, osoba prowadząca sprawę powinna móc odróżnić wersje i ustalić, która dotyczy danej sytuacji. Nie wystarczy podmienić pliku na stronie i założyć, że nowa treść automatycznie opisuje wszystkie wcześniejsze zakupy.

Przy niepełnym zgłoszeniu zapytajcie o informacje, które rzeczywiście pomagają ustalić stan sprawy. Może to być oznaczenie produktu, opis objawu lub sposób kontaktu. Jeśli klient nie może odczytać numeru, potrzebna jest droga wyjaśnienia zamiast formularza, który kończy rozmowę na polu obowiązkowym.

UOKiK wskazuje, że brak dokumentu gwarancyjnego nie usuwa sam przez się uprawnień wynikających z gwarancji, choć może utrudnić ustalenie jej treści. Projekt powinien więc przewidywać sprawdzenie innych dostępnych informacji i przekazanie wątpliwości do właściwej osoby. Nie należy utożsamiać braku załącznika z automatycznym wynikiem oceny.

Ustalcie również, kto aktualizuje treść wzorów odpowiedzi i instrukcji dla konsultantów. Zmiana produktu lub zasad może wymagać ponownego przeglądu. Informacja, kiedy materiał został sprawdzony i kto za niego odpowiada, pomaga uniknąć wysyłania klientowi wskazówek dotyczących innej wersji urządzenia.

Warto zapisać także datę oraz pochodzenie informacji wykorzystanej w ocenie. Treść dokumentu może być dostępna w kilku miejscach, a kopie nie muszą być aktualizowane jednocześnie. Osoba prowadząca sprawę potrzebuje możliwości sprawdzenia, czy korzysta z właściwego oświadczenia i czy wcześniejsza odpowiedź odnosiła się do tej samej wersji produktu.

Od przyjęcia do decyzji

Po otrzymaniu zgłoszenia rozdzielcie przyjęcie sprawy od jej oceny. Komunikat może potwierdzać, że system zapisał wiadomość, ale nie powinien sugerować, że roszczenie zostało już uznane. Osoba prowadząca powinna wiedzieć, jakie informacje są dostępne, czego brakuje i kto podejmie decyzję o dalszej obsłudze.

W zależności od procesu konieczne może być przekazanie produktu do serwisu lub umówienie oceny na miejscu. Nie zakładajcie jednego sposobu dostarczenia dla wszystkich urządzeń. Właściwą procedurę należy ustalić na podstawie warunków i przepisów dotyczących danej sytuacji. Aplikacja powinna wyjaśniać kolejne kroki zgodnie z rzeczywistą decyzją, a nie wyświetlać ogólny scenariusz niezależnie od sprawy.

Jeśli serwis potrzebuje dodatkowej informacji, zadanie powinno mieć właściciela i termin kolejnego sprawdzenia. Klient powinien wiedzieć, o co został poproszony oraz gdzie może znaleźć aktualny stan sprawy. O przekazywaniu zadań między osobami piszemy w artykule o automatyzacji zleceń serwisowych. Jeżeli zgłoszenie trafia do warsztatu rowerowego, przyjęcie sprzętu i uzgodnienie zakresu pracy mają własny przebieg, opisany w artykule o aplikacji dla serwisu rowerowego.

Po podjęciu decyzji zapiszcie jej podstawę w zakresie odpowiednim dla procesu oraz sposób przekazania informacji klientowi. Automatyczna wiadomość może przygotować podsumowanie, ale nie powinna dopisywać przyczyny ani obietnicy, których osoba uprawniona nie zatwierdziła. Jeśli treść wymaga oceny, zostawcie wyraźny etap przeglądu.

Przy przekazaniu sprawy między zespołami zachowajcie uzgodniony kontekst. Pracownik serwisu powinien wiedzieć, jaki objaw zgłosił klient i co zostało już sprawdzone, jeśli ma prawo do tych informacji. Osoba kontaktująca się z klientem potrzebuje natomiast stanu i następnego kroku. Nie każda techniczna notatka musi pojawić się w wiadomości wychodzącej.

Naprawa, wymiana i historia kolejnej sprawy

Po wykonaniu uzgodnionych prac zapiszcie rezultat przy właściwym egzemplarzu lub powiązanym produkcie. Jeżeli wymieniono całe urządzenie, mogą istnieć dwa identyfikatory oraz relacja między nimi. Uzgodnijcie, który numer klient otrzyma po zakończeniu sprawy i gdzie znajdzie historię wcześniejszego zgłoszenia.

Nie wyliczajcie automatycznie nowego okresu wyłącznie na podstawie nazwy statusu „naprawione”. Skutek zależy od rzeczywistych czynności, warunków gwarancji i właściwych przepisów. UOKiK opisuje różne sytuacje dotyczące biegu gwarancji po wymianie lub naprawie. Zespół powinien ocenić konkretny przypadek, a system zachować dane potrzebne do tej oceny.

Jeśli naprawę wykonuje partner, ustalcie sposób przekazania wyniku oraz osoby, która go potwierdza. Odpowiedź z jednego narzędzia nie zawsze oznacza, że klient otrzymał produkt albo że wszystkie dane zaktualizowano. Przepływ potwierdzeń i obsługę błędów omawiamy przy API i webhookach.

Warto przewidzieć ponowne zgłoszenie po wcześniejszej naprawie. Konsultant potrzebuje kontekstu, ale nie powinien automatycznie zakładać, że nowy objaw ma tę samą przyczynę. Historia pomaga zadawać właściwe pytania. Decyzja o dalszej obsłudze powinna wynikać z aktualnych informacji i kompetencji osoby prowadzącej sprawę.

Dostęp do dokumentów i danych klienta

Zgłoszenie może zawierać dane kontaktowe, opis problemu, dokument zakupu lub zdjęcia. Ustalcie, które informacje są potrzebne na każdym etapie i kto może je zobaczyć. Serwis naprawiający urządzenie może potrzebować objawu i identyfikatora, ale niekoniecznie całej korespondencji handlowej klienta.

Przy dostępie klienta rozdzielcie różne sprawy i konta. Znajomość numeru seryjnego nie powinna sama w sobie otwierać pełnej historii innej osoby. Sprawdźcie uprawnienia przy wyszukiwaniu, pobieraniu dokumentów i korzystaniu z wcześniej zapisanych odnośników.

Zespół techniczny potrzebuje informacji o błędach, ale nie zawsze pełnej treści przesłanych dokumentów. Ustalcie zakres logów, czas ich przechowywania oraz osobę zajmującą się zgłoszeniem, które utknęło w integracji. Pomocne pytania znajdziecie w artykule o monitorowaniu automatyzacji.

W projektowaniu całej drogi klienta warto porównać również proces zwrotów i reklamacji sklepu, opisany w artykule o obsłudze zwrotów i reklamacji e-commerce. Podobne ekrany nie oznaczają jednak identycznych podstaw i decyzji.

Jeżeli klient zgłasza pomyłkę w dokumencie lub chce poprawić dane kontaktowe, zaplanujcie sposób potwierdzenia zmiany i osobę odpowiedzialną za jej wprowadzenie. Zapisana wcześniej wiadomość może już znajdować się u partnera serwisowego. Dlatego proces powinien wskazywać, czy i jak poprawiona informacja zostaje przekazana dalej.

Próba przed otwarciem formularza

Przygotujcie fikcyjny produkt, kilka egzemplarzy oraz różne wersje warunków. Prześledźcie zgłoszenie z kompletem danych, nieczytelnym numerem, brakującym dokumentem i wcześniejszą naprawą. Następnie sprawdźcie przypadek wymiany urządzenia oraz dostęp klienta do właściwej historii. Oczekiwane zachowanie trzeba uzgodnić z osobami prowadzącymi rzeczywisty proces.

Poproście konsultanta o ustalenie następnego kroku bez podpowiadania, gdzie znajduje się właściwy dokument. Klient powinien z kolei rozumieć, co zostało przyjęte i czego jeszcze nie rozstrzygnięto. O przygotowaniu takiej próby piszemy w tekście o testowaniu prototypu z pracownikami.

Przy odbiorze zapiszcie wersję aplikacji, dane testowe i osobę potwierdzającą wynik. Jeśli zewnętrzny serwis jest symulowany, test nie dowodzi działania rzeczywistej integracji. O scenariuszach i granicach takiej próby przeczytacie w artykule o odbiorze aplikacji.

Jeśli planujesz system gwarancyjny, poznaj zakres oprogramowania na zamówienie i skontaktuj się z Archifutura. W briefie opisz produkt, uczestników obsługi oraz moment, w którym dziś najtrudniej powiązać zgłoszenie z właściwą sztuką i warunkami. Na początek użyj przykładowych danych.

Po próbie porównajcie odpowiedzi konsultanta i klienta. Jeśli jedna osoba uważa, że zgłoszenie zostało tylko przyjęte, a druga, że podjęto już decyzję, komunikat wymaga poprawki. Zapiszcie uwagi oraz odpowiedzialność za ponowne sprawdzenie. Taki test pomaga ocenić zrozumiałość stanu bez formułowania obietnic dotyczących wyniku pojedynczej sprawy.