Oprogramowanie do obsługi reklamacji - proces sprawy i model danych

Program do reklamacji a system do obsługi reklamacji - zakres pojęć

Oprogramowanie do obsługi reklamacji rejestruje sprawę, pilnuje jej statusu i przechowuje dokumenty, które powstają w trakcie rozpatrywania. Na rynku ta sama funkcja występuje pod kilkoma nazwami, więc przy wyborze narzędzia trzeba najpierw ustalić, czego dotyczy zapytanie. Program do reklamacji bywa prostą aplikacją z rejestrem zgłoszeń, a system do obsługi reklamacji zwykle obejmuje jeszcze obieg zadań między działami oraz integracje z innymi systemami firmy.

Ten tekst opisuje warstwę wspólną dla wszystkich wariantów: przebieg sprawy oraz sposób, w jaki dane sprawy układa się w bazie SQL Server. Osobne opracowania dotyczą portalu klienta i formularza zgłoszeniowego oraz terminów i odpowiedzialności w firmie handlowej. Szersze omówienie samej aplikacji znajduje się na stronie program do obsługi reklamacji.

Oprogramowanie do obsługi reklamacji - etapy sprawy

Sprawa reklamacyjna przechodzi przez stałą sekwencję etapów, a oprogramowanie pilnuje, żeby żaden z nich nie został pominięty. Sekwencja jest taka sama niezależnie od branży, różnią się natomiast pola formularzy i osoby odpowiedzialne za decyzję.

Zgłoszenie i rejestracja

Zgłoszenie trafia do systemu przez formularz online albo zostaje wprowadzone przez pracownika obsługi. W chwili zapisu system nadaje sprawie unikalny numer i wiąże ją z klientem. Zapisuje też dokument sprzedaży, a osobno opis usterki. Numer pełni rolę klucza biznesowego: pracownik i klient posługują się tym samym identyfikatorem. Zasady jego nadawania opisuje osobno artykuł numer RMA.

Weryfikacja i decyzja

Na etapie oceny osoba uprawniona sprawdza kompletność zgłoszenia oraz zasadność roszczenia w świetle gwarancji lub rękojmi. Wynikiem jest decyzja: uznanie z określeniem sposobu załatwienia albo odmowa. Decyzja jest osobnym faktem w danych, a nie tylko zmianą statusu, ponieważ późniejsze raporty muszą odróżnić sprawy uznane od odrzuconych.

Reguła: decyzja wymaga wpisu autora i uzasadnienia, a datę nadaje system, który nie pozwala zamknąć sprawy bez decyzji.

Realizacja i rozliczenie

Po decyzji uruchamiane są zadania wykonawcze, na przykład przyjęcie towaru do serwisu albo wysyłka towaru zastępczego. Rozliczenie zamyka sprawę finansowo i magazynowo, więc przy integracji z ERP albo systemem magazynowym to na tym etapie powstają dokumenty korygujące i przyjęcia zwrotu.

Zamknięcie i analiza przyczyn

Zamknięcie sprawy wymaga potwierdzenia, że klient otrzymał rozstrzygnięcie, a dokumenty zostały rozliczone. Ostatni krok ma także wartość analityczną: przy zamknięciu operator wskazuje kod przyczyny z ustalonego słownika, na przykład wada fabryczna albo uszkodzenie w transporcie. Kod przyczyny zapisany w strukturze danych pozwala później grupować sprawy i wskazywać powtarzające się źródła problemów, a pole tekstu wolnego takich zestawień nie umożliwia.

Statusy sprawy i dozwolone przejścia

Status opisuje, w którym miejscu procesu znajduje się sprawa, a lista dozwolonych przejść chroni przed skrótami. Przykładowy zestaw obejmuje siedem statusów, od nowej do zamkniętej. Cztery pierwsze opisują ocenę zgłoszenia, a trzy ostatnie wykonanie decyzji. Konkretne wdrożenie może dodać własne statusy, na przykład oczekiwanie na dostawę części.

Przejścia w tej tabeli tworzą graf skierowany, który w bazie zapisuje się jako słownik statusów i tabelę dozwolonych par status źródłowy - status docelowy. Aplikacja przed zmianą sprawdza, czy para istnieje, a klient widzi tylko uproszczoną wersję statusów. Parametry, które warto zapisać przy każdej zmianie:

• Status źródłowy i docelowy - obie wartości, żeby historię dało się odtworzyć bez porównywania kolejnych rekordów.
• Autor zmiany - konto użytkownika albo nazwa procesu automatycznego, który wykonał przejście.
• Czas zdarzenia - znacznik w UTC, z którego liczy się czas przebywania sprawy w każdym statusie.
• Notatka - krótkie uzasadnienie, obowiązkowe przy odmowie i przy cofnięciu do wcześniejszego etapu.

Terminy i eskalacja opóźnień

Termin odpowiedzi zapisuje się w nagłówku sprawy w chwili rejestracji, a system porównuje go z bieżącą datą. Sprawy po terminie pojawiają się na liście kierownika i mogą wywołać powiadomienie do przełożonego. Zapytanie wybierające zaległe sprawy korzysta z funkcji DATEDIFF opisanej w dokumentacji T-SQL.

SELECT r.NumerRma, r.TerminOdpowiedzi, s.Nazwa AS Status,
       DATEDIFF(DAY, r.TerminOdpowiedzi, CAST(SYSUTCDATETIME() AS DATE)) AS DniPoTerminie
  FROM dbo.Reklamacja AS r
  JOIN dbo.StatusReklamacji AS s ON s.StatusId = r.StatusId
 WHERE s.CzyKoncowy = 0
   AND r.TerminOdpowiedzi < CAST(SYSUTCDATETIME() AS DATE)
 ORDER BY DniPoTerminie DESC;

Zapytanie uruchamia cyklicznie zadanie SQL Server Agent albo usługa aplikacyjna. Wersja Express nie zawiera SQL Server Agent, więc przy takim wdrożeniu harmonogram przejmuje proces po stronie aplikacji. Terminy ustawowe i wewnętrzne cele czasowe omawia osobno artykuł o zarządzaniu reklamacjami w firmie handlowej.

Model danych sprawy w SQL Server

Studio RMA.net przechowuje dane w jednej bazie MS SQL Server, a dostęp do informacji jest ograniczony rolami i prawami użytkowników. Poniższe fragmenty nie pokazują rzeczywistego schematu produktu, tylko przykładowy model. Ilustruje on dwa mechanizmy: historię zdarzeń i kontrolę współbieżności. Dokumentacja składni znajduje się w opisie instrukcji CREATE TABLE.

Nagłówek sprawy i słownik statusów

Nagłówek sprawy zawiera dane, które się nie powtarzają: odwołanie do klienta i dokumentu sprzedaży, a także termin odpowiedzi oraz status bieżący. Status wskazuje słownik, a nie tekst wpisany ręcznie, więc literówka nie utworzy nowego stanu.

CREATE TABLE dbo.StatusReklamacji (
    StatusId   TINYINT      NOT NULL CONSTRAINT PK_StatusReklamacji PRIMARY KEY,
    Nazwa      NVARCHAR(40) NOT NULL,
    CzyKoncowy BIT          NOT NULL DEFAULT 0
);

CREATE TABLE dbo.Reklamacja (
    ReklamacjaId      INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_Reklamacja PRIMARY KEY,
    NumerRma          VARCHAR(20)    NOT NULL CONSTRAINT UQ_Reklamacja_Numer UNIQUE,
    KlientId          INT            NOT NULL,
    DokumentSprzedazy VARCHAR(40)    NULL,
    DataZgloszenia    DATETIME2(0)   NOT NULL DEFAULT SYSUTCDATETIME(),
    TerminOdpowiedzi  DATE           NULL,
    StatusId          TINYINT        NOT NULL
        CONSTRAINT FK_Reklamacja_Status REFERENCES dbo.StatusReklamacji (StatusId),
    OpisUsterki       NVARCHAR(2000) NOT NULL,
    Wersja            ROWVERSION
);

Historia zmian i załączniki

Historia jest tabelą tylko do dopisywania. Każde przejście statusu tworzy nowy wiersz, a istniejące wiersze nie są modyfikowane, dzięki czemu ślad audytowy zachowuje kolejność zdarzeń. Załączniki, takie jak zdjęcia usterki czy skan dowodu zakupu, warto trzymać w osobnej tabeli z odwołaniem do sprawy i metadanymi pliku.

CREATE TABLE dbo.ReklamacjaHistoria (
    HistoriaId   BIGINT IDENTITY(1,1) NOT NULL CONSTRAINT PK_ReklamacjaHistoria PRIMARY KEY,
    ReklamacjaId INT           NOT NULL
        CONSTRAINT FK_Historia_Reklamacja REFERENCES dbo.Reklamacja (ReklamacjaId),
    StatusZ      TINYINT       NULL,
    StatusDo     TINYINT       NOT NULL,
    Autor        NVARCHAR(100) NOT NULL,
    Czas         DATETIME2(0)  NOT NULL DEFAULT SYSUTCDATETIME(),
    Notatka      NVARCHAR(1000) NULL
);

Numer sprawy i współbieżność

Numer nadaje obiekt SEQUENCE, który generuje wartości bez blokowania tabeli. Sekwencja nie cofa numerów po wycofaniu transakcji, więc w numeracji mogą pojawić się luki, a kontrola ciągłości nie powinna być wymogiem biznesowym. Zmianę statusu wykonuje się w krótkiej transakcji z porównaniem kolumny ROWVERSION, żeby dwóch użytkowników nie nadpisało sobie decyzji.

SET XACT_ABORT ON;
BEGIN TRAN;

UPDATE dbo.Reklamacja
   SET StatusId = @StatusDo
 WHERE ReklamacjaId = @ReklamacjaId
   AND StatusId = @StatusZ
   AND Wersja = @Wersja;

IF @@ROWCOUNT = 0
    THROW 50001, N'Sprawa została zmieniona przez innego użytkownika.', 1;

INSERT INTO dbo.ReklamacjaHistoria (ReklamacjaId, StatusZ, StatusDo, Autor)
VALUES (@ReklamacjaId, @StatusZ, @StatusDo, @Autor);

COMMIT;

Reguła: zmiana statusu i wpis w historii zapisują się w jednej transakcji, bo osobne polecenia zostawiają sprawę bez śladu po awarii.

Decyzja i rozliczenie w osobnych tabelach

Decyzja i rozliczenie mają inną częstotliwość zmian niż nagłówek, więc lepiej trzymać je w osobnych tabelach powiązanych kluczem obcym ze sprawą. Jedna sprawa może mieć kilka pozycji, gdy klient zgłasza więcej niż jeden artykuł z tego samego dokumentu sprzedaży. Wtedy decyzja zapada dla każdej pozycji osobno, a rozliczenie sumuje kwoty. Taki układ wymaga pilnowania dwóch reguł:

• Jedna decyzja na pozycję - unikalny indeks na kluczu pozycji uniemożliwia wpisanie dwóch sprzecznych rozstrzygnięć.
• Rozliczenie po decyzji - kwota zwrotu lub korekty powstaje dopiero wtedy, gdy pozycja ma zapisaną decyzję uznającą.

Indeks dla spraw otwartych

Kolejki pracy oglądają wyłącznie sprawy otwarte, a te stanowią niewielką część historycznych danych. Indeks filtrowany obejmuje tylko wiersze niezakończone, więc pozostaje mały i szybko się przebudowuje. Pokrywający zestaw kolumn pozwala wyświetlić listę zadań bez sięgania do tabeli bazowej. Opis składni zawiera dokumentacja indeksów filtrowanych.

CREATE NONCLUSTERED INDEX IX_Reklamacja_Otwarte
    ON dbo.Reklamacja (TerminOdpowiedzi)
    INCLUDE (StatusId, KlientId, NumerRma)
    WHERE StatusId < 7;

Dokumenty i komunikacja z klientem

Do sprawy dołącza się zgłoszenie i protokół oględzin. Dodatkowo system przechowuje zdjęcia usterki oraz dowód zakupu, a korespondencja z klientem trafia do tej samej historii. Kartoteka produktów wiąże zgłoszenie z konkretnym artykułem, a wyszukiwarka z filtrami skraca dojście do sprawy przy dużej liczbie rekordów. Dzięki temu przy sporze z klientem cały przebieg da się odtworzyć bez przeszukiwania skrzynek pocztowych.

Komunikacja z klientem opiera się na zdarzeniach. Zmiana statusu generuje wiadomość, a klient dostaje ją wtedy, gdy sprawa faktycznie się przesuwa, bez ręcznego pisania maili. Wersja widoczna dla klienta jest uproszczona i nie ujawnia notatek wewnętrznych, co szczegółowo opisuje artykuł o programie RMA online. Uzupełnieniem jest rejestracja zgłoszeń w oddzielnym module, opisana na stronie program do rejestracji reklamacji.

Uprawnienia do danych sprawy

Dostęp do informacji, które przemieszczają się wraz z procesem, ogranicza się rolami i prawami dostępu. Konsultant widzi własne kolejki, a kierownik działu całość spraw. Na poziomie bazy SQL Server umożliwia to między innymi mechanizm row-level security, który filtruje wiersze według atrybutów sesji.

Raporty i integracje oprogramowania do obsługi reklamacji

Dane sprawy w jednej bazie pozwalają liczyć wskaźniki bez eksportu do arkusza. Najczęściej raportuje się liczbę zgłoszeń w okresie, podział według przyczyn oraz średni czas od rejestracji do zamknięcia. Raporty tabelaryczne i wydruki można budować w SSRS, a technikę tworzenia definicji RDL opisuje artykuł SQL Report Builder.

Integracje opisuje szerzej artykuł integracja systemów informatycznych, a relację reklamacji z danymi klienta - materiał o systemach CRM. Dla firm, które wybierają model bez własnego serwera, znaczenie ma także obsługa reklamacji w chmurze.

Kryteria wyboru oprogramowania do obsługi reklamacji

Przy wyborze pomaga sprawdzenie kilku parametrów, które da się zweryfikować w trakcie demonstracji. Ich lista jest krótka, ponieważ wszystkie pozostałe cechy wynikają z tych czterech:

• Historia zmian - czy każde przejście statusu zostaje zapisane z autorem i czasem oraz czy da się je wyświetlić w karcie sprawy.
• Konfigurowalny proces - czy administrator zmienia statusy i ścieżki procesu bez udziału programisty.
• Role i uprawnienia - czy dostęp do spraw i kolumn zależy od roli, a nie od wiedzy użytkownika o adresie strony.
• Wymiana danych - czy system udostępnia interfejs do ERP i magazynu, a nie tylko eksport do pliku.

Test przyjmuje najlepszą formę praktyczną: wprowadzić jedną sprawę od zgłoszenia do zamknięcia i sprawdzić, jakie ślady zostały w historii. Wersję demonstracyjną Studio RMA.net udostępnia serwis demo reklamacji, a opis modułów znajduje się na stronie Studio RMA.net. Gdy obsługa reklamacji ma być częścią szerszej organizacji sprzedaży, warto przejrzeć zestawienie powodów wdrożenia systemu RMA online.