Program RMA on-line - portal klienta i formularz zgłoszeniowy

Program RMA on-line - jak działa portal klienta

Program RMA on-line składa się z dwóch powierzchni pracy. Pierwszą jest portal klienta, w którym kupujący składa zgłoszenie i sprawdza jego status. Drugą jest panel serwisu, w którym pracownicy przyjmują sprawy i dopisują notatki, a także zmieniają postęp naprawy. Obie części korzystają z tej samej bazy danych, więc klient widzi to, co zapisał serwis, z opóźnieniem liczonym w sekundach. Program bywa oferowany także pod nazwą Reklamacje.net.

Określenie program do reklamacji obejmuje w praktyce właśnie ten układ: formularz dla klienta oraz kolejkę spraw dla obsługi. Zakres samej obsługi sprawy, od rejestracji do rozliczenia, opisuje artykuł o oprogramowaniu do obsługi reklamacji. Tutaj opisany jest widok klienta i mechanizmy, które go zasilają.

Formularz zgłoszeniowy w programie do reklamacji

Formularz decyduje o jakości całej sprawy, bo braki w zgłoszeniu wracają jako dopytywanie klienta i wydłużają rozpatrzenie. Zapisane zgłoszenie dostaje automatycznie unikalny numer, który klient widzi na ekranie potwierdzenia i w wiadomości e-mail. Szczegółowe zasady tego identyfikatora omawia osobno artykuł numer RMA, a proces po stronie klienta ilustruje strona zgłoszenie reklamacji online.

Pola formularza i ich walidacja

Każde pole ma cel procesowy, a reguła walidacji wynika z tego, do czego dana informacja posłuży w dalszych krokach. Numer dokumentu sprzedaży pozwala odnaleźć produkt w kartotece, a opis usterki trafia do oceny technicznej.

Formularz powinien zbierać dane kontaktowe klienta oraz numer zamówienia albo numer seryjny produktu. Kolejne pola to opis usterki i preferowany sposób rekompensaty. Studio RMA.net pozwala projektować własne pola i dodawać checklisty, a także załączniki ze zdjęciami, więc zakres można dopasować do produktów danej firmy. Wzorzec działania opisuje także strona formularz reklamacyjny.

Wysyłka formularza z przeglądarki

Przeglądarka wysyła dane asynchronicznie, bez przeładowania strony. Skrypt przechwytuje zdarzenie submit, buduje obiekt FormData i wywołuje punkt końcowy API. Po błędzie walidacji serwer zwraca listę pól z komunikatami, a po sukcesie numer sprawy. Podstawy interfejsu opisuje dokumentacja Fetch API.

const formularz = document.querySelector('#formularz-reklamacji');

formularz.addEventListener('submit', async (zdarzenie) => {
    zdarzenie.preventDefault();
    const odpowiedz = await fetch('/api/reklamacje', {
        method: 'POST',
        body: new FormData(formularz)
    });
    const wynik = await odpowiedz.json();
    if (!odpowiedz.ok) {
        wynik.bledy.forEach((b) => {
            document.querySelector('#blad-' + b.pole).textContent = b.komunikat;
        });
        return;
    }
    document.querySelector('#potwierdzenie').textContent = 'Numer zgłoszenia: ' + wynik.numer;
});

Reguła: walidacja w przeglądarce poprawia wygodę, ale wiążąca jest wyłącznie walidacja na serwerze, bo żądanie można wysłać z pominięciem formularza.

Rejestracja zgłoszenia w bazie

Punkt końcowy API wywołuje procedurę składowaną, która nadaje numer i zapisuje sprawę w jednej transakcji. Numer pochodzi z obiektu SEQUENCE, więc równoległe zgłoszenia nie blokują się nawzajem. Poniższy fragment jest przykładem, a nie kopią procedury produktu.

CREATE PROCEDURE dbo.RejestrujZgloszenie
    @Email             NVARCHAR(200),
    @DokumentSprzedazy VARCHAR(40),
    @Opis              NVARCHAR(2000),
    @Numer             VARCHAR(20) OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;

    DECLARE @n INT = NEXT VALUE FOR dbo.SeqNumerRma;
    SET @Numer = CONCAT('RMA/', YEAR(SYSUTCDATETIME()), '/', RIGHT(CONCAT('000000', @n), 6));

    INSERT INTO dbo.Reklamacja (NumerRma, KlientId, DokumentSprzedazy, StatusId, OpisUsterki)
    SELECT @Numer, k.KlientId, @DokumentSprzedazy, 1, @Opis
      FROM dbo.Klient AS k
     WHERE k.Email = @Email;

    IF @@ROWCOUNT = 0
        THROW 50002, N'Nie znaleziono konta klienta.', 1;
END;

Załączniki ze zdjęciami usterki

Zdjęcia skracają ocenę zasadności, ponieważ serwis widzi stan towaru, zanim ten trafi do magazynu. Serwer sprawdza rozszerzenie pliku, jego rzeczywisty typ odczytany z nagłówka oraz maksymalny rozmiar. Sam plik zapisuje się poza tabelą, a w bazie zostaje ścieżka pliku i suma kontrolna, a osobne pole wiąże plik ze sprawą. Suma kontrolna wykrywa uszkodzony lub zmieniony plik, a powiązanie pozwala pokazać zdjęcia w karcie sprawy bez przeszukiwania katalogu.

Statusy widoczne dla klienta w portalu

Klient nie potrzebuje wiedzieć, że sprawa czeka na wolnego serwisanta, ale potrzebuje wiedzieć, czy jego zgłoszenie zostało przyjęte i kiedy ma się spodziewać decyzji. Portal pokazuje więc uproszczoną wersję statusów wewnętrznych. Mapowanie zapisuje się w słowniku, żeby zmiana nazwy statusu wewnętrznego nie wymagała zmian w kodzie portalu.

Dostęp do sprawy wymaga uwierzytelnienia. Moduł zgłoszeń przez portal działa na podstawie adresu e-mail i generowanego hasła, a jego sekcje obejmują sprawdzanie statusu zgłoszenia i rejestrację nowej reklamacji. Osobną funkcją jest zakładanie konta dostępowego dla dystrybutora, który zgłasza sprawy w imieniu wielu odbiorców. Ten wariant opisuje strona o reklamacjach online.

Reguła: numer sprawy sam nie wystarcza do wglądu w dane, ponieważ numery są kolejne i łatwo je odgadnąć.

Oś czasu sprawy w portalu

Oprócz bieżącego statusu klient widzi kolejne zdarzenia w porządku chronologicznym. Oś czasu powstaje z historii zmian, a słownik mapowania decyduje, które przejścia są dla klienta widoczne. Przejścia czysto wewnętrzne, jak przekazanie sprawy między serwisantami, w ogóle nie trafiają do wyniku zapytania.

SELECT h.Czas, m.NazwaDlaKlienta
  FROM dbo.ReklamacjaHistoria AS h
  JOIN dbo.MapaStatusowKlienta AS m ON m.StatusId = h.StatusDo
 WHERE h.ReklamacjaId = @ReklamacjaId
   AND m.Widoczny = 1
 ORDER BY h.Czas;

Powiadomienia o zmianie statusu

Klient oczekuje wiadomości w chwili, gdy sprawa się przesuwa, więc powiadomienia wynikają ze zdarzeń w procesie. Zmiana statusu dopisuje wiersz do kolejki powiadomień w tej samej transakcji, co zmiana sprawy. Osobny proces odczytuje kolejkę i wysyła wiadomości e-mail albo SMS. Rozdzielenie zapisu od wysyłki chroni sprawę przed skutkami awarii serwera pocztowego, bo niewysłana wiadomość czeka w kolejce zamiast blokować transakcję.

Kolejka powiadomień i blokady

Kilka procesów wysyłających może odczytywać kolejkę równolegle. Podpowiedzi UPDLOCK i READPAST sprawiają, że każdy proces pobiera inne wiersze: pierwsza blokuje wiersz do aktualizacji, a druga pomija wiersze zablokowane przez sąsiada. Zamiast czekać na zwolnienie blokady, proces bierze kolejne wolne wiadomości.

WITH nastepne AS (
    SELECT TOP (10) *
      FROM dbo.PowiadomienieKolejka WITH (UPDLOCK, READPAST, ROWLOCK)
     WHERE Stan = 0
     ORDER BY PowiadomienieId
)
UPDATE nastepne
   SET Stan = 1, Proba = Proba + 1
OUTPUT inserted.PowiadomienieId, inserted.Adres, inserted.Temat, inserted.Tresc;

Po udanej wysyłce proces ustawia stan 2, a po błędzie wraca do stanu 0 z zapisanym numerem próby. Powyżej ustalonej liczby prób wiadomość trafia do kolejki błędów i pojawia się na liście dla administratora. Pocztę z poziomu bazy można wysyłać procedurą opisaną w dokumentacji sp_send_dbmail, choć wdrożenia webowe częściej korzystają z usługi aplikacyjnej.

Szablony wiadomości do klienta

Treść wiadomości powstaje z szablonu z parametrami, takimi jak numer sprawy i nazwa statusu, a nie z tekstu wpisywanego ręcznie. Szablon jest przypisany do przejścia w procesie, więc zmiana treści nie wymaga zmiany kodu. Wiadomość nie zawiera danych wrażliwych ani załączników, tylko odsyłacz do portalu, gdzie dostęp chroni logowanie. Taki układ ogranicza skutki błędnie zaadresowanej poczty.

Bezpieczeństwo dostępu do portalu klienta

Portal udostępnia dane osobowe i dokumenty sprzedaży, więc jego zabezpieczenie jest częścią projektu, a nie dodatkiem. Podstawowe mechanizmy są znane z każdej aplikacji webowej. Hasła zapisuje się jako skróty z solą, a nie w postaci jawnej, liczbę nieudanych prób logowania ogranicza się w czasie, a całą komunikację prowadzi się przez HTTPS. Nowe konto otrzymuje hasło wygenerowane przez system.

Najczęstszy błąd dotyczy autoryzacji, a nie uwierzytelniania. Zalogowany klient nie może zobaczyć cudzej sprawy przez zmianę numeru w adresie strony. Identyfikator klienta pochodzi więc z sesji lub tokena, a nie z parametru żądania, a zapytanie zawsze zawiera warunek na właściciela sprawy. Odpowiedź dla cudzej sprawy jest taka sama jak dla nieistniejącej, żeby nie ujawniać, które numery są w użyciu.

[HttpGet("api/reklamacje/{numer}")]
public IActionResult Pobierz(string numer)
{
    var klientId = int.Parse(User.FindFirst("klient_id").Value);

    var sprawa = _db.Reklamacje
        .SingleOrDefault(r => r.NumerRma == numer && r.KlientId == klientId);

    return sprawa == null ? NotFound() : Ok(sprawa);
}

Załączniki i notatki wewnętrzne podlegają osobnym regułom. Notatki oznaczone jako wewnętrzne nigdy nie trafiają do odpowiedzi API dla klienta, a filtr działa w zapytaniu, nie w widoku. Dzięki temu pomyłka w szablonie strony nie ujawni uwag serwisu.

Praca serwisu u klienta i ewidencja napraw

Program dostępny on-line zmienia sposób pracy serwisów terenowych. Zamiast zapisywać zgłoszenie na papierze i przepisywać je w biurze, serwisant rejestruje sprawę na miejscu z telefonu lub tabletu i od razu spisuje protokół naprawy w obecności klienta. Zgłoszenia trafiają do rejestru, który obejmuje naprawy oraz sprzęt klientów, a także rozliczenia między serwisem a odbiorcami. Przebieg naprawy koordynuje się notatkami różnych typów oraz statusem i postępem.

Reguła: zestaw statusów naprawy, od przyjęcia przez diagnostykę do gotowości do odbioru, musi być jednolity w całym zespole, bo raporty liczą czas w każdym statusie.

Ta sama zasada dotyczy zespołów rozproszonych. Firma z kilkoma oddziałami serwisowymi bez wspólnej bazy zgłoszeń duplikuje pracę i przekazuje klientom rozbieżne informacje. Wspólny rejestr pozwala kierownikowi porównywać obciążenie oddziałów, a reguły przydziału kierują sprawę do wolnego serwisanta. Osobne omówienie aplikacji mobilnej znajduje się na stronie aplikacja obsługi reklamacji.

Protokół naprawy spisywany u klienta

Protokół powstaje w miejscu, w którym stoi urządzenie, więc dane są kompletne i nie wymagają późniejszego uzupełniania z pamięci. Formularz protokołu zawiera cztery grupy informacji:

• Identyfikacja urządzenia - numer seryjny i model urządzenia oraz jego lokalizacja, którą system kojarzy z kartoteką klienta.
• Opis stwierdzonej usterki - wpis technika uzupełniony zdjęciami zrobionymi na miejscu.
• Zakres wykonanych prac - czynności i wymienione części, które system przenosi do rozliczenia.
• Potwierdzenie klienta - podpis lub akceptacja elektroniczna zapisane razem z datą i autorem.

Po zapisaniu protokołu sprawa przechodzi do statusu gotowej do rozliczenia, a klient widzi zmianę w portalu. Uproszczony przebieg całej sprawy pokazuje strona aplikacja RMA online.

Kryteria wyboru programu RMA on-line

Wybór narzędzia opiera się na mierzalnych kryteriach, które przekładają się na codzienną pracę zespołu. Firmy zmieniające starsze oprogramowanie zgłaszają zwykle te same braki, więc test z demonstracją najlepiej zacząć od nich.

Typowe braki starszych rozwiązań da się sprowadzić do czterech pozycji:

• Brak przyjmowania zgłoszeń przez stronę www - klient musi dzwonić lub pisać, a pracownik przepisuje dane ręcznie.
• Uboga lista statusów - sprawy nie da się opisać dokładniej niż otwarta i zamknięta.
• Brak planowania wizyt - serwis nie prowadzi kalendarza wyjazdów do klientów.
• Priorytety bez SLA - kolejkę porządkuje data wpływu, a nie termin odpowiedzi.

Terminy odpowiedzi i odpowiedzialność wobec klienta opisuje artykuł zarządzanie reklamacjami w firmie handlowej, a znaczenie numeru w zwrotach towaru materiał o return merchandise authorization. Wersję demonstracyjną Studio RMA.net można obejrzeć w serwisie demo reklamacji, a zestawienie argumentów za wdrożeniem zawiera artykuł 10 powodów, aby wdrożyć system RMA online.