Reklamacje online - kanały zgłoszeń, formularz i wdrożenie

Reklamacje online - kanały zgłoszeń

Zgłoszenie złożone przez przeglądarkę trafia do bazy jako sprawa z numerem RMA. System wiąże ją z klientem i dokumentem sprzedaży. Numer RMA (Return Merchandise Authorization) identyfikuje zarówno wpis w systemie, jak i fizyczną przesyłkę z towarem, więc pracownik magazynu po otwarciu paczki od razu wie, której sprawy ona dotyczy. Klient niczego nie instaluje. Potrzebuje adresu strony i numeru dokumentu zakupu.

Formularz WWW jest tylko jednym z kanałów, a wszystkie muszą prowadzić do tej samej kolejki. Gdy jedna część zgłoszeń leży w skrzynce pocztowej, a druga w arkuszu, nie da się porównać ani statusów, ani terminów. System rejestruje więc zgłoszenie bez względu na kanał i zapisuje, skąd ono przyszło.

Zgłoszenia od dystrybutorów wymagają osobnej ścieżki. Firma loguje się na konto założone na jej adres e-mail. Tam rejestruje reklamację i sprawdza jej status. Szczegóły takiego rozwiązania opisuje tekst o portalu klienta w programie RMA on-line, a zasady nadawania identyfikatora wyjaśnia artykuł o numerze RMA.

Formularz reklamacyjny i walidacja danych

Formularz decyduje o tym, ile pracy wykona człowiek, zanim sprawa ruszy dalej. Każde brakujące pole oznacza telefon do klienta, dlatego pola obowiązkowe dobiera się do decyzji, którą dział obsługi musi podjąć. Pełniejszy opis samego procesu przyjęcia zgłoszenia znajduje się na stronie o zgłoszeniu reklamacji online.

Pola obowiązkowe

Minimum, które pozwala ocenić zasadność roszczenia, obejmuje cztery grupy danych.

• Dokument zakupu - numer faktury lub paragonu, na podstawie którego system sprawdza datę sprzedaży i okres rękojmi albo gwarancji.
• Identyfikacja towaru - kod z kartoteki oraz numer seryjny, jeśli towar jest serwisowany indywidualnie.
• Opis niezgodności - tekst o minimalnej długości, który odsiewa wpisy w rodzaju „nie działa”.
• Oczekiwany sposób załatwienia - pole wyboru, a nie wolny tekst, bo od niego zależy dalszy obieg dokumentów.

Zdjęcia i nagranie wady pozostają polami opcjonalnymi. Ich obecność skraca diagnostykę wstępną, ale wymuszanie załącznika zniechęca klientów, którzy zgłaszają sprawę z telefonu.

Załączniki i limity

Plik dołączony do zgłoszenia jest danymi z zewnątrz i wymaga takiej samej ostrożności jak pole tekstowe. Serwer sprawdza rozmiar oraz rzeczywisty typ pliku, a nie samo rozszerzenie z nazwy. Nazwę nadaje system, żeby nie przenosić do dysku znaków sterujących ani ścieżek z komputera klienta. Pliki trzyma się poza katalogiem publicznym witryny, a dostęp do nich odbywa się przez akcję sprawdzającą uprawnienia użytkownika.

Konsument czy przedsiębiorca

Formularz powinien odróżniać konsumenta od firmy, ponieważ obie grupy mają inne uprawnienia. Według polskiego prawa konsumentem jest osoba fizyczna, która nabywa towar lub usługę w celu niezwiązanym bezpośrednio z jej działalnością gospodarczą lub zawodową. Ogólne informacje o prawach kupujących zbiera portal konsument.gov.pl, a konkretne terminy i podstawy roszczeń warto zapisać w konfiguracji systemu na podstawie aktualnych przepisów, a nie w kodzie.

Walidacja po stronie serwera

Sprawdzanie pól w przeglądarce (JavaScript, jQuery) poprawia komfort wypełniania, ale nie chroni bazy, bo żądanie HTTP można wysłać z pominięciem formularza. Reguły muszą więc działać także na serwerze. W aplikacji ASP.NET robi się to atrybutami modelu, a ostatnią linią obrony są ograniczenia w tabeli SQL Server. Poniższy model jest przykładowy.

public class ZgloszenieReklamacji
{
    [Required, StringLength(40)]
    public string NrDokumentu { get; set; }

    [Required, StringLength(60)]
    public string KodTowaru { get; set; }

    [Required, StringLength(2000, MinimumLength = 20)]
    public string OpisUsterki { get; set; }

    [EmailAddress]
    public string Email { get; set; }
}

Reguła: pole obowiązkowe w formularzu musi być obowiązkowe także w bazie, w przeciwnym razie import albo interfejs API zapisze rekord, którego formularz by nie przyjął.

Kolumna z numerem dokumentu ma ten sam typ i długość co pole modelu, a kolumna opisu dostaje ograniczenie CHECK na minimalną liczbę znaków. Platformę, na której działa taki formularz, opisuje przegląd ASP.NET w dokumentacji Microsoft Learn.

Kolejka spraw i statusy po rejestracji

Po zapisie sprawa trafia do kolejki nowych zgłoszeń, z której pracownik przejmuje ją do realizacji. Wersja demonstracyjna Studio RMA.net dzieli sprawy na listy według statusu, od nowych po zamknięte. Nad tabelą działa pasek poleceń, a menu wydruku oferuje między innymi oświadczenie dla klienta i szczegóły reklamacji. Poniższy zrzut pochodzi z tej wersji i zawiera dane przykładowe.

Ten sam zestaw statusów widać w widoku kalendarza, gdzie każdy stan ma własny kolor. Znaczenia stanów opisano poniżej ogólnie, bo konkretny obieg zależy od konfiguracji wdrożenia.

Reguła: zmiana statusu zapisuje autora i czas, a status nie jest wolnym polem tekstowym, tylko przejściem dozwolonym z bieżącego stanu.

Taka konstrukcja pozwala potem policzyć, ile czasu sprawy spędzają w każdym stanie. Sposób budowy raportów terminowości opisuje strona zarządzanie reklamacjami - terminy i raporty.

Każda nowa sprawa dostaje termin obliczany z daty przyjęcia i liczby dni zapisanej w konfiguracji. Wersja demonstracyjna oznacza ten termin kolorem, więc pracownik widzi na liście, które zgłoszenia wymagają reakcji w pierwszej kolejności. Wartość terminu nie powinna być wpisana na stałe w kodzie, ponieważ różni się między konsumentami a firmami i zmienia się wraz z przepisami.

Numer RMA i powiadomienia dla klienta

Numer RMA nadaje system w chwili zapisu, a klient dostaje go w potwierdzeniu na ekranie i w wiadomości. Przesyłkę z towarem oznacza się etykietą z tym numerem, najczęściej w postaci kodu kreskowego lub kodu QR generowanego przez system. Pracownik przyjmujący paczkę skanuje etykietę i otwiera właściwą sprawę bez ręcznego wyszukiwania. Zasady doboru symboliki opisuje artykuł o kodach kreskowych w magazynie.

Powiadomienia idą e-mailem lub SMS-em i dotyczą przejść między statusami. Tabela pokazuje zdarzenia, przy których komunikat ma sens.

Komunikaty warto oprzeć o kolejkę w bazie, a nie wysyłać ich w trakcie zapisu zmiany statusu. Wysyłka poczty może się opóźnić albo zakończyć błędem, a transakcja zmiany statusu nie powinna na nią czekać. Tabela wychodzących komunikatów z licznikiem prób pozwala ponowić wysyłkę bez ryzyka duplikatu. Mechanizm poczty wbudowany w SQL Server opisuje dokumentacja Database Mail. Struktura poniżej jest przykładowa.

CREATE TABLE dbo.KolejkaPowiadomien (
    Id         INT IDENTITY(1,1) PRIMARY KEY,
    IdSprawy   INT            NOT NULL,
    Kanal      VARCHAR(5)     NOT NULL,  -- EMAIL lub SMS
    Tresc      NVARCHAR(1000) NOT NULL,
    LiczbaProb TINYINT        NOT NULL DEFAULT 0,
    WyslanoO   DATETIME2(0)   NULL
);

-- zadanie SQL Agent wybiera niewysłane wpisy
SELECT TOP (50) Id, IdSprawy, Kanal, Tresc
FROM dbo.KolejkaPowiadomien
WHERE WyslanoO IS NULL AND LiczbaProb < 5
ORDER BY Id;

Integracja formularza z ERP i sklepem

Formularz na stronie firmy nie musi być częścią systemu RMA. Sklep internetowy może wysyłać zgłoszenie do systemu przez API REST, które według opisu producenta Studio RMA.net udostępnia do integracji z ERP oraz ze sklepem internetowym. Klient zostaje wtedy na stronie sprzedawcy, a dane trafiają do tej samej bazy, co zgłoszenia z formularza systemowego. Ogólne zasady łączenia takich aplikacji opisuje tekst o integrowaniu aplikacji webowych.

Fragment JavaScript poniżej pokazuje wywołanie asynchroniczne. Adres i format danych są przykładowe, a odpowiedź zawiera nadany numer RMA, który sklep pokazuje klientowi bez przeładowania strony.

async function wyslijZgloszenie(dane) {
  const odp = await fetch('/api/zgloszenia', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(dane)
  });
  if (!odp.ok) {
    throw new Error('Rejestracja nie powiodła się: ' + odp.status);
  }
  return odp.json(); // odpowiedź z numerem RMA
}

Integracja z CRM porządkuje historię kontaktów, a dane o klientach opisuje osobno strona o aplikacjach CRM. Zwrot przyjmowany na magazyn generuje dokument, którego zasady opisują dokumenty magazynowe.

Ochrona formularza przed nadużyciami

Publiczny formularz przyciąga automaty, które wysyłają setki fałszywych zgłoszeń, więc bez zabezpieczeń kolejka szybko traci wartość. Podstawą jest token przeciw fałszowaniu żądań (w ASP.NET mechanizm antiforgery), który wiąże wysłany formularz z sesją użytkownika. Uzupełnia go ograniczenie liczby żądań z jednego adresu w krótkim czasie oraz pole pułapka, którego człowiek nie widzi, a automat wypełnia.

Zgłoszenie odrzucone przez zabezpieczenie nie powinno znikać bez śladu. Dziennik zdarzeń zapisuje przyczynę odrzucenia i adres źródłowy, co pozwala odróżnić atak od pomyłki klienta i dostroić limity bez otwierania formularza na oścież.

Wdrożenie reklamacji online w firmie

Wdrożenie składa się z etapów, które da się sprawdzić osobnym kryterium zakończenia. Poniższe zestawienie porządkuje je w kolejności prac.

Scenariusze testowe

Testy poprawnej ścieżki nie wystarczą, bo błędy ujawniają się na wyjątkach. W scenariuszach awaryjnych warto sprawdzić cztery sytuacje.

• Duplikat zgłoszenia - ten sam dokument i towar wysłane dwukrotnie w ciągu minuty, co nie powinno utworzyć dwóch spraw.
• Brak załącznika - formularz z pustym polem opcjonalnym musi zapisać sprawę bez błędu.
• Dokument spoza kartoteki - zgłoszenie towaru, którego nie ma w ERP, trafia do kolejki ręcznej weryfikacji.
• Awaria wysyłki - niedostępny serwer poczty zostawia komunikat w kolejce i nie blokuje zmiany statusu.

Pilotaż na jednym oddziale ujawnia rozbieżności między procedurą na papierze a praktyką pracowników, zanim system obejmie całą firmę. Wersję demonstracyjną można sprawdzić w serwisie demo reklamacji, a opis modułów znajduje się na stronie Studio RMA.net. Rozwiązanie działające w przeglądarce, bez instalacji na stanowiskach, opisuje także tekst o systemie RMA online, a szersze ujęcie techniczne zawiera strona o aplikacji webowej.

Przy przejściu z arkusza na system trzeba zdecydować, co zrobić ze starymi zgłoszeniami. Otwarte sprawy przenosi się importem z mapowaniem starych statusów na nowe i sprawdzeniem, czy numer dokumentu występuje w ERP. Sprawy zamknięte zwykle wystarczy zostawić w archiwum, o ile działowi jakości nie są potrzebne do analizy trendów.

Dane klienta i uprawnienia w systemie online

Formularz online zbiera dane osobowe, więc dostęp do spraw powinien wynikać z roli. Klient widzi wyłącznie własne zgłoszenia, pracownik obsługi widzi kolejkę przypisaną do jego działu, a administrator zarządza słownikami i uprawnieniami. Zmiany w sprawie zostają w historii razem z autorem, co ułatwia wyjaśnianie sporów.

Zakres zbieranych danych warto ograniczyć do tego, co potrzebne do rozpatrzenia sprawy. Adres wysyłkowy jest potrzebny dopiero wtedy, gdy towar wraca do klienta, a numer telefonu wystarcza jeden. Okres przechowywania zamkniętych spraw zapisuje się jako parametr, a po jego upływie dane osobowe są anonimizowane, natomiast dane techniczne o towarze i przyczynie usterki zostają do analiz jakościowych.

Połączenie z formularzem powinno być szyfrowane (HTTPS), a kopie zapasowe bazy powinny być wykonywane według harmonogramu i sprawdzane przez odtworzenie. Proces reklamacyjny w szerszym ujęciu, z podziałem odpowiedzialności między działy, opisuje strona reklamacje aplikacja.