Program do reklamacji - kryteria wyboru od rejestru po raporty

Program do reklamacji - od czego zależy wybór

Program do reklamacji ocenia się po tym, co zostaje w bazie po zamknięciu sprawy, a nie po liczbie przycisków na ekranie. Dobry rejestr pozwala po roku odpowiedzieć, kto przyjął zgłoszenie, jakie decyzje zapadły i ile trwał każdy etap. Słaby zostawia pole tekstowe z opisem i kilka załączników w skrzynce pocztowej jednego pracownika.

Pięć kryteriów wystarcza, żeby odróżnić program od nakładki na arkusz kalkulacyjny. Tabela zestawia je z pytaniem kontrolnym, które da się zadać dostawcy podczas demonstracji, oraz z objawem, jaki pojawia się w pracy, gdy danej cechy brakuje.

Reguła: program, który nie zapisuje historii zmian statusu, nie policzy rzetelnie czasu obsługi.

Samą czynność przyjęcia zgłoszenia opisuje artykuł o programie do rejestracji reklamacji. Ten tekst traktuje rejestr wyłącznie jako kryterium oceny, obok czterech pozostałych.

Wagi kryteriów zależą od profilu firmy. Sklep z dużą liczbą drobnych zgłoszeń najbardziej odczuje brak automatycznych terminów i szablonów odpowiedzi. Producent, który naprawia sprzęt, potrzebuje przede wszystkim statusów naprawy i historii urządzenia. Firma sprzedająca odbiorcom hurtowym patrzy na dokumenty rozliczeniowe i powiązanie z dostawcą. Przed rozmową z dostawcą dobrze więc przypisać każdemu kryterium wagę i ocenić program w skali, a nie odpowiadać „tak” lub „nie” na listę funkcji.

Rejestr i statusy w programie do reklamacji

W rejestrze każda sprawa ma numer i dokument sprzedaży. Przy nich zapisane są dane klienta oraz reklamowany towar, a całość uzupełnia data wpływu. Data wpływu nie jest datą utworzenia rekordu. Reklamacja przyjęta telefonicznie w piątek i wpisana w poniedziałek ma piątkową datę wpływu, bo od niej biegną terminy. Program powinien przechowywać oba znaczniki czasu osobno i nie pozwalać na ciche nadpisanie pierwszego.

Status opisuje, na kim spoczywa kolejny krok w sprawie. Nazwy statusów bywają różne w różnych firmach, dlatego przy ocenie programu ważniejsze są cztery atrybuty słownika statusów:

• Znacznik otwartości - informacja, czy sprawa w danym statusie nadal liczy się do zaległych, więc raporty nie zależą od nazw.
• Dozwolone następniki - lista statusów, do których wolno przejść, dzięki czemu nie da się przeskoczyć z przyjęcia od razu do zamknięcia.
• Wymóg uzasadnienia - pole, które trzeba wypełnić przy przejściu, na przykład przy odrzuceniu reklamacji.
• Właściciel kolejnego kroku - rola lub dział odpowiedzialny za sprawę, dopóki nie zmieni się status.

Dozwolone przejścia najprościej trzymać w osobnej tabeli. Reguła zapisana w bazie działa niezależnie od tego, z jakiego ekranu lub integracji przychodzi zmiana, więc interfejs w przeglądarce nie jest jedyną barierą.

-- przykładowy schemat, nazwy poglądowe
CREATE TABLE dbo.PrzejscieStatusu (
    StatusZ            INT NOT NULL,
    StatusDo           INT NOT NULL,
    WymagaUzasadnienia BIT NOT NULL DEFAULT 0,
    CONSTRAINT PK_PrzejscieStatusu PRIMARY KEY (StatusZ, StatusDo)
);

Model danych sprawy i pełną listę statusów z przejściami omawia tekst o oprogramowaniu do obsługi reklamacji. Strukturę warstw aplikacji, w której te reguły działają, pokazuje opis architektury systemu RMA.

Terminy w programie do reklamacji

Termin odpowiedzi zależy od tego, kto reklamuje. Inaczej liczy się reklamację konsumenta, inaczej reklamację odbiorcy będącego przedsiębiorcą. Artykuł o zarządzaniu reklamacjami i terminach podaje, jak zapisano to w tekstach jednolitych ustaw: na reklamację konsumenta trzeba odpowiedzieć w ciągu 14 dni, a brak odpowiedzi oznacza jej uznanie. Program musi więc rozpoznać rodzaj klienta już przy rejestracji. Interpretację przepisów w konkretnej sprawie warto potwierdzić u prawnika.

Liczba dni nie powinna siedzieć w kodzie aplikacji. Zapisana w słowniku terminów, zmienia się jednym wpisem po nowelizacji przepisów lub po zmianie umowy z odbiorcą. Zapytanie poniżej pokazuje sprawy otwarte z liczbą dni pozostałych do terminu.

-- nazwy tabel i kolumn są przykładowe
SELECT r.Numer,
       r.DataWplywu,
       DATEADD(DAY, t.TerminDni, r.DataWplywu) AS TerminOdpowiedzi,
       DATEDIFF(DAY, SYSDATETIME(), DATEADD(DAY, t.TerminDni, r.DataWplywu)) AS DniDoTerminu
FROM dbo.Reklamacja AS r
JOIN dbo.SlownikTerminow AS t ON t.RodzajKlientaId = r.RodzajKlientaId
WHERE r.CzyOtwarta = 1
ORDER BY DniDoTerminu;

Funkcja DATEDIFF zlicza przekroczenia granic dni, a nie pełne doby, co przy terminach liczonych w dniach kalendarzowych daje właściwy wynik. Przy dniach roboczych potrzebna jest osobna tabela kalendarza ze świętami.

Reguła: termin zapisuje się w sprawie w chwili rejestracji, a późniejsza zmiana słownika nie przesuwa terminów spraw już otwartych.

Obok terminu wynikającego z przepisów działa termin wewnętrzny, krótszy, który zostawia zapas na decyzję kierownika. Oba powinny być widoczne na liście spraw jako osobne kolumny. Sposób ustawiania przypomnień i eskalacji opisuje tekst o programie do obsługi reklamacji.

Dokumenty i załączniki w programie do reklamacji

Sprawa reklamacyjna produkuje kilka dokumentów, a program powinien wiedzieć, który z nich powstaje na jakim etapie. Ten sam numer sprawy łączy cztery dokumenty z tabeli poniżej, więc w sporze z klientem da się odtworzyć przebieg nawet po wielu miesiącach.

Pliki zwykle trafiają na serwer plików, a w bazie zostaje ścieżka do pliku wraz z autorem i datą dodania. Przy ocenie programu warto sprawdzić, czy da się wygenerować dokument z danych sprawy i czy wersja wysłana do klienta zostaje zapisana jako niezmienny plik. Zestaw dokumentów w pełnej procedurze opisuje tekst o procedurze RMA, a rolę numeru na paczce i etykiecie omawia artykuł o numerze RMA.

Raporty w programie do reklamacji

Raport z reklamacji odpowiada na pytania o przyczynę usterki i czas obsługi. Zestawienia, których wymaga kierownik, sprowadzają się do czterech miar:

• Liczba spraw według przyczyny - z zamkniętego słownika kodów przyczyn, wybieranych przy zamknięciu sprawy.
• Czas do decyzji - liczony od daty wpływu do dnia rozstrzygnięcia, osobno dla każdej kategorii towaru.
• Sprawy po terminie - otwarte reklamacje z przekroczonym terminem wewnętrznym lub ustawowym.
• Wynik decyzji - udział decyzji pozytywnych i odmownych w sprawach zamkniętych w okresie.

Każda z tych miar wymaga historii zmian. Czas do decyzji da się policzyć tylko wtedy, gdy program zapisał, kiedy sprawa dostała status rozstrzygnięcia. Tabele czasowe SQL Server, opisane w dokumentacji tabel czasowych, odtwarzają stan sprawy z dowolnej chwili bez ręcznego dopisywania wierszy.

Wydruki i zestawienia w formacie zgodnym z firmowym wzorem tworzy się zwykle w Report Builderze, co opisuje artykuł o SQL Report Builder i wydrukach RDL. Wskaźniki pracy nadzorczej, takie jak zaległe sprawy i mediana czasu obsługi, rozwija tekst o nadzorowaniu reklamacji.

Uprawnienia i ślad zmian w programie do reklamacji

Reklamacja zawiera dane osobowe klienta i dane handlowe, takie jak ceny i rabaty, więc dostęp do spraw trzeba ograniczyć. Pracownik obsługi widzi sprawy swojego zespołu, kierownik całą kolejkę, a księgowość wyłącznie decyzje z rozliczeniem. Podział ról i przekazywanie sprawy między działami omawia artykuł o programie do obsługi reklamacji, a poniżej opisano tylko mechanizm, który warto sprawdzić przy wyborze.

Ograniczenie można wymusić już w bazie. Mechanizm zabezpieczeń na poziomie wiersza w SQL Server, dostępny od wersji 2016, dokłada do każdego zapytania predykat filtrujący, więc pominięcie warunku w kodzie aplikacji nie odsłoni cudzych spraw. Aplikacja ustawia po zalogowaniu identyfikator działu w kontekście sesji, a polityka porównuje go z kolumną sprawy.

-- przykład poglądowy, nazwy są umowne
CREATE SCHEMA Sec;
GO
CREATE FUNCTION Sec.fn_DostepDoSprawy(@DzialId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Dozwolone
WHERE @DzialId = CAST(SESSION_CONTEXT(N'DzialId') AS INT);
GO
CREATE SECURITY POLICY Sec.PolitykaReklamacji
ADD FILTER PREDICATE Sec.fn_DostepDoSprawy(DzialId) ON dbo.Reklamacja
WITH (STATE = ON);

Reguła: historia zmian jest tabelą tylko do dopisywania, a konto aplikacji nie ma na niej uprawnień do edycji ani usuwania wierszy.

Ślad zmian zapisuje autora i datę każdego przejścia oraz status przed zmianą i po niej. Wpis, którego nie da się poprawić, ma wartość dowodową w sporze z klientem i pozwala rozliczyć odpowiedzialność za decyzję. Przy ocenie programu wystarczy poprosić o pokazanie historii dowolnej zamkniętej sprawy i sprawdzić, czy widać w niej wszystkie przejścia.

Arkusz kalkulacyjny a program do reklamacji

Arkusz sprawdza się przy niewielkiej liczbie zgłoszeń i jednej osobie, która je prowadzi. Kłopoty zaczynają się, gdy dwie osoby edytują ten sam plik albo termin trzeba policzyć ręcznie dla każdego wiersza. Tabela zestawia oba podejścia w miejscach, w których różnica ma znaczenie dla procesu.

Reguła: o przejściu z arkusza na program decyduje moment, w którym termin trzeba liczyć ręcznie albo dwie osoby nadpisują sobie wiersze, a nie sama liczba spraw.

Ręczne prowadzenie rejestru jest mało wydajne i nadaje się do sytuacji, gdy zgłoszeń jest niewiele. Gdy dziennie wpływają dziesiątki albo setki reklamacji, potrzebny jest system informatyczny. Porównanie w kontekście firmy handlowej daje tekst o terminach i podziale ról, a ryzyka arkuszy w innej branży pokazuje artykuł o arkuszach kalkulacyjnych w transporcie.

Sprawdzenie programu do reklamacji na własnych danych

Demonstracja na danych dostawcy pokazuje najlepszy przypadek. Więcej mówi próba na kilkudziesięciu prawdziwych zgłoszeniach z ostatniego kwartału, w tym na tych, które sprawiły najwięcej kłopotu. Cztery scenariusze warto przejść na pewno:

• Reklamacja bez dokumentu sprzedaży - program musi pozwolić ją zarejestrować i oznaczyć brak, a nie blokować wpis.
• Zwrot częściowy - sprawa obejmuje jedną pozycję z zamówienia, a rozliczenie dotyczy tylko jej.
• Zmiana decyzji po odwołaniu - stara decyzja zostaje w historii, a nowa dostaje własną datę i autora.
• Eksport danych - pełny zbiór spraw da się pobrać w formacie, który otworzy inny program, co ogranicza uzależnienie od dostawcy.

Jeśli firma przenosi się z arkusza, wpisy historyczne trzeba zaimportować z zachowaniem oryginalnych numerów i dat wpływu. Nowy numer nadany przy imporcie zrywa powiązanie z korespondencją, którą klient już dostał, dlatego stary numer zostaje w osobnym polu i wchodzi do wyszukiwania. Import wykonuje się najpierw na kopii bazy, a wynik porównuje się z arkuszem, zestawiając liczbę spraw otwartych przed przeniesieniem i po nim.

Studio RMA.net, według opisu producenta zebranego w innych artykułach serwisu, pozwala projektować własne pola formularza oraz dodawać checklisty i zdjęcia. Wymianę danych z systemem ERP lub WMS przedstawia strona o systemie RMA, a przebieg sprawy w gotowym środowisku pokazuje demo reklamacji. Odpowiedź na pytanie, jak uporządkować wybór między pojęciami, jest w artykule o wyborze systemu i wskaźnikach KPI.