Obsługa reklamacji a kanały zgłoszeń
Obsługa reklamacji zaczyna się w chwili, gdy klient zgłasza wadę, a pierwsza decyzja dotyczy tego, którędy zgłoszenie wpłynęło. Kanał wpływa na kompletność danych i na czas rejestracji, a także na to, czy sprawa ma numer, zanim ktokolwiek ją otworzy. Firma przyjmująca reklamacje mailem i w punkcie sprzedaży prowadzi w praktyce dwa osobne rejestry, dopóki nie zbierze ich w jednym systemie.
Wspólny rejestr nie oznacza jednego kanału. Oznacza jedną strukturę danych, do której każdy kanał zapisuje te same pola: dane klienta z dokumentem sprzedaży oraz opis wady. Osobno odnotowuje się datę wpływu, inną niż data wprowadzenia rekordu, ponieważ pracownik może wpisać maila z opóźnieniem, a termin odpowiedzi liczy się od wpływu.
| Kanał | Co trafia do rejestru | Typowe ryzyko |
|---|---|---|
| Formularz online | pola obowiązkowe, załączniki, data wpływu z serwera | puste lub niespójne dane, jeśli walidacja działa tylko w przeglądarce |
| Wiadomość e-mail | treść, nadawca, załączniki przepisane przez pracownika | opóźniona rejestracja i brak numeru sprawy w odpowiedzi |
| Punkt sprzedaży | protokół przyjęcia towaru i dokument zakupu | brak zdjęć usterki oraz podpisu klienta |
| Rozmowa telefoniczna | notatka pracownika i numer zgłaszającego | skrót myślowy zamiast opisu wady |

Numer sprawy od pierwszego kontaktu
Numer nadany przy rejestracji staje się wspólnym punktem odniesienia dla klienta i dla obsługi. Zasady jego budowy opisuje osobno artykuł o numerze RMA. W kontekście kanałów istotne jest jedno: numer powinien trafić do klienta w potwierdzeniu, niezależnie od tego, czy zgłoszenie przyszło formularzem, czy mailem.
Reguła: każdy kanał kończy się potwierdzeniem z numerem sprawy i datą wpływu, bo bez nich klient nie ma jak wykazać terminu zgłoszenia.
Przydział zgłoszenia do zespołu
Po rejestracji sprawa trafia do zespołu wskazanego regułą. Reguła porównuje kategorię produktu i oddział z tabelą przydziałów, więc pracownik nie wybiera kolejki ręcznie. Gdy żadna reguła nie pasuje, sprawa wpada do kolejki koordynatora, a nie znika z widoku.
SELECT TOP (1) z.ZespolId
FROM dbo.RegulaPrzydzialu AS z
WHERE z.KategoriaId = @KategoriaId
AND (z.OddzialId = @OddzialId OR z.OddzialId IS NULL)
ORDER BY CASE WHEN z.OddzialId IS NULL THEN 1 ELSE 0 END, z.Priorytet;
Zapytanie preferuje regułę przypisaną do konkretnego oddziału przed regułą ogólną, a przy remisie wybiera niższy priorytet liczbowy. Dzięki temu dwie identyczne sprawy z tego samego oddziału zawsze trafią do tego samego zespołu. Reguły utrzymuje koordynator, bez udziału programisty, a każda zmiana reguły ma w tabeli datę obowiązywania. Taki układ chroni przed sytuacją, w której po reorganizacji działu sprawy trafiają do osób, które już nie zajmują się reklamacjami.
Norma ISO 10002 jako model procesu reklamacyjnego
Norma ISO 10002 opisuje wytyczne postępowania ze skargami i reklamacjami w organizacjach, a w Polsce funkcjonuje jako PN-ISO 10002. Wersja z 2006 roku, którą cytował oryginał tej strony, wskazuje nie tylko potrzebę klasyfikowania zgłoszeń, lecz także ich analizowania. Norma nie narzuca konkretnego oprogramowania. Opisuje etapy, które organizacja powinna przejść, więc na jej podstawie da się zaprojektować statusy w systemie.
Poniższa tabela zestawia etapy postępowania ze zgłoszeniem z danymi, które system musi zapisać, żeby dało się je wykazać podczas audytu. Zestawienie jest tłumaczeniem norm na strukturę rejestru, a nie cytatem z tekstu normy.
| Etap postępowania | Dane zapisane w systemie | Kto odpowiada |
|---|---|---|
| Przyjęcie zgłoszenia | data wpływu, kanał, dane klienta | osoba rejestrująca |
| Potwierdzenie odbioru | wiadomość z numerem sprawy i terminem | system, automatycznie |
| Wstępna ocena | kategoria, pilność, przypisany zespół | koordynator obsługi |
| Badanie sprawy | ustalenia, załączniki, protokół oględzin | specjalista ds. reklamacji |
| Decyzja i odpowiedź | rozstrzygnięcie, uzasadnienie, data odpowiedzi | osoba uprawniona |
| Zamknięcie i analiza | kod przyczyny, koszty, wnioski dla jakości | dział jakości |
Analiza zgłoszeń jako wymóg procesu
Klasyfikacja bez analizy daje rejestr, z którego niczego nie wynika. Dlatego przy zamknięciu sprawy system wymusza wybór kodu przyczyny z zamkniętego słownika, a nie wpis tekstem wolnym. Zestawienia według kodów pokazują, czy powtarza się ten sam dostawca, ta sama partia towaru albo ten sam oddział. Odpowiedź na pytanie, skąd biorą się reklamacje, wynika wtedy z danych, a nie z wrażenia zespołu.

Terminy odpowiedzi i eskalacja zgłoszeń
Termin odpowiedzi jest wyliczany raz, przy rejestracji, i zapisywany w rekordzie sprawy jako data. Kolejki pracy sortuje się po tej dacie rosnąco, więc pracownik zawsze widzi na górze sprawy najbliższe przekroczenia. Ustawowy termin dla reklamacji konsumenckiej z tytułu rękojmi wynosi zwykle 14 dni kalendarzowych, a brak odpowiedzi w tym czasie skutkuje uznaniem zgłoszenia za zasadne. Przed wdrożeniem zasady warto potwierdzić z prawnikiem firmy, bo termin zależy od rodzaju roszczenia i statusu klienta.
Poniższe zapytanie wybiera sprawy otwarte, których termin upływa w ciągu dwóch dni. Nazwy tabel są przykładowe. Funkcje DATEADD i CAST opisuje dokumentacja DATEADD w T-SQL.
SELECT r.NumerRma, r.TerminOdpowiedzi, r.ZespolId
FROM dbo.Reklamacja AS r
WHERE r.StatusId < 7
AND r.TerminOdpowiedzi <= DATEADD(DAY, 2, CAST(SYSDATETIME() AS DATE))
ORDER BY r.TerminOdpowiedzi ASC, r.ReklamacjaId ASC;
Wynik takiego zapytania zasila powiadomienia. Studio RMA.net wyróżnia zgłoszenia z bliskim terminem realizacji i wysyła automatyczne powiadomienia o eskalacji na cztery sposoby:
- E-mail - wiadomość do osoby odpowiedzialnej i do jej przełożonego, gdy termin zostaje przekroczony.
- Telefon z Androidem - powiadomienie na urządzeniu mobilnym pracownika.
- Telefon z iOS - odpowiednik dla urządzeń Apple, z tą samą treścią.
- Pulpit komputera - komunikat widoczny podczas pracy w przeglądarce.
Eskalacja do przełożonego
Eskalacja ma sens dopiero wtedy, gdy ma adresata z nazwiska. Reguła w systemie wskazuje przełożonego osoby odpowiedzialnej i wysyła mu informację o incydencie w momencie przekroczenia terminu. Sprawa pozostaje przypisana do pierwotnego wykonawcy, a przełożony dostaje wgląd i możliwość zmiany przydziału.
Reguła: przekroczenie terminu tworzy zdarzenie w historii sprawy, dzięki czemu opóźnienie zostaje udokumentowane niezależnie od tego, kiedy sprawa zostanie zamknięta.
Obsługa reklamacji online w przeglądarce i w chmurze
Obsługa reklamacji online oznacza, że pracownicy i klienci korzystają z aplikacji przez przeglądarkę, bez instalowania programu na każdym komputerze. Aplikacja w technologii ASP.NET działa na serwerze, a użytkownik potrzebuje połączenia z Internetem i uprawnień. Po stronie firmy zostaje konto użytkownika i przeglądarka.
| Cecha | Serwer własny firmy | Hosting u dostawcy |
|---|---|---|
| Instalacja aktualizacji | wykonuje dział IT klienta | wykonuje dostawca według ustalonego harmonogramu |
| Kopie zapasowe bazy | zadanie SQL Agent skonfigurowane przez klienta | zapis w umowie o świadczenie usługi |
| Skalowanie zasobów | zakup sprzętu i licencji | zmiana parametrów usługi |
| Dostęp z zewnątrz | wymaga skonfigurowania sieci i certyfikatu | zapewnia dostawca |
Co zmienia się dla działu IT
Przy hostingu zewnętrznym dział IT nie odpowiada za instalację poprawek ani za zajętość dysku, ale nadal decyduje o tym, kto ma konto i jakie role otrzymuje. Zagadnieniem osobnym jest zakres modelu chmurowego, który omawia artykuł o obsłudze reklamacji w chmurze. Wdrożenie i integracje prowadzi zwykle zewnętrzny software house, a firmy porównujące warianty mogą też zajrzeć do opisu programu RMA online, dostępnego przez portal klienta.
Wersję demonstracyjną modułu reklamacji udostępnia serwis demo reklamacji. Pozwala sprawdzić, jak wygląda rejestracja sprawy i zmiana statusu w przeglądarce, bez wdrożenia.
Formularz zgłoszeniowy i wymiana danych ze sklepem
Internetowy formularz RMA jest najtańszym kanałem dla firmy, bo dane trafiają do rejestru bez przepisywania. Aplikacja Studio RMA.net udostępnia klientom spersonalizowaną stronę, na której klient samodzielnie inicjuje zwrot lub reklamację i śledzi ją później ze smartfona. Strona jest przystosowana do urządzeń mobilnych. Szczegółowe omówienie pól formularza znajduje się w artykule o zgłoszeniu reklamacji online.
Wysyłka formularza i walidacja po stronie serwera
Formularz wysyła dane asynchronicznie, a serwer je sprawdza i zwraca numer sprawy. Walidacja w przeglądarce poprawia wygodę, ale nie chroni rejestru, więc każde pole sprawdza się ponownie po stronie serwera. Podstawy wywołań opisuje dokumentacja Fetch API. Poniższy fragment JavaScript jest przykładem, a nie kodem produktu.
async function wyslijZgloszenie(form) {
const dane = new FormData(form);
const odp = await fetch('/api/zgloszenia', { method: 'POST', body: dane });
if (!odp.ok) {
throw new Error('Serwer odrzucił zgłoszenie: ' + odp.status);
}
const wynik = await odp.json();
return wynik.numerSprawy;
}
Po stronie serwera zgłoszenie trafia do procedury, która w jednej transakcji zapisuje nagłówek sprawy, historię pierwszego statusu i termin odpowiedzi. Dopiero po zatwierdzeniu transakcji formularz otrzymuje numer. Gdyby zapis się nie powiódł, klient zobaczy błąd zamiast numeru, którego nie ma w bazie.
Dane ze sprzedaży i marketplace
System reklamacji rzadko działa sam. Zamówienia i faktury pochodzą ze sklepu lub z ERP, a najwięcej pracy oszczędza wymiana danych, która podpowiada w formularzu produkty z zakupu klienta. W przypadku marketplace'ów, takich jak Allegro, klient zgłasza reklamację bez podawania od nowa danych, które sprzedawca już ma. Mechanizmy takich połączeń opisuje artykuł o integracji systemów informatycznych.
- Numer zamówienia - klucz łączący zgłoszenie z dokumentem sprzedaży i z pozycjami zakupu.
- Numer seryjny - pole obowiązkowe dla towarów objętych gwarancją, sprawdzane względem kartoteki.
Historia zgłoszeń i statusy widoczne dla klienta
Klient, który widzi etap swojej sprawy, rzadziej dzwoni z pytaniem o jej losy. Pełna historia kontaktu zapisana w rekordzie sprawy pozwala pracownikowi odpowiedzieć bez szukania danych w kilku miejscach. Klientowi udostępnia się jednak tylko wycinek tej historii, bez notatek wewnętrznych.
Wycinek realizuje się przez widok w bazie, który zawiera wyłącznie statusy oznaczone jako publiczne. Aplikacja portalu klienta odpytuje widok, a nie tabelę bazową, więc błąd w warstwie aplikacji nie ujawni notatek wewnętrznych. Składnię opisuje dokumentacja CREATE VIEW.
CREATE VIEW dbo.vHistoriaDlaKlienta
AS
SELECT h.ReklamacjaId, s.NazwaPubliczna AS Status, h.Czas
FROM dbo.ReklamacjaHistoria AS h
JOIN dbo.StatusReklamacji AS s ON s.StatusId = h.StatusDo
WHERE s.CzyPubliczny = 1;

Przejrzystość a liczba kontaktów
Widoczny status nie rozwiązuje reklamacji, ale ogranicza liczbę telefonów z pytaniem o etap. Klient zna termin odpowiedzi od pierwszego dnia i wie, że system go pilnuje. W zamian firma musi zadbać o to, by statusy publiczne nie były pustymi etykietami: każda zmiana powinna oznaczać realne działanie w procesie.
Raportowanie wskaźników reklamacyjnych
Raport z rejestru odpowiada na pytania, które zadaje kierownictwo: ile zgłoszeń wpłynęło i jak długo trwa ich rozpatrzenie. Ponieważ dane leżą w jednej bazie SQL Server, wskaźniki liczy się zapytaniem, bez eksportu do arkusza. Wyniki można wystawić w raporcie SSRS albo w widoku dla kierownika działu.
| Wskaźnik | Definicja | Jak go czytać |
|---|---|---|
| Liczba zgłoszeń wg kanału | liczba spraw zarejestrowanych w okresie | pokazuje, który kanał wymaga najwięcej pracy ręcznej |
| Czas do pierwszej odpowiedzi | różnica między datą wpływu a pierwszą odpowiedzią | porównuje się z przyjętym terminem odpowiedzi |
| Udział spraw przeterminowanych | sprawy zamknięte po terminie w stosunku do wszystkich zamkniętych | sygnał niedoboru obsady lub błędnego przydziału |
| Rozkład kodów przyczyn | liczba spraw według słownika przyczyn | wskazuje źródło problemów jakościowych |
Zapytanie o czas odpowiedzi
Poniższe zapytanie zestawia średni czas do pierwszej odpowiedzi w godzinach według kanału. Funkcję DATEDIFF opisuje dokumentacja DATEDIFF w T-SQL, a nazwy kolumn są przykładowe.
SELECT k.NazwaKanalu,
COUNT(*) AS LiczbaSpraw,
AVG(DATEDIFF(HOUR, r.DataWplywu, r.DataPierwszejOdpowiedzi)) AS SrGodzinDoOdpowiedzi
FROM dbo.Reklamacja AS r
JOIN dbo.KanalZgloszenia AS k ON k.KanalId = r.KanalId
WHERE r.DataWplywu >= DATEADD(MONTH, -3, SYSDATETIME())
GROUP BY k.NazwaKanalu
ORDER BY SrGodzinDoOdpowiedzi DESC;
Regularna analiza danych z systemu reklamacji online wspiera też decyzje zakupowe. Wysoki odsetek zgłoszeń dotyczących jednego dostawcy jest powodem do rozmowy z producentem, zanim problem dotknie kolejnych klientów. Zasady doboru terminów i raportów opisuje z kolei materiał o terminach i raportach w zarządzaniu reklamacjami. Rejestr zgłoszeń w formie samodzielnej aplikacji omawia strona o programie do rejestracji reklamacji. Opisy modułów Studio RMA.net znajdują się na stronie aplikacji Studio RMA.net.



