Program do zarządzania reklamacjami i przejrzystość statusu sprawy

Program do zarządzania reklamacjami a źródła frustracji klienta

Reklamacja rzadko jest przyjemnym doświadczeniem, ale frustrację potęguje przede wszystkim brak informacji. Klient nie wie, czy zgłoszenie dotarło, kto się nim zajmuje i kiedy dostanie odpowiedź. Pracownik z drugiej strony szuka historii w skrzynkach pocztowych i prowadzi dokumentację ręcznie. Program do zarządzania reklamacjami usuwa te przyczyny, a nie tylko ich skutki.

Artykuł dotyczy informacji widocznych w sprawie dla klienta i pracownika oraz pomiaru, czy program faktycznie ogranicza frustrację. Obieg zgłoszenia i model danych opisuje tekst o oprogramowaniu do obsługi reklamacji. Uprawnienia i przekazywanie spraw między działami zawiera artykuł o programie do obsługi reklamacji.

Numer RMA jako klucz sprawy

Każda reklamacja przyjęta do systemu dostaje unikalny numer RMA już w chwili rejestracji. Numer towarzyszy sprawie od pierwszego kontaktu do zamknięcia, niezależnie od tego, ilu pracowników zajmie się nią po drodze. Dokumentacja nie rozprasza się po skrzynkach, a każdy, kto otworzy zgłoszenie, widzi pełną historię działań. Numer staje się wspólnym językiem obsługi i magazynu, co ogranicza pomyłki przy przekazywaniu sprawy.

Maska numeru jest konfigurowalna. Przykładowa maska RMA-RRRR-NNNNN składa się z roku i numeru kolejnego, dzięki czemu identyfikator jest czytelny dla klienta i dla serwisu. Pełne omówienie znaczenia numeru zawiera artykuł numer RMA, a pojęcie RMA w logistyce zwrotnej wyjaśnia tekst o Return Merchandise Authorization.

CREATE SEQUENCE dbo.SeqNumerRMA AS INT START WITH 1 INCREMENT BY 1;

DECLARE @Numer VARCHAR(20);
SELECT @Numer = CONCAT('RMA-', YEAR(SYSDATETIME()), '-',
                       FORMAT(NEXT VALUE FOR dbo.SeqNumerRMA, '00000'));

Obiekt SEQUENCE gwarantuje unikalne numery także przy jednoczesnej rejestracji przez wielu pracowników, bo baza wydaje każdą wartość tylko raz. Sekwencja nie zeruje się sama z początkiem roku. Numeracja odnawiana co rok wymaga tabeli liczników, której konstrukcję opisuje tekst o oprogramowaniu do obsługi reklamacji. Nazwy obiektów w przykładzie są przykładowe.

Numer w kontakcie z klientem

Numer RMA jest użyteczny dopiero wtedy, gdy klient go widzi. Umieszcza się go w temacie wiadomości, na protokole reklamacyjnym i na etykiecie przesyłki. Gdy klient dzwoni i podaje numer, konsultant otwiera sprawę jednym wyszukiwaniem i nie musi pytać o imię, adres ani datę zakupu. Wyszukiwanie po numerze jest szybkie, jeśli kolumna z numerem ma unikalny indeks, który jednocześnie zabezpiecza bazę przed zdublowaniem numeru.

Reguła: numer sprawy nadaje baza w momencie zapisu zgłoszenia, a nie aplikacja ani pracownik, bo tylko wtedy dwa równoległe zgłoszenia nie dostaną tego samego numeru.

Dwa SLA w programie do zarządzania reklamacjami

Umowa o poziomie usług, czyli SLA, opisuje maksymalny czas odpowiedzi i rozpatrzenia reklamacji. Warto zdefiniować ją osobno dla pierwszej odpowiedzi i osobno dla ostatecznego rozwiązania sprawy. Klient najbardziej docenia szybkie potwierdzenie przyjęcia zgłoszenia, nawet jeśli merytoryczne rozpatrzenie wymaga kilku dni na diagnozę usterki.

Rozdzielenie obu SLA zmienia zachowanie zespołu. Gdy liczy się tylko czas rozwiązania, pracownik bez diagnozy nie ma powodu pisać do klienta. Gdy pierwsza odpowiedź ma własny termin, potwierdzenie wychodzi w pierwszych godzinach, a klient przestaje pytać, czy ktokolwiek zajmuje się jego sprawą.

Terminy wynikające z przepisów i liczenie dni roboczych opisuje artykuł o zarządzaniu reklamacjami i terminach. Kontrolę zaległości i wieku spraw zawiera tekst o programie do nadzorowania reklamacji.

Wstrzymanie zegara SLA

Zegar SLA rozwiązania bywa wstrzymywany, gdy sprawa czeka na działanie klienta, na przykład na przesłanie towaru do serwisu. Wstrzymanie musi być jawne: system zapisuje w historii jego początek i koniec wraz z powodem. Ukryte wstrzymywanie zegara zamienia SLA we wskaźnik, który zawsze wygląda dobrze, a nie odzwierciedla czasu oczekiwania klienta.

Status w sprawie jako komunikat

Status jest jedyną informacją, którą klient dostaje bez kontaktu z konsultantem, więc jego nazwa musi być zrozumiała bez wiedzy o procesie. Status oznaczony słowami z wewnętrznego żargonu firmy wywołuje dokładnie te pytania, którym miał zapobiec. Przy każdej zmianie statusu system może wysłać powiadomienie e-mail, a treść wiadomości powinna mówić, co się stało i co będzie dalej.

Statusów wewnętrznych bywa więcej, niż klient potrzebuje widzieć. Stany takie jak oczekiwanie na opinię serwisu albo na zatwierdzenie kierownika łączy się dla klienta w jeden komunikat, na przykład sprawa jest rozpatrywana. Mapowanie wielu statusów wewnętrznych na kilka zewnętrznych utrzymuje przejrzystość bez ujawniania szczegółów organizacji pracy. Klient nie powinien też zobaczyć statusu, który po chwili cofa się do poprzedniego bez wyjaśnienia.

Pomiar liczby kontaktów przypadających na sprawę

Skuteczność przejrzystości mierzy się liczbą kontaktów, które klient musi podjąć, żeby dowiedzieć się o swojej sprawie. Kontakt to zdarzenie w historii sprawy, na przykład telefon z pytaniem o status, które konsultant zapisuje jednym kliknięciem. Wskaźnik liczy się kohortowo: dla spraw zarejestrowanych w danym miesiącu zlicza się wszystkie zapisane kontakty.

SELECT m.Miesiac,
       COUNT(DISTINCT r.Id) AS Sprawy,
       COUNT(h.Id)          AS Kontakty,
       CAST(COUNT(h.Id) AS DECIMAL(9, 2)) / NULLIF(COUNT(DISTINCT r.Id), 0) AS KontaktyNaSprawe
FROM dbo.Reklamacja AS r
CROSS APPLY (SELECT DATEFROMPARTS(YEAR(r.DataRejestracji), MONTH(r.DataRejestracji), 1) AS Miesiac) AS m
LEFT JOIN dbo.HistoriaSprawy AS h
       ON h.SprawaId = r.Id AND h.Zdarzenie = N'PytanieOStatus'
GROUP BY m.Miesiac
ORDER BY m.Miesiac;

Zapytanie łączy sprawy z kontaktami przez LEFT JOIN, więc sprawy bez żadnego kontaktu wchodzą do mianownika. Bez tego wskaźnik byłby zawyżony, bo obejmowałby tylko sprawy, w których klient się odezwał. Funkcja NULLIF chroni przed dzieleniem przez zero w miesiącach bez spraw.

Po uruchomieniu powiadomień wskaźnik powinien spadać. Jeśli nie spada, przyczyną bywa niedostarczona poczta, status niezrozumiały dla klienta albo wiadomość wysyłana dopiero przy zamknięciu sprawy. Wskaźnik ma jedno ograniczenie: zależy od dyscypliny zapisywania kontaktów, więc wartość bezwzględna jest mniej ważna niż trend w czasie.

Dane z reklamacji dla jakości produktu

Reklamacje zawierają informacje, których firma nie zdobędzie inaczej: które produkty zawodzą i w jakich okolicznościach. Program do zarządzania reklamacjami zbiera je w postaci kodu przyczyny oraz modelu i partii towaru. Firma widzi wtedy najczęstsze przyczyny zwrotów i wadliwe produkty, a zmiany w produkcji lub w logistyce można oceniać po liczbie nowych spraw. Dane z reklamacji uzupełniają kontrolę na hali, ale jej nie zastępują, bo dotyczą wyłącznie wad, które dotarły do klienta i zostały zgłoszone.

Największą wartość mają dane porównywalne w czasie. Jeśli kody przyczyn zmieniają się co kwartał, trendów nie da się odczytać, dlatego słownik przyczyn zmienia się rzadko i z wpisem o dacie zmiany. Wpływ danych reklamacyjnych na jakość omawia artykuł o zarządzaniu reklamacjami a jakością produktów. Reklamację jako źródło informacji o produkcie przedstawia też tekst o kontroli jakości w systemie produkcyjnym.

Integracje ograniczające błędy przepisywania

Ręczne przepisywanie danych reklamacji między systemem sprzedaży a magazynem to częste źródło pomyłek przy zwrotach. Aplikacja obsługi reklamacji wymienia dane automatycznie, więc numer zamówienia oraz dane produktu trafiają do zgłoszenia razem z historią zakupu, bez udziału konsultanta. Rozwiązanie takie opisuje strona aplikacja obsługi reklamacji.

Integracja wymaga jednego źródła prawdy dla każdego pola. Jeśli sprzedaż i magazyn nazywają ten sam model inaczej, potrzebna jest tablica mapowania kodów, a rekordy bez dopasowania trafiają na listę wyjątków do ręcznej poprawy. Bez takiej listy niezgodne dane wpadają do zgłoszenia po cichu i wychodzą dopiero przy rozliczeniu.

Wstępna weryfikacja okresu rękojmi

Gdy data wydania towaru trafia do zgłoszenia z systemu sprzedaży, program może policzyć, czy zgłoszenie mieści się w okresie rękojmi. Wynik jest podpowiedzią dla pracownika, a nie decyzją, bo okresy zależą od rodzaju klienta i od warunków gwarancji.

SELECT r.Id,
       CASE WHEN r.DataZgloszenia <= DATEADD(YEAR, 2, s.DataWydania)
            THEN N'w okresie rekojmi'
            ELSE N'po okresie rekojmi'
       END AS PodpowiedzRekojmi
FROM dbo.Reklamacja AS r
JOIN dbo.SprzedazZrodlo AS s ON s.NumerDokumentu = r.NumerDokumentuSprzedazy;

Automatyczne pobranie danych skraca też czas weryfikacji uprawnień klienta do rękojmi lub gwarancji, bo data zakupu i model są znane w chwili rejestracji. Przy dużym wolumenie zgłoszeń kierownik działu może na bieżąco widzieć, które sprawy zbliżają się do przekroczenia terminu SLA.

Reklamacje B2C i B2B w jednym programie

Sposób obsługi zależy od modelu sprzedaży, ale program może obsłużyć oba modele w jednej bazie, jeśli konfiguracja pozwala rozróżnić rodzaj klienta.

• Klient indywidualny (B2C) - prostszy formularz i krótszy czas odpowiedzi, ponieważ konsument oczekuje szybkiej reakcji i nie zawsze zna zapisy Kodeksu cywilnego o rękojmi.
• Klient biznesowy (B2B) - protokoły reklamacyjne i uzgodnienia handlowe, więc sprawa bywa bardziej złożona i częściej wymaga akceptacji po stronie kontrahenta.

Zasada pozostaje ta sama: sprawnie obsłużona reklamacja przekłada się na lojalność klienta, a nie tylko na zamknięcie pojedynczej sprawy. Osobne omówienie sprzedaży konsumenckiej zawiera artykuł o reklamacjach B2C, a wpływ obsługi na powroty klientów opisuje tekst o zarządzaniu reklamacjami a lojalnością klientów.

W praktyce różnicę realizuje typ klienta zapisany w zgłoszeniu. Od niego zależą pola formularza i termin odpowiedzi. Typ klienta jest kolumną słownikową, a nie polem tekstowym, żeby raporty mogły grupować sprawy według modelu sprzedaży.

Ankieta CSAT po zamknięciu sprawy

Liczba kontaktów mierzy wysiłek klienta, ale nie jego zadowolenie z wyniku. Uzupełnia ją CSAT (Customer Satisfaction Score), czyli krótka ankieta wysyłana po zamknięciu sprawy. Jedno pytanie na skali od 1 do 5 wystarcza, bo długa ankieta obniża odsetek odpowiedzi.

Najczęściej stosowana konwencja liczy CSAT jako odsetek ocen 4 i 5 w ogólnej liczbie odpowiedzi. Ankieta powinna być powiązana z numerem sprawy, żeby wynik można było rozbić według decyzji: klient, któremu reklamację odrzucono, ocenia obsługę inaczej niż klient, któremu towar wymieniono. Wspólna średnia ukrywa tę różnicę.

SELECT DATEFROMPARTS(YEAR(a.DataOdpowiedzi), MONTH(a.DataOdpowiedzi), 1) AS Miesiac,
       COUNT(*) AS Odpowiedzi,
       100.0 * SUM(CASE WHEN a.Ocena >= 4 THEN 1 ELSE 0 END) / COUNT(*) AS CsatProc
FROM dbo.AnkietaCSAT AS a
GROUP BY DATEFROMPARTS(YEAR(a.DataOdpowiedzi), MONTH(a.DataOdpowiedzi), 1)
ORDER BY Miesiac;

Komentarz tekstowy warto powiązać z kodem przyczyny. Ocena 1 z uwagą o czasie oczekiwania wskazuje na SLA, a z uwagą o jakości naprawy na serwis. Klasyfikacja komentarzy raz w tygodniu wystarcza, aby zobaczyć, które elementy procesu obniżają ocenę.

Ankieta ma też własne pułapki. Klienci z wyraźnie złą albo wyraźnie dobrą opinią odpowiadają chętniej niż ci pośrodku, więc wynik przechyla się ku skrajnościom. Wysyłanie ankiety zaraz po zamknięciu sprawy podnosi odsetek odpowiedzi, ale przed fizycznym otrzymaniem naprawionego towaru mierzy tylko formalne zamknięcie. Wskaźnik ma sens dopiero przy odpowiedniej liczbie ankiet w okresie, bo kilka odpowiedzi w miesiącu nie daje wiarygodnego procentu. Funkcje programu do zarządzania reklamacjami w Studio RMA.net opisuje producent na stronie programu do zarządzania reklamacjami. Zachowanie statusów i numeracji można obejrzeć w wersji demonstracyjnej.