Program do obsługi reklamacji - uprawnienia i współpraca działów

Program do obsługi reklamacji i jedna baza dla każdego kanału

Klient zgłasza reklamację tam, gdzie mu wygodnie: dzwoni albo wypełnia formularz na stronie. Program do obsługi reklamacji zbiera te zgłoszenia w jednej bazie danych, więc cały zespół widzi tę samą historię kontaktu i ten sam status sprawy. Znika sytuacja, w której dwie osoby prowadzą ten sam przypadek, bo jedna dostała wiadomość, a druga telefon.

Wspólna baza wymaga jednej kolumny opisującej kanał wpływu. Dzięki niej raporty pokazują, przez który kanał zgłoszenia spływają najczęściej i które z nich są niekompletne. Formularz na stronie i portal klienta opisuje osobny artykuł o programie RMA on-line. Przykład formularza zgłoszeniowego pokazuje strona formularza reklamacyjnego producenta.

Powiązane zgłoszenia zamiast automatycznego scalania

Ten sam klient bywa zgłaszającym w kilku kanałach naraz. System porównuje wtedy numer dokumentu sprzedaży i numer seryjny, a przy zbieżności podpowiada powiązanie spraw. Automatyczne scalanie jest ryzykowne, bo dwa zgłoszenia o różnych usterkach jednego towaru to dwie osobne sprawy. Decyzję o połączeniu podejmuje pracownik.

Role i uprawnienia w programie do obsługi reklamacji

Reklamacja przechodzi przez kilka działów, ale nie każdy powinien widzieć wszystko. Obsługa klienta potrzebuje wglądu w całość sprawy. Pracownikom magazynu lub produkcji wystarczą informacje niezbędne do rozwiązania problemu w ich obszarze. Księgowość korzysta z danych rozliczeniowych. W Studio RMA.net dostęp do danych ogranicza się rolami i prawami dostępu, a wszystkie działy pracują na jednej bazie MS SQL Server.

Reguła: prawo do odczytu sprawy i prawo do zmiany jej statusu to dwa osobne uprawnienia, a zmiana decyzji o uznaniu reklamacji wymaga roli kierownika.

Ograniczenie wierszy w SQL Server

Uprawnienia egzekwuje się zwykle w aplikacji, ale baza może dodać drugą barierę. Mechanizm Row-Level Security filtruje wiersze według predykatu, więc zapytanie wykonane w imieniu działu nie zwróci cudzych spraw. Aplikacja webowa łączy się z bazą jednym kontem. Dział i rolę użytkownika przekazuje się więc w kontekście sesji.

CREATE FUNCTION Security.fn_DostepDoSprawy (@DzialId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Dozwolone
WHERE @DzialId = CAST(SESSION_CONTEXT(N'DzialId') AS INT)
   OR CAST(SESSION_CONTEXT(N'Rola') AS NVARCHAR(20)) = N'Kierownik';
GO

CREATE SECURITY POLICY Security.PolitykaSprawy
ADD FILTER PREDICATE Security.fn_DostepDoSprawy(DzialId) ON dbo.Reklamacja
WITH (STATE = ON);

Przykład zakłada jedną kolumnę DzialId w tabeli spraw. Sprawa obsługiwana kolejno przez kilka działów wymaga tabeli powiązań zamiast jednej kolumny, a predykat sprawdza wtedy przynależność w tej tabeli. Kontekst sesji ustawia aplikacja procedurą sp_set_session_context na początku każdego żądania. Nazwy obiektów są przykładowe i nie opisują schematu produktu.

Uprawnienia zmieniają się w czasie. Gdy pracownik przechodzi do innego działu, jego dostęp do dotychczasowych spraw powinien się skończyć, a sprawy, których był właścicielem, trzeba przekazać. Lista otwartych spraw odchodzącego pracownika jest więc zestawieniem, które kierownik uruchamia przed zmianą roli, a nie po niej.

Przydział spraw do działów według reguł

Nowe zgłoszenie powinno trafić do właściwej osoby bez pośrednictwa kierownika. Studio RMA.net przypisuje zgłoszenia według ustalonych reguł, na przykład kategorii produktu i rodzaju problemu. Zasadę tę można wyrazić tabelą, w której każda reguła ma priorytet, a puste pole oznacza dowolną wartość.

SELECT TOP (1) r.DzialId
FROM dbo.RegulaPrzydzialu AS r
WHERE (r.KategoriaId       IS NULL OR r.KategoriaId       = @KategoriaId)
  AND (r.RodzajProblemuId  IS NULL OR r.RodzajProblemuId  = @RodzajProblemuId)
ORDER BY r.Priorytet ASC,
         (CASE WHEN r.KategoriaId      IS NULL THEN 1 ELSE 0 END
        + CASE WHEN r.RodzajProblemuId IS NULL THEN 1 ELSE 0 END) ASC;

Zapytanie wybiera regułę o najniższym priorytecie, a przy remisie tę, która ma mniej pustych pól, czyli jest bardziej szczegółowa. Ostatnia reguła z pustymi polami działa jak sieć bezpieczeństwa: zgłoszenie bez dopasowania trafia do kolejki ogólnej i nie ginie.

Osoba czy kolejka

Przydział do konkretnej osoby skraca czas reakcji, ale zawodzi przy nieobecności. Przydział do kolejki działu jest odporny na urlopy, lecz wymaga, żeby ktoś sprawę przejął. Częsty układ łączy oba podejścia: reguła wskazuje dział, a pracownik przejmuje sprawę z kolejki i od tej chwili jest jej właścicielem. Nadzór nad kolejkami i zaległościami opisuje artykuł o programie do nadzorowania reklamacji.

Notatki i załączniki przy sprawie

Studio RMA.net pozwala dodawać do zgłoszenia notatki i zdjęcia wadliwych produktów oraz szybko wyszukiwać dokumenty. Wymiana uwag między działami odbywa się w samej sprawie, a nie w prywatnych wiadomościach. Cała korespondencja zostaje w jednym miejscu i po miesiącach można odtworzyć, kto co ustalił.

Rozróżnienie wpisów wewnętrznych i widocznych dla klienta trzeba zapisać w danych, na przykład w kolumnie CzyWidocznyDlaKlienta. Pomyłka w tym miejscu jest kosztowna, bo notatka o wątpliwościach wobec zasadności reklamacji może trafić do klienta. Domyślną wartością kolumny powinno być nie, a zmiana wymaga świadomego kliknięcia. Zdjęcia i pliki przechowuje się zwykle poza tabelami, a w bazie zapisuje się ścieżkę i rozmiar pliku, co odciąża bazę i przyspiesza kopie zapasowe.

Oznaczenie współpracownika w komentarzu jest w praktyce zadaniem z powiadomieniem. Warto, żeby zadanie miało termin, bo prośba bez terminu w komentarzu ginie równie łatwo jak wiadomość w skrzynce.

Przekazanie sprawy między działami

Najwięcej spraw gubi się w chwili przekazania: obsługa uznaje, że serwis wie, a serwis nie dostał żadnej informacji. Przekazanie ma więc być operacją systemową, a nie ustaleniem ustnym. Poprawne przekazanie zapisuje cztery elementy.

• Właściciel - jedna osoba albo kolejka odpowiedzialna za kolejny krok.
• Zadanie - opis czynności, którą przyjmujący ma wykonać.
• Termin - data, do której przyjmujący odpowiada za wynik.
• Powód zwrotu - obowiązkowy komentarz, gdy dział odsyła sprawę do nadawcy.

Po stronie bazy przekazanie powinno być jedną transakcją: zmiana właściciela i wpis w historii sprawy zapisują się razem albo wcale. Warunek w klauzuli WHERE chroni przed sytuacją, w której dwie osoby przejmują tę samą sprawę w tej samej sekundzie.

SET XACT_ABORT ON;
BEGIN TRAN;

UPDATE dbo.Reklamacja
SET WlascicielId = @NowyWlasciciel,
    DzialId      = @NowyDzial
WHERE Id = @SprawaId
  AND WlascicielId = @ObecnyWlasciciel;

IF @@ROWCOUNT = 0
    THROW 50001, 'Sprawa ma juz innego wlasciciela.', 1;

INSERT INTO dbo.HistoriaSprawy (SprawaId, Zdarzenie, Autor, Komentarz, Data)
VALUES (@SprawaId, N'Przekazanie', @Autor, @Komentarz, SYSDATETIME());

COMMIT;

Jeśli sprawa zmieniła już właściciela, aktualizacja nie zmienia żadnego wiersza, procedura zgłasza błąd, a użytkownik dostaje komunikat, że sprawę przejął ktoś inny. Opcja XACT_ABORT sprawia, że błąd wycofuje całą transakcję.

Reguła: sprawa ma zawsze jednego właściciela, a odesłanie jej do nadawcy bez komentarza z uzasadnieniem jest niedozwolone.

Komunikacja z klientem z poziomu sprawy

Program wysyła klientowi automatyczne powiadomienia e-mail o statusie zgłoszenia. Korespondencja przychodząca też powinna wracać do sprawy. Najprostszy mechanizm opiera się na numerze sprawy w temacie wiadomości: odpowiedź klienta z numerem trafia do właściwej historii, a wiadomość bez numeru ląduje w kolejce do ręcznego przypisania.

Dokładniejsze dopasowanie wykorzystuje nagłówki In-Reply-To i References, które łączą odpowiedź z wysłaną wcześniej wiadomością. Mechanizm ten działa tylko wtedy, gdy program pocztowy klienta zachowuje nagłówki, więc numer w temacie pozostaje zabezpieczeniem. Szablony wiadomości i kolejkę wysyłki opisuje wspomniany wyżej tekst o programie RMA on-line.

Ważne jest rozdzielenie komunikacji z klientem i uwag wewnętrznych w widoku sprawy. Pracownik piszący do klienta nie powinien mieć w tym samym oknie notatek o wątpliwościach co do zasadności zgłoszenia.

Szablony odpowiedzi

Powtarzalne wiadomości, takie jak potwierdzenie przyjęcia zgłoszenia albo prośba o dodatkowe zdjęcia, oszczędzają czas, jeśli szablon zawiera pola zmienne, na przykład numer sprawy i nazwę produktu. Pracownik widzi gotową treść i może ją poprawić przed wysyłką. Szablon, którego nie można edytować, wymusza sztywne odpowiedzi w sprawach nietypowych i kończy się wiadomościami pisanymi poza systemem. Zmiana treści szablonu powinna być dostępna tylko dla kierownika, żeby jedno brzmienie obowiązywało wszystkich.

Terminy i przypomnienia przy obsłudze sprawy

Każda sprawa ma termin, do którego klient powinien dostać odpowiedź. Program do obsługi reklamacji ustawia go przy rejestracji, a Studio RMA.net przypomina o zbliżających się terminach, żeby żadna reklamacja nie umknęła zespołowi. Skąd biorą się same terminy, w tym wymogi wynikające z przepisów, wyjaśnia artykuł o terminach i raportach w zarządzaniu reklamacjami.

Przypomnienie da się zbudować bez pracy ręcznej. Zadanie SQL Server Agent uruchamia się cyklicznie, wybiera sprawy z terminem w najbliższych godzinach i wpisuje powiadomienia do kolejki. Klauzula NOT EXISTS pilnuje, żeby jedna sprawa nie dostała tego samego przypomnienia przy każdym uruchomieniu zadania.

INSERT INTO dbo.KolejkaPowiadomien (SprawaId, AdresatId, Typ, DataUtworzenia)
SELECT r.Id, r.WlascicielId, N'TerminBliski', SYSDATETIME()
FROM dbo.Reklamacja AS r
WHERE r.TerminOdpowiedzi BETWEEN SYSDATETIME() AND DATEADD(HOUR, 24, SYSDATETIME())
  AND NOT EXISTS (SELECT 1
                  FROM dbo.KolejkaPowiadomien AS k
                  WHERE k.SprawaId = r.Id AND k.Typ = N'TerminBliski');

Kolejkę powiadomień odczytuje osobny proces, który wysyła e-maile i oznacza wpisy jako wysłane. Rozdzielenie tworzenia i wysyłki ułatwia ponawianie po awarii poczty. Harmonogram zadań opisuje dokumentacja SQL Server Agent na Microsoft Learn.

Termin odpowiedzi a termin rozstrzygnięcia

Z punktu widzenia obsługi ważna jest różnica między terminem odpowiedzi a terminem rozstrzygnięcia. Pierwszy dotyczy kontaktu z klientem, drugi decyzji w sprawie. Sprawa może mieć spełniony termin odpowiedzi, bo klient dostał potwierdzenie, i jednocześnie zbliżać się do przekroczenia terminu rozstrzygnięcia. Dwa przypomnienia o różnych adresatach zmniejszają ryzyko, że jedno z nich zostanie zignorowane.

Jak rozdzielić oba terminy w umowach o poziomie usług i jak pokazać klientowi status, opisuje tekst o programie do zarządzania reklamacjami.

Integracja z CRM i ERP w obsłudze reklamacji

Program do obsługi reklamacji rzadko działa sam. Dane klienta znajdują się w CRM, a dokumenty sprzedaży w ERP. Integracja z tymi systemami pozwala pobrać dane przy rejestracji zgłoszenia i uniknąć przełączania się między aplikacjami. Współpracę z systemem klasy CRM omawia osobna strona, a przykład powiązania z systemem finansowo-księgowym stanowi Symfonia ERP.

Studio RMA.net działa w przeglądarce, więc integracje odbywają się po stronie serwera i bazy, a nie na stanowisku pracownika. Ogólne zasady budowy takich systemów przedstawia artykuł o aplikacjach webowych, a dostęp z telefonu i przeglądarki opisuje tekst reklamacje aplikacja.

Wymiana danych opiera się na kluczach, takich jak numer klienta i numer dokumentu sprzedaży. Kierunek odczytu i kierunek zapisu różnią się ryzykiem, co pokazuje tabela.

Studio RMA.net opisuje producent na stronie aplikacji Studio RMA.net. Zasady numeracji i identyfikacji spraw wyjaśnia artykuł o numerze RMA, a etapy sprawy oraz model danych w SQL Server zawiera tekst o oprogramowaniu do obsługi reklamacji.