W skrócie
Pole Przyczyna reklamacji grupuje sprawy według problemu, więc jego wartości muszą pochodzić ze spójnego słownika. Przyczyna zgłoszona przy rejestracji różni się od przyczyny stwierdzonej po badaniu towaru, dlatego obie zapisujemy osobno. Dokumentacja nie opisuje, czy pole jest listą wyboru, więc słownik ustalamy przy wdrożeniu i sprawdzamy w demo. Dobrze zbudowany słownik ma kilkanaście rozłącznych pozycji z definicjami i pozycję Inna, którą przeglądamy co miesiąc.
Przyczyna reklamacji a kategoria problemu
Pole Przyczyna reklamacji występuje w sekcji Dane zgłoszenia formularza pracownika i w formularzu WWW dla klienta. Wydruk reklamacji ma sekcję o tej samej nazwie, a podgląd dokumentu pokazuje pole Przyczyna. Strona produktu Studio RMA.net mówi z kolei o kategorii problemu zapisywanej przy zgłoszeniu razem z opisem usterki i zdjęciami. Oba pojęcia opisują ten sam cel: pogrupowanie spraw według problemu, zanim ktoś zbada towar. Czy pole w wersji 1.173.0 ma listę wyboru, dokumentacja nie mówi, więc sprawdzamy to w demo przed wdrożeniem.
Przyczyna służy do grupowania spraw, a opis wady do oceny jednej sprawy, co rozwijamy przy opisie wady w zgłoszeniu reklamacyjnym. Klasyfikacja działa tylko wtedy, gdy ta sama wada zawsze trafia pod tę samą przyczynę. Wpis dowolnym tekstem rozbija jedną wadę na wiele wariantów, np. „nie włącza się” i „brak zasilania”, a raport liczy je osobno.
Przyczyna zgłoszona i przyczyna stwierdzona
Przy rejestracji przyczynę podaje klient w formularzu WWW albo pracownik na podstawie rozmowy. Taki wpis nie jest jeszcze ustaleniem, bo nikt nie zbadał towaru. Pola formularza dla klienta opisujemy przy formularzu reklamacyjnym online na stronie firmy. W klasyfikacji rozróżniamy więc dwie przyczyny:
- Przyczyna zgłoszona - objaw opisany przy rejestracji, np. „nie ładuje się”, zapisany w polu Przyczyna reklamacji.
- Przyczyna stwierdzona - wynik badania przez serwis albo rzeczoznawcę, zapisany w danych naprawy, np. uszkodzone gniazdo.
Raport oparty tylko na przyczynach zgłoszonych pokazuje, jak klienci opisują problemy, a nie skąd się biorą. Według starszej dokumentacji pracownik serwisu dopisuje dane naprawy do dokumentu reklamacji, więc przyczynę stwierdzoną ma gdzie zapisać. Przy wdrożeniu ustalamy, czy przyczynę stwierdzoną zapisujemy w osobnym polu, czy w notatce, bo od tego zależą późniejsze raporty. Przyczyna stwierdzona decyduje o tym, kto poniesie koszt, więc jej zapis ma znaczenie przy rozliczeniu z dostawcą.
Raport na przyczynach stwierdzonych pokazuje źródło wady, a na zgłoszonych tylko opis klienta.
Zasady budowy słownika przyczyn
Słownik przyczyn działa, gdy pracownik w kilka sekund wybiera właściwą pozycję, a dwie osoby wybierają tę samą dla tej samej wady. Słownik z setką pozycji tego nie zapewnia, bo pracownicy wybierają wtedy pierwszą pasującą. Słownik powstaje z listy ostatnich spraw, a nie z wyobrażenia o nich, więc zaczynamy od przeglądu kilkuset zgłoszeń. Przy wdrożeniu stosujemy cztery zasady:
- Rozłączność - każda wada pasuje do jednej pozycji, a nie do dwóch.
- Definicja - każda pozycja ma zdanie, które mówi, kiedy ją wybrać.
- Rozsądna długość - kilkanaście pozycji zamiast kilkudziesięciu, najlepiej w kilku grupach.
- Pozycja Inna - z obowiązkowym opisem, przeglądana co miesiąc.
Gdy pozycja Inna obejmuje więcej niż kilka procent spraw, słownikowi brakuje pozycji, którą trzeba dodać. Zmiany w słowniku wprowadzamy od początku miesiąca, żeby raporty nie mieszały starych i nowych pozycji w jednym okresie. Nazwy pozycji nie zmieniamy po cichu, bo stare sprawy zostają z dawną nazwą. Spójność sprawdzamy prostym testem: dwóch pracowników klasyfikuje te same dziesięć spraw, a różnice pokazują niejasne pozycje.
Przykładowe grupy przyczyn
Słownik porządkujemy w grupy według miejsca powstania wady, bo od niego zależy, kto odpowiada za koszt. Pierwszy poziom mówi o źródle problemu, a drugi o konkretnej wadzie. Dla innych branż grupy wyglądają inaczej, co pokazujemy przy zasadach reklamacji artykułów spożywczych. Przykładowy podział dla sklepu z elektroniką wygląda tak:
| Grupa przyczyn | Przykładowe przyczyny | Kto zwykle ponosi koszt |
|---|---|---|
| Wada produkcyjna | Niedziałający podzespół, pęknięta obudowa | Producent albo dostawca |
| Uszkodzenie w transporcie | Zgniecione opakowanie, rozbity ekran | Sklep, a potem przewoźnik |
| Niezgodność z opisem | Inny kolor, brak elementu zestawu | Sprzedawca |
| Uszkodzenie przez użytkownika | Zalanie, upadek | Użytkownik, jeśli sprzedawca to wykaże |
Grupa Uszkodzenie przez użytkownika oznacza zwykle odmowę uznania reklamacji, więc przypisujemy ją dopiero po badaniu towaru. Grupa Niezgodność z opisem wskazuje zwykle na błąd w karcie produktu albo w kompletacji zamówienia, a nie na wadę fabryczną. Przy zgłoszeniu taka przyczyna byłaby oceną klienta przed zbadaniem towaru, a przez 2 lata od dostarczenia działa domniemanie na jego korzyść. Domniemanie i opinię rzeczoznawcy opisujemy przy opinii rzeczoznawcy w procesie reklamacji.
Słownik w skorowidzach programu
Według starszej dokumentacji listy wartości w programie przechowują skorowidze, które ustawia administrator, m.in. skorowidz działań korygujących. Menu Kartoteki ma też pozycję Słowniki, a pola formularza ustawia się według starszej dokumentacji przy wdrożeniu. Czy słownik przyczyn trafia do skorowidza, czy do słownika kartotek, ustalamy razem z producentem programu. Lista w skorowidzu nie usuwa błędów wyboru, ale ogranicza je do kilkunastu możliwości. Skorowidze opisujemy przy skorowidzach w programie reklamacyjnym.
Słownik zapisany w skorowidzu ma jedną zaletę: zmianę wprowadza administrator w jednym miejscu, a nie każdy pracownik u siebie. Formularz WWW korzysta z tej samej listy tylko wtedy, gdy wdrożenie tak ją ustawi, co sprawdzamy w demo. Dla klienta nazwy przyczyn upraszczamy, bo klient nie zna języka serwisu.
Przyczyny a kody IRIS
W serwisie elektroniki zamiast własnego słownika można użyć kodów IRIS, które opisują m.in. objaw i uszkodzenie. Według starszego opisu zgłaszający wybiera kod objawu, a serwisant uzupełnia kod uszkodzenia, co odpowiada podziałowi na przyczynę zgłoszoną i stwierdzoną. Zrzuty formularzy nie pokazują pól IRIS, więc ich dostępność sprawdzamy przed wdrożeniem. Kody IRIS mają sens zwłaszcza w serwisach, które rozliczają naprawy z producentami elektroniki, bo ci często używają tego standardu. Kody opisujemy przy kodach IRIS w naprawach serwisowych.
Przyczyny w raportach i przeglądach
Raport Statystyki wg uszkodzeń artykułów pokazuje, które wady powtarzają się przy artykułach, a jego wartość zależy od spójności słownika. Na przeglądzie zaczynamy od udziału pozycji Inna, bo jego wzrost oznacza, że słownik przestał pasować do spraw. Potem porównujemy przyczyny zgłoszone ze stwierdzonymi, bo duża rozbieżność wskazuje na formularz, który źle prowadzi klienta. Wnioski i działania korygujące opisujemy przy analizie przyczyn i trendów reklamacji.
Słownik przyczyn przeglądamy razem z działem jakości co kwartał, a pozycje bez użycia przez pół roku wycofujemy z listy wyboru. Pozycje o najwyższym udziale dostają właściciela, który szuka ich przyczyny u dostawcy albo w procesie. Słownik, którego nikt nie przegląda, po roku przestaje opisywać rzeczywiste sprawy. Serię tej samej wady w partii opisujemy przy wadach powtarzalnych w partii produktu, a raporty według artykułu przy tabelach przestawnych i statystykach reklamacji. Klasyfikacja zgłoszeń jest punktem wyjścia do analizy, a nie jej wynikiem, bo przyczynę źródłową ustala dopiero przegląd spraw.