Nadzorowanie reklamacji jako proces cykliczny
Nadzorowanie reklamacji odpowiada na pytanie, czy procesowi można ufać bez sprawdzania każdej sprawy z osobna. Odpowiedź daje powtarzalny przegląd terminów i wskaźników, wykonywany o stałych porach i według tych samych definicji. Pojedyncza skarga klienta pokazuje jedną awarię procesu, a przegląd cykliczny pokazuje, gdzie awarie się powtarzają.
W zakresie nadzoru odnosi się ten tekst do normy PN-ISO 10002:2006 tylko w tym, co dotyczy cykliczności. Zapewnienie powtarzalności i cykliczności działań jest warunkiem prawidłowego nadzorowania reklamacji, a spełnia go ujęcie postępowania z reklamacjami w procesie zgodnie z tą normą. Wymagania prawne stanowią punkt odniesienia przy opracowywaniu polityki postępowania z reklamacjami, a ważnym elementem procesu są planowanie i organizowanie oraz dobór zasobów. Treści normy nie cytujemy. Szczegółowe wymagania trzeba sprawdzić w jej aktualnym tekście, a zgodność zasad z przepisami potwierdzić u prawnika.
Ręczne sterowanie wystarcza, gdy reklamacji jest niewiele. Gdy dziennie wpływają dziesiątki albo setki zgłoszeń, potrzebny jest system informatyczny, bo przeglądu cyklicznego nie da się wykonać na ręcznie prowadzonej liście. Tabela zestawia elementy nadzoru z osobą odpowiedzialną i rytmem, w jakim się je wykonuje.
| Element nadzoru | Co oznacza w praktyce | Kto odpowiada | Rytm |
|---|---|---|---|
| Kontrola terminów | Lista spraw bliskich terminu i już po terminie | Kierownik obsługi | Codziennie |
| Reakcja na eskalację | Decyzja o przydziale albo o priorytecie sprawy | Osoba na danym poziomie eskalacji | Po powiadomieniu |
| Przegląd wskaźników | Czas obsługi oraz odsetek uznanych i zaległych | Kierownik i dział jakości | Co tydzień lub co miesiąc |
| Przegląd zasad | Zgodność terminów i reguł z wymaganiami prawnymi | Właściciel procesu | Po zmianie przepisów lub umów |
Reguła: nadzór polega na przeglądzie o stałych porach według tych samych definicji, a nie na reagowaniu na pojedyncze skargi.
Kanały zgłoszeń i etapy normy w ujęciu rejestru opisuje artykuł o obsłudze reklamacji. Ten tekst zajmuje się tym, co następuje po zarejestrowaniu sprawy. Chodzi o pilnowanie terminów oraz o eskalację i wskaźniki.
Nadzór wymaga właściciela procesu, czyli osoby, która odpowiada za definicje wskaźników i za decyzję o zmianie progów. Bez właściciela każdy dział liczy po swojemu, a zmiana progu eskalacji w jednym miejscu psuje porównanie z poprzednim okresem. Właściciel prowadzi też zapis zmian: kiedy i dlaczego zmieniono próg albo definicję.
Terminy w nadzorowaniu reklamacji
Program nadzorujący pracuje na dwóch terminach jednocześnie. Pierwszy wynika z przepisów i zależy od rodzaju klienta. Artykuł o zarządzaniu reklamacjami i terminach podaje, jak zapisano go w tekstach jednolitych: konsument otrzymuje odpowiedź w ciągu 14 dni, a brak odpowiedzi oznacza uznanie reklamacji. Interpretację przepisów w konkretnej sprawie potwierdza prawnik. Drugi termin jest wewnętrzny, krótszy, i zostawia kierownikowi zapas na decyzję.
Rozwiązanie do prowadzenia reklamacji pozwala ustawić reguły, które określają, co dzieje się po wpłynięciu zgłoszenia: aplikacja powiadamia odpowiednie osoby i wyznacza im terminy na wykonanie zadań. Klienta można informować przy każdej zmianie statusu. To ustawienia, które nadzór wykorzystuje jako punkt wyjścia, a nie zastępuje.
Termin wewnętrzny liczy się często w dniach roboczych. Wtedy potrzebna jest tabela kalendarza z numerem dnia roboczego, w której dni wolne od pracy w ogóle nie występują. Zapytanie znajduje pierwszy dzień roboczy od daty wpływu i przesuwa się o zadaną liczbę dni.
-- dbo.KalendarzRoboczy(Data DATE PRIMARY KEY, NrDniaRoboczego INT) zawiera tylko dni robocze
DECLARE @start DATE = (SELECT MIN(Data) FROM dbo.KalendarzRoboczy WHERE Data >= @DataWplywu);
SELECT k.Data AS TerminWewnetrzny
FROM dbo.KalendarzRoboczy AS k
WHERE k.NrDniaRoboczego =
(SELECT NrDniaRoboczego FROM dbo.KalendarzRoboczy WHERE Data = @start) + @LiczbaDniRoboczych;Reguła: termin zapisuje się w sprawie w chwili rejestracji, żeby późniejsza zmiana kalendarza nie przesunęła terminów spraw otwartych.
Nazwy tabel i kolumn w przykładach są przykładowe, a kalendarz roboczy uzupełnia się co roku o święta ruchome.
Zatrzymanie biegu terminu wewnętrznego
Niektóre statusy zatrzymują zegar terminu wewnętrznego, na przykład „oczekuje na dane od klienta”. Zatrzymanie musi być jawne: znacznik w słowniku statusów określa, czy czas w danym statusie liczy się do terminu, a program zapisuje moment wejścia i wyjścia. Bez tego sprawa czekająca na odpowiedź klienta trafia na listę zaległych albo zostaje z niej wyłączona na stałe.
Zatrzymanie dotyczy wyłącznie terminu wewnętrznego. Kwestię, czy bieg terminu wynikającego z przepisów zatrzymuje się i w jakich okolicznościach, ocenia prawnik, a program nie powinien wyłączać wskazań ustawowych na podstawie samej zmiany statusu.
Poziomy eskalacji przy zagrożonym terminie
Eskalacja przekazuje informację o zagrożonym albo przekroczonym terminie wyżej, do osoby, która może zmienić przydział lub priorytet. Działa dobrze, gdy ma kilka poziomów o różnych adresatach i gdy każdy poziom uruchamia się tylko raz na sprawę. Wartości progów w tabeli są przykładowe, a każda firma ustala własne.
| Poziom | Wyzwalacz | Adresat | Działanie |
|---|---|---|---|
| 1 - przypomnienie | Połowa terminu wewnętrznego minęła, brak decyzji | Właściciel sprawy | Wiadomość i oznaczenie na liście |
| 2 - ostrzeżenie | Wykorzystane 90 procent terminu wewnętrznego | Kierownik zespołu | Decyzja o przydziale lub priorytecie |
| 3 - przekroczenie | Termin wewnętrzny minął | Kierownik obsługi klienta | Sprawa na liście zaległych, kontakt z klientem |
| 4 - zagrożenie terminu ustawowego | Zbliża się termin wynikający z przepisów | Osoba odpowiedzialna za jakość lub prawnik | Ostateczna decyzja przed upływem terminu |
Wyzwalanie eskalacji zadaniem w tle
Progi sprawdza zadanie uruchamiane cyklicznie, na przykład co kilkanaście minut, które dopisuje wiersze eskalacji dla spraw otwartych. Warunek NOT EXISTS gwarantuje, że dany poziom powstanie raz. W SQL Server takie zadanie konfiguruje się w SQL Server Agent, a wiadomości wysyła osobne zadanie czytające nieprzesłane wiersze, na przykład przez Database Mail.
-- zadanie cykliczne; nazwy poglądowe, UlamekTerminu np. 0.50, 0.90, 1.00
INSERT INTO dbo.Eskalacja (ReklamacjaId, Poziom, DataUtworzenia)
SELECT r.Id, p.Poziom, SYSDATETIME()
FROM dbo.Reklamacja AS r
JOIN dbo.PoziomEskalacji AS p
ON SYSDATETIME() >= DATEADD(MINUTE,
CAST(p.UlamekTerminu * DATEDIFF(MINUTE, r.DataWplywu, r.TerminWewnetrzny) AS INT),
r.DataWplywu)
WHERE r.CzyOtwarta = 1
AND NOT EXISTS (SELECT 1 FROM dbo.Eskalacja AS e
WHERE e.ReklamacjaId = r.Id AND e.Poziom = p.Poziom);Wiersze eskalacji zostają w bazie także po zamknięciu sprawy, więc pełnią rolę śladu i źródła statystyk: pokazują, jaki odsetek spraw dochodzi do poziomu trzeciego i w którym dziale. Poziom czwarty liczy się analogicznie od terminu ustawowego. Wiek spraw i kolejki na pracownika opisuje artykuł o programie do nadzorowania reklamacji.
Reakcja adresata na eskalację
Powiadomienie bez możliwości reakcji jest tylko hałasem. Adresat eskalacji potrzebuje w programie czterech operacji, z których każda zostawia ślad w historii sprawy:
- Zmiana właściciela - przekazanie sprawy osobie, która ma czas i uprawnienia do decyzji.
- Zmiana priorytetu - podniesienie sprawy w kolejce ze wskazaniem powodu.
- Kontakt z klientem - wiadomość o opóźnieniu wysłana ze sprawy, tak żeby trafiła do jej historii.
- Zmiana terminu wewnętrznego - przesunięcie z uzasadnieniem i akceptacją osoby wyższego szczebla; termin ustawowy pozostaje bez zmian.
Ostatnia operacja wymaga kontroli, bo bez niej eskalacja staje się sposobem na ukrycie zaległości. Każde przesunięcie terminu wewnętrznego liczy się jako osobny wskaźnik i wraca do przeglądu cyklicznego.
Wskaźniki nadzorowania reklamacji
Wskaźnik ma sens tylko wtedy, gdy każdy w firmie liczy go tak samo. Zapis definicji w jednym miejscu chroni przed sytuacją, w której dział jakości i dział obsługi pokazują różne liczby dla tego samego miesiąca. Poniższa tabela podaje trzy podstawowe wskaźniki i czwarty pochodny, każdy z typowym błędem obliczeniowym.
| Wskaźnik | Definicja | Typowy błąd |
|---|---|---|
| Czas obsługi | Dni od daty wpływu do daty decyzji dla spraw rozstrzygniętych w okresie, podawane jako mediana | Wliczanie spraw otwartych albo liczenie od daty rejestracji |
| Odsetek uznanych | Sprawy rozstrzygnięte na korzyść klienta podzielone przez wszystkie rozstrzygnięte w okresie | Dzielenie przez sprawy, które wpłynęły, choć część jeszcze czeka na decyzję |
| Zaległe | Sprawy otwarte po terminie na wskazany dzień | Porównanie ze stanem dzisiejszym zamiast z dniem raportu |
| Udział zaległych | Zaległe podzielone przez sprawy otwarte na ten sam dzień | Brak zapisu wcześniejszych stanów, więc trend jest niemożliwy do odtworzenia |
Wymienione miary uzupełnia zestaw KPI z artykułu o wyborze systemu do obsługi reklamacji, a rozdział na dwa terminy i ankietę satysfakcji po zamknięciu sprawy omawia tekst o programie do zarządzania reklamacjami.
Każdy wskaźnik podaje się razem z liczebnością, z której go policzono. Odsetek uznanych równy 50 procent znaczy co innego dla dwóch spraw w kategorii, a co innego dla dwustu. Przy małych liczbach lepiej pokazać liczby bezwzględne albo połączyć kategorie niż porównywać procenty. Wskaźniki zestawia się w kolejnych okresach tej samej długości, na przykład miesiąc do miesiąca, bo dopiero trend pokazuje, czy zmiana w procesie coś poprawiła.
Czas obsługi liczony medianą
Średni czas obsługi zniekształcają nieliczne, bardzo długie spory. Jedna sprawa trwająca kilka miesięcy podnosi średnią z całego okresu, choć zdecydowana większość spraw skończyła się w kilka dni. Mediana, czyli wartość środkowa, jest odporna na takie wartości odstające. Warto dodać percentyl 90, który pokazuje, w jakim czasie kończy się dziewięć na dziesięć spraw.
SELECT DISTINCT
k.Nazwa AS Kategoria,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY DATEDIFF(DAY, r.DataWplywu, r.DataDecyzji))
OVER (PARTITION BY r.KategoriaId) AS MedianaDni
FROM dbo.Reklamacja AS r
JOIN dbo.Kategoria AS k ON k.Id = r.KategoriaId
WHERE r.DataDecyzji >= @Od AND r.DataDecyzji < @Do;Funkcja PERCENTILE_CONT liczy percentyl z interpolacją, a zmiana wartości 0.5 na 0.9 daje percentyl 90. Zapytanie obejmuje wyłącznie sprawy z datą decyzji w okresie. To ważne, bo sprawy wciąż otwarte są z definicji najdłuższe i wskaźnik z nich pominiętych zawsze wygląda lepiej, niż jest w rzeczywistości. Dlatego obok mediany pokazuje się liczbę spraw otwartych starszych niż percentyl 90.
Odsetek uznanych i zaległe reklamacje
Odsetek uznanych mówi o tym, jak często decyzja jest korzystna dla klienta, i sam w sobie nie jest ani dobry, ani zły. Wysoki wynik w jednej kategorii towaru wskazuje na powtarzalną wadę, a wysoki w całej firmie może oznaczać zbyt łagodne kryteria oceny. Dlatego liczy się go według kategorii i przyczyny, a nie tylko w skali całości. Mianownik stanowią sprawy rozstrzygnięte w okresie, bo sprawy oczekujące nie mają jeszcze wyniku.
Rozbicie według przyczyny i dostawcy towaru zamienia wskaźnik w narzędzie pracy. Gdy w jednej kategorii odsetek uznanych rośnie, sprawdza się kody przyczyn: powtarzająca się wada partii wraca do dostawcy, a błędy w opisie oferty trafiają do działu, który ją prowadzi. Takie dane powstają tylko wtedy, gdy przy zamknięciu sprawy wybiera się kod ze słownika zamiast wpisywać opis własnymi słowami.
Liczba zaległych zmienia się codziennie, więc raport musi odpowiadać na pytanie, ile spraw było zaległych w konkretnym dniu. Zapytanie poniżej zlicza sprawy przyjęte do wskazanej daty, jeszcze nierozstrzygnięte w tym dniu i mające termin wewnętrzny sprzed niego.
SELECT COUNT(*) AS Zalegle
FROM dbo.Reklamacja AS r
WHERE r.DataWplywu <= @Dzien
AND (r.DataDecyzji IS NULL OR r.DataDecyzji > @Dzien)
AND r.TerminWewnetrzny < @Dzien;Reguła: zaległe liczy się na wskazany dzień, a nie na dzień uruchomienia raportu, więc program musi przechowywać daty decyzji i historię zmian.
Zapytanie zakłada, że data decyzji nie jest nadpisywana. Gdy decyzję zmienia się po odwołaniu, potrzebna jest pełna historia statusów, którą zapewniają tabele czasowe albo osobna tabela zdarzeń. Sposób budowy zestawień i wydruków wskaźników opisuje artykuł o SQL Report Builder i wydrukach RDL.
Przegląd cykliczny i wybór programu do nadzorowania
Przy wyborze programu do nadzorowania reklamacji warto sprawdzić cztery rzeczy, które odróżniają narzędzie nadzorcze od zwykłego rejestru:
- Wskaźniki z historii - zestawienia liczone z dat przejść między statusami, a nie z bieżącego stanu sprawy.
- Konfigurowalne progi - poziomy eskalacji i terminy zmieniane w ustawieniach, bez zmiany kodu.
- Ślad eskalacji - zapis, kto i kiedy został powiadomiony oraz jaką decyzję podjął.
- Eksport danych - możliwość pobrania zestawień do arkusza lub narzędzia raportowego, gdy dział jakości liczy własne miary.
Studio RMA.net pozwala, według opisu producenta zebranego w innych artykułach serwisu, definiować własne statusy i atrybuty spraw oraz integrować się z systemem ERP lub WMS. Sposób pracy aplikacji do nadzorowania przedstawia strona o aplikacji do nadzorowania reklamacji, a przebieg sprawy z terminami można obejrzeć w demo reklamacji.
Porównanie tego, co program powinien zapisywać w rejestrze, znajduje się w artykule o programie do reklamacji, a statusy i przejścia opisuje tekst o oprogramowaniu do obsługi reklamacji. Procedurę sprawy i jej etapy zawiera artykuł o procedurze RMA.
