Poznaj system RMA - panel klienta B2B i zgłoszenie B2C bez logowania

System RMA - dwa sposoby dostępu klienta

System RMA jest aplikacją do obsługi reklamacji, z której mogą korzystać także klienci firmy. Zgłoszenie można złożyć o dowolnej porze, bez czekania na godziny pracy działu obsługi. Ogólny opis rozwiązania zawiera artykuł System RMA, a sam numer nadawany zgłoszeniu opisuje strona Return merchandise authorization - numer RMA.

Klienci firmowi i indywidualni mają różne potrzeby, więc system oferuje dwa wejścia. Klient B2B loguje się do panelu, w którym prowadzi wiele zgłoszeń naraz. Klient B2C zgłasza jedną sprawę bez zakładania konta, na podstawie numeru zamówienia.

Reguła: dostęp bez logowania obejmuje wyłącznie jedno zgłoszenie i jego status. Historia i dane innych spraw pozostają dostępne tylko po uwierzytelnieniu.

Panel klienta B2B i izolacja danych

Panel klienta B2B daje kontrahentowi wgląd w jego zgłoszenia bez pośrednictwa działu obsługi. Klient przegląda historię spraw, dodaje nowe zgłoszenia i sprawdza postęp każdej z nich. Dla firmy oznacza to mniej telefonów z prośbą o informację o stanie sprawy. Szerzej o takim rozwiązaniu pisze artykuł Moduł internetowy dla kontrahentów.

Najważniejszą regułą panelu jest izolacja danych. Kontrahent widzi wyłącznie własne zgłoszenia, a filtr po jego identyfikatorze stosuje serwer, nie przeglądarka. Zapytanie z parametrem chroni przed atakiem typu SQL injection, opisanym w dokumentacji Microsoft Learn.

EXEC sp_executesql
    N'SELECT numer_rma, status, data_zgloszenia
      FROM dbo.reklamacje
      WHERE kontrahent_id = @kontrahent
      ORDER BY data_zgloszenia DESC',
    N'@kontrahent int',
    @kontrahent = @id_z_sesji;

Identyfikator kontrahenta pochodzi z sesji użytkownika, a nie z adresu strony ani z pola formularza. Gdyby panel przyjmował go z parametru w adresie, zmiana jednej liczby wystarczyłaby do podejrzenia cudzych spraw. Nazwy tabeli i kolumn w przykładzie są przykładowe.

Role w panelu kontrahenta

W dużej firmie klienckiej ze zgłoszeniami pracuje kilka osób, więc panel rozróżnia role. Osoba składająca zgłoszenia nie musi widzieć decyzji finansowych, a osoba zatwierdzająca rozliczenia nie musi rejestrować spraw. Ograniczenie zakresu do potrzeb roli zmniejsza ryzyko pomyłek i ujawnienia danych.

Konto użytkownika jest w bazie przypisane do jednego kontrahenta, a rola do konta. Zmiana zatrudnienia u klienta oznacza zablokowanie konta, a nie usunięcie historii zgłoszeń, bo rekordy sprawy należą do kontrahenta, a nie do osoby, która je zarejestrowała. Administrator po stronie dostawcy systemu nie powinien tworzyć kont bez potwierdzenia od kontrahenta.

Zgłoszenie B2C bez logowania

Klient indywidualny rzadko zakłada konto tylko po to, żeby zgłosić jedną usterkę. Wymóg logowania odstrasza go i zmniejsza liczbę zgłoszeń doprowadzonych do końca. Formularz bez konta skraca drogę: klient podaje numer zamówienia i opis problemu, a system pobiera resztę danych z rejestru sprzedaży. Zagadnienia tej grupy klientów opisuje strona Reklamacje B2C.

Brak logowania nie oznacza braku kontroli. Formularz wymaga pary danych, którą zna tylko kupujący, na przykład numeru zamówienia i adresu e-mail podanego przy zakupie. Serwer ogranicza liczbę prób z jednego adresu IP w jednostce czasu, żeby uniemożliwić zgadywanie numerów zamówień.

Po wysłaniu formularza system nadaje numer RMA i przesyła go w potwierdzeniu. Klient może wydrukować numer i umieścić go na przesyłce z reklamowanym produktem. Kolejne kroki tego procesu opisuje artykuł Zgłoszenie reklamacji online. Samo potwierdzenie zawiera numer RMA, adres strony statusu i krótką instrukcję odesłania towaru. Instrukcja ogranicza liczbę paczek wysłanych bez oznaczenia, które trzeba potem ręcznie dopasowywać do zgłoszeń. Treść potwierdzenia firma może dostosować do swojego regulaminu, na przykład wskazując adres serwisu i dopuszczalny sposób pakowania.

Sprawdzanie statusu po numerze RMA

Klient sprawdza aktualny stan sprawy, wpisując numer RMA w odpowiednie pole w przeglądarce. Numer nie jest hasłem, więc odpowiedź zawiera tylko opis statusu przeznaczony dla klienta, bez danych osobowych i wewnętrznych komentarzy. Poniższy szkic pokazuje wywołanie po stronie przeglądarki, a adres i pola są przykładowe.

async function sprawdzStatus(numerRma, email) {
  const odp = await fetch('/api/status', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ numerRma, email })
  });
  if (!odp.ok) { return 'Nie znaleziono zgłoszenia.'; }
  return (await odp.json()).opisDlaKlienta;
}

Ten sam komunikat błędu pojawia się zarówno przy złym numerze, jak i przy niepasującym adresie e-mail. Dzięki temu odpowiedź nie zdradza, że dane zgłoszenie istnieje.

Ograniczanie nadużyć w formularzu bez konta

Formularz dostępny bez logowania jest widoczny dla każdego użytkownika Internetu, więc przyciąga także automaty wysyłające fałszywe zgłoszenia. Zabezpieczenia działają w kilku miejscach jednocześnie. Serwer sprawdza format numeru zamówienia i ogranicza rozmiar załączników, a osobno zlicza próby z jednego adresu.

Zliczanie prób wymaga prostej tabeli zdarzeń, do której serwer zapisuje adres i czas każdego wywołania. Zapytanie sprawdza, ile prób wykonano w ostatnich dziesięciu minutach, a przy przekroczeniu progu odrzuca kolejne żądanie.

SELECT COUNT(*) AS proby
FROM dbo.proby_formularza
WHERE adres_ip = @ip
  AND czas > DATEADD(minute, -10, SYSDATETIME());

Próg i okno czasowe są parametrami konfiguracji i zależą od ruchu w serwisie. Zbyt niski próg blokuje klientów za wspólnym adresem sieci firmowej, a zbyt wysoki nie chroni przed zgadywaniem numerów. Załączniki dodatkowo sprawdza się po stronie serwera, bo rozszerzenie pliku zgłoszone przez przeglądarkę nie dowodzi jego zawartości.

Powiadomienia o zmianie statusu

Klient nie musi sprawdzać statusu, jeśli system sam go informuje. Każda zmiana statusu dodaje wpis do kolejki powiadomień, a osobne zadanie wysyła wiadomości e-mail asynchronicznie. Rozdzielenie zapisu zgłoszenia od wysyłki chroni obsługę przed przestojem: awaria serwera pocztowego nie blokuje pracy nad sprawami, a niewysłane wiadomości czekają w kolejce.

CREATE TABLE dbo.powiadomienia (
    id          int IDENTITY(1,1) PRIMARY KEY,
    numer_rma   varchar(20)   NOT NULL,
    szablon     varchar(30)   NOT NULL,
    status      varchar(10)   NOT NULL DEFAULT 'oczekuje',
    proby       tinyint       NOT NULL DEFAULT 0,
    utworzono   datetime2     NOT NULL DEFAULT SYSDATETIME()
);

Zadanie cykliczne pobiera wpisy ze statusem „oczekuje”, wysyła wiadomość i zmienia status na „wysłano”. Przy błędzie zwiększa licznik prób i ponawia wysyłkę w następnym cyklu, a po przekroczeniu limitu oznacza wpis do ręcznej obsługi. Nazwy tabeli i kolumn są przykładowe.

Treść powiadomienia korzysta z opisu statusu przeznaczonego dla klienta, a nie z nazwy wewnętrznej. Klient B2B otrzymuje wiadomość z odsyłaczem do panelu, a klient B2C z numerem RMA i odsyłaczem do strony statusu. Wiadomość nie zawiera danych wrażliwych, bo poczta elektroniczna nie jest kanałem chronionym.

Numer RMA na przesyłce i przyjęcie w serwisie

Numer RMA łączy zgłoszenie klienta z fizyczną paczką. Klient umieszcza go na przesyłce w widocznym miejscu, a serwis lub magazyn identyfikuje towar po numerze. Bez numeru przesyłka wymaga ręcznego dopasowania do sprawy, co wydłuża obsługę. Zasady numeracji opisuje artykuł Numer RMA - co to jest i do czego służy.

Numer może mieć postać kodu kreskowego na etykiecie, którą klient drukuje z potwierdzenia. Serwis skanuje kod, system zmienia status na „przyjęte” i wyświetla dane zgłoszenia. Pracownik nie wpisuje niczego ręcznie, więc ryzyko pomyłki w numerze spada.

Wymagania techniczne rozwiązania przeglądarkowego

System RMA działa w przeglądarce, więc na stanowiskach nie instaluje się żadnego oprogramowania. Wystarczy przeglądarka w aktualnej wersji, zgodna ze standardami HTML5 i CSS3 oraz obsługująca JavaScript. Klient nie pobiera aplikacji, a firma nie wymienia programów na wielu komputerach po każdej aktualizacji. Szersze omówienie modelu webowego zawiera strona Aplikacja webowa.

Ponieważ system jest dostępny przez Internet i przechowuje dane klientów, zabezpieczenia są częścią projektu. Połączenie szyfruje protokół TLS, a użytkownicy panelu przechodzą uwierzytelnianie. Uprawnienia do zasobów nadaje się per rola, więc pracownik obsługi nie ma dostępu do ustawień systemu, a klient nie widzi cudzych spraw.

• Szyfrowanie połączenia - cały ruch między przeglądarką a serwerem odbywa się przez HTTPS.
• Uwierzytelnianie i role - konto potwierdza tożsamość, a rola określa widoczne dane i dozwolone operacje.

Firma wybiera między modelem abonamentowym a własnym serwerem. Wersja w modelu SaaS nie wymaga inwestycji w infrastrukturę, a wersja instalowana daje pełną kontrolę nad danymi i integracjami. Wariant abonamentowy opisuje strona Program RMA online.

Punkty serwisowe i komunikacja między działami

Punkty serwisowe są integralną częścią procesu reklamacyjnego. Stosowanie osobnego oprogramowania do weryfikowania napraw i komentarzy serwisu rozbija sprawę na dwa rejestry, z których żaden nie pokazuje pełnego obrazu. W jednym systemie serwis dopisuje wynik badania do tego samego zgłoszenia, które widzi dział obsługi.

Pracownicy dodają i edytują informacje przez Internet, więc zespoły w różnych lokalizacjach pracują na tych samych danych. Dostęp online eliminuje przesyłanie arkuszy między działami i wersje pliku, które rozjeżdżają się po kilku poprawkach.

Część zgłoszeń przychodzi e-mailem. System może odbierać wiadomości z dedykowanej skrzynki, tworzyć z nich zgłoszenia i przypisywać je pracownikom, a odpowiedzi klienta dołączać do istniejącej sprawy. Wsparcie decyzji zapewnia też analiza treści zgłoszeń, opisana w artykule AI analizuje zgłoszenia reklamacyjne. Rekomendacja pozostaje podpowiedzią dla pracownika, a nie decyzją.

Przykład sklepu obuwniczego

System reklamacyjny dla sklepu z butami powinien przyjmować zgłoszenia ze strony internetowej i z aplikacji mobilnej. Typowe sprawy dotyczą wad materiałowych i rozklejonej podeszwy, a proces od zgłoszenia przez weryfikację do rozstrzygnięcia przebiega online. Klient widzi status, a sklep raportuje liczbę i rodzaj zgłoszeń, co pomaga wychwycić powtarzające się wady partii towaru. Podobny przypadek opisuje artykuł Program do reklamacji w sklepie.

Co sprawdzić w demo systemu RMA

Demonstracja na danych przykładowych pozwala ocenić system bez instalacji. Rozwiązanie webowe umożliwia rejestrację zgłoszenia reklamacyjnego oraz przyjęcie sprzętu do serwisu, a po zapisie nadaje numer RMA, który porządkuje ewidencję statusów. Demo Studio RMA.net jest dostępne pod adresem demo systemu reklamacji, a opis aplikacji znajduje się na stronie Studio RMA.net.

Test warto oprzeć na scenariuszach z własnego procesu, a nie na przypadkowym klikaniu. Poniższa lista zawiera scenariusze, które ujawniają różnice między systemami.

• Zgłoszenie bez logowania - złożenie sprawy jako klient indywidualny i sprawdzenie, jakie dane system wymaga.
• Panel kontrahenta - zalogowanie i sprawdzenie, czy widoczne są tylko własne zgłoszenia.
• Status po numerze RMA - odczyt statusu i ocena, czy opis jest zrozumiały dla klienta.
• Przyjęcie w serwisie - zeskanowanie numeru z etykiety i zmiana statusu.

Wyniki testu warto zapisać w jednej tabeli porównawczej z tymi samymi kryteriami dla każdego oglądanego systemu. Wtedy różnice widać w liczbach i obserwacjach, a nie w ogólnym wrażeniu z prezentacji. Do testu dobrze jest zaprosić osobę z działu obsługi i osobę z serwisu, bo każda z nich zauważy inne braki. Podstawowy przegląd programów tej klasy zawiera artykuł Oprogramowanie do obsługi reklamacji.