System rejestracji zgłoszeń online - rejestr i przyjęcie zgłoszenia

Firma, która przyjmuje reklamacje mailem i telefonem, nie ma jednego miejsca z pełną listą spraw. System rejestracji zgłoszeń online rozwiązuje ten problem u źródła: każde zgłoszenie trafia do rejestru z numerem i statusem, a dopiero z rejestru jest rozdzielane do działów. Rejestr staje się podstawą do prowadzenia rozpatrywania skarg i do analizy niezgodności.

Ten artykuł opisuje rejestrację jako etap procesu. Zaczyna od formularza z walidacją i zapisu w bazie, a dalej omawia przepływ informacji oraz kryteria wyboru narzędzia. Przykłady w T-SQL i JavaScript mają nazwy poglądowe i nie opisują schematu produktu SoftwareStudio.

System rejestracji zgłoszeń online jako rejestr spraw

Klient zgłasza reklamację albo zapytanie przez formularz w przeglądarce o dowolnej porze. Zgłoszenie trafia bezpośrednio do bazy danych, gdzie system nadaje mu numer, a następnie przydziela je do właściwego działu. Pracownicy diagnozują sprawę i podejmują kroki naprawcze, a klient widzi status w panelu.

Dokładny opis narzędzia do przyjmowania reklamacji zawiera artykuł program do rejestracji reklamacji. Stronę producenta poświęconą temu zagadnieniu udostępnia serwis system rejestracji zgłoszeń online.

Formularz zgłoszeniowy i walidacja pól

Formularz decyduje o jakości danych w rejestrze. Zbyt mało pól utrudnia klasyfikację, a zbyt wiele zniechęca zgłaszającego. Każde pole ma więc regułę walidacji i powód, dla którego jest w formularzu.

function sprawdzZgloszenie(f) {
  const bledy = [];
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(f.email)) bledy.push('email');
  if (!f.numerDokumentu.trim()) bledy.push('numerDokumentu');
  if (f.opis.trim().length < 20) bledy.push('opis');
  return bledy;
}

Funkcja zwraca listę pól z błędem, a formularz wyróżnia je przy wysyłce. Wyrażenie regularne dla adresu e-mail celowo jest proste, bo pełna zgodność ze standardem jest praktycznie niemożliwa do sprawdzenia wzorcem. Prawdziwą weryfikacją adresu jest wiadomość z potwierdzeniem.

Reguła: walidacja w przeglądarce jest podpowiedzią dla użytkownika, a jedynym źródłem prawdy o poprawności zgłoszenia jest serwer, który powtarza wszystkie kontrole.

Pola zależne od rodzaju zgłoszenia

Nie każde zgłoszenie wymaga tych samych danych. Reklamacja towaru potrzebuje numeru dokumentu zakupu i opisu wady, a zapytanie o status sprawy tylko numeru zgłoszenia. Formularz pokazuje pola dodatkowe po wyborze kategorii, więc zgłaszający nie wypełnia niepotrzebnych rubryk.

• Kategoria - wybór ze słownika, który decyduje o zestawie pól i o przydziale do działu.
• Pola dodatkowe - dane wymagane tylko dla wybranej kategorii, na przykład numer seryjny towaru.

Załączniki i bezpieczeństwo wysyłki

Zdjęcia wady i dokumenty zakupu przyspieszają rozpatrzenie sprawy, ale są też najczęstszą drogą ataku na formularz. Serwer nie może ufać ani rozszerzeniu pliku, ani typowi zgłoszonemu przez przeglądarkę. Kontrola obejmuje listę dozwolonych typów i limit rozmiaru. Nazwę pliku system zamienia na własną wartość.

private static readonly HashSet<string> Dozwolone =
    new(StringComparer.OrdinalIgnoreCase) { ".jpg", ".png", ".pdf" };

public IActionResult DodajZalacznik(IFormFile plik)
{
    if (plik.Length == 0 || plik.Length > 5 * 1024 * 1024)
        return BadRequest("Nieprawidlowy rozmiar pliku.");
    if (!Dozwolone.Contains(Path.GetExtension(plik.FileName)))
        return BadRequest("Niedozwolony typ pliku.");

    var nazwa = Guid.NewGuid().ToString("N") + Path.GetExtension(plik.FileName);
    // zapis pliku poza katalogiem publicznym, w bazie tylko nazwa i rozmiar
    return Ok(nazwa);
}

Przykład w C# pokazuje zasadę, a nie gotową implementację: limit pięciu megabajtów jest wartością poglądową. Pliki przechowuje się poza katalogiem dostępnym z Internetu, a w bazie zapisuje się nazwę i rozmiar, co odciąża bazę i przyspiesza kopie zapasowe. Rozszerzenie jest tylko pierwszym filtrem, więc dokładniejsza kontrola sprawdza także sygnaturę pliku.

Zapis zgłoszenia i numer w rejestrze

Przyjęcie zgłoszenia powinno być jedną transakcją. Wiersz zgłoszenia i wpis w historii zapisują się razem albo wcale, więc rejestr nie zawiera spraw bez śladu przyjęcia. Osobny problem to podwójne kliknięcie przycisku wysyłki, które bez zabezpieczenia tworzy dwie identyczne sprawy.

Zabezpiecza przed tym token generowany przez formularz przy jego otwarciu. Ten sam token wraca przy każdej próbie wysyłki, a baza uznaje go za identyfikator jednego zgłoszenia.

CREATE PROCEDURE dbo.ZarejestrujZgloszenie
    @Token UNIQUEIDENTIFIER,
    @Email NVARCHAR(200),
    @Opis  NVARCHAR(MAX)
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;

    BEGIN TRAN;

    DECLARE @Id INT = (SELECT Id FROM dbo.Zgloszenie WITH (UPDLOCK, HOLDLOCK)
                       WHERE Token = @Token);

    IF @Id IS NULL
    BEGIN
        INSERT INTO dbo.Zgloszenie (Token, Email, Opis, Status, DataWplywu)
        VALUES (@Token, @Email, @Opis, N'Nowe', SYSDATETIME());
        SET @Id = SCOPE_IDENTITY();

        INSERT INTO dbo.HistoriaZgloszenia (ZgloszenieId, Zdarzenie, Data)
        VALUES (@Id, N'Przyjęcie zgłoszenia', SYSDATETIME());
    END

    COMMIT;
    SELECT @Id AS ZgloszenieId;
END;

Podpowiedź UPDLOCK z HOLDLOCK blokuje zakres klucza na czas transakcji, więc drugie wywołanie z tym samym tokenem czeka i po odblokowaniu znajduje już istniejący wiersz. Dodatkowo kolumna Token powinna mieć unikalny indeks jako ostatnią barierę. Opcja SET XACT_ABORT wycofuje całą transakcję przy pierwszym błędzie wykonania.

Numer widoczny dla zgłaszającego

Po zapisie klient dostaje numer zgłoszenia w ekranie potwierdzenia i w wiadomości e-mail. Numer identyfikuje sprawę w każdej dalszej rozmowie, a jego budowę opisuje artykuł o numerze RMA. W obrocie między firmami rolę tego identyfikatora omawia tekst return merchandise authorization.

Rejestr zgłoszeń i przepływ informacji

Zgłoszenia trafiają do odpowiednich działów albo do pracowników odpowiedzialnych za rozpatrzenie. Przepływ ma sens tylko wtedy, gdy każdy status wskazuje osobę odpowiedzialną i następny krok.

Przydział działa na regułach: kategoria zgłoszenia wskazuje dział, a priorytet określa kolejność w jego kolejce. Zgłoszenie bez dopasowania trafia do kolejki ogólnej, żeby żadna sprawa nie zginęła.

• Kategoria - rodzaj zgłoszenia, na przykład reklamacja towaru albo zapytanie o status.
• Priorytet - wartość liczbowa, która wyznacza kolejność w kolejce działu.
• Właściciel - osoba albo kolejka, która odpowiada za następny krok w sprawie.
• Termin - data, po której system wysyła przypomnienie lub alert.

Klient śledzi te statusy w panelu, co ogranicza liczbę pytań o stan sprawy. Dostęp do zgłoszeń dla odbiorców biznesowych opisuje artykuł moduł internetowy dla kontrahentów.

Terminy w rejestrze

Rejestr pozwala wskazać sprawy, które czekają zbyt długo w statusach początkowych. Zapytanie kontrolne wybiera zgłoszenia nowe i w obsłudze, których data wpływu jest starsza niż zapisany w konfiguracji limit dni.

SELECT Numer, Status, DataWplywu
FROM dbo.Zgloszenie
WHERE Status IN (N'Nowe', N'W obsłudze')
  AND DataWplywu < DATEADD(DAY, -@LimitDni, SYSDATETIME())
ORDER BY DataWplywu;

Wynik trafia do kierownika jako lista zaległości. Limit dni jest parametrem, bo termin odpowiedzi zależy od rodzaju zgłoszenia oraz od umowy z odbiorcą, a nie od kodu aplikacji.

Potwierdzenia i powiadomienia

Po przyjęciu zgłoszenia system wysyła potwierdzenie z numerem, a przy zmianie statusu kolejne powiadomienie. Wiadomość nie powinna być wysyłana w trakcie transakcji zapisu, bo błąd poczty wycofałby poprawnie przyjęte zgłoszenie. Bezpieczniejszy układ zapisuje powiadomienie w tabeli kolejki, a osobne zadanie wysyła je po zatwierdzeniu transakcji i ponawia próbę po błędzie.

Historia zmian w rejestrze

Każda zmiana statusu oraz każda zmiana przydziału zapisuje wpis z datą i nazwą autora. Wpisów nie edytuje się ani nie usuwa: pomyłkę koryguje nowy wpis z adnotacją. Taka historia pozwala odpowiedzieć na pytanie, kto i kiedy zmienił sprawę, a w sporze z klientem służy jako dokument przebiegu zdarzeń.

Zapis historii należy do tej samej transakcji co zmiana, którą opisuje. Gdyby oba zapisy były niezależne, rejestr mógłby zawierać status bez śladu jego zmiany.

Identyfikacja niezgodności i działania korygujące

Rejestr zgłoszeń ma wartość analityczną, gdy przyczyna każdej sprawy jest zapisana w postaci kodu ze słownika, a nie wolnego tekstu. Zapytanie grupujące po kodzie pokazuje wtedy powtarzalne niezgodności i ich częstość.

SELECT k.Kod, k.Nazwa, COUNT(*) AS Liczba
FROM dbo.Zgloszenie AS z
JOIN dbo.KodPrzyczyny AS k ON k.Id = z.KodPrzyczynyId
WHERE z.DataWplywu >= DATEADD(MONTH, -3, SYSDATETIME())
GROUP BY k.Kod, k.Nazwa
ORDER BY Liczba DESC;

Zestawienie z ostatnich trzech miesięcy wskazuje przyczyny, którymi warto zająć się w pierwszej kolejności. Działanie korygujące zapisuje się osobno, jako rekord powiązany ze zgłoszeniami. Rekord ma termin i właściciela.

Reguła: działanie korygujące bez terminu i właściciela jest notatką, a nie działaniem, więc formularz działania wymaga obu tych pól.

Nadzór nad takimi sprawami i kolejkami opisuje artykuł program do nadzorowania reklamacji. Wydruki i zestawienia z rejestru przygotowuje się w narzędziu opisanym w tekście SQL Report Builder - raporty RDL i wydruki.

Kryteria wyboru systemu rejestracji zgłoszeń

Przy porównywaniu ofert warto sprawdzić, czy narzędzie pokrywa proces opisany wyżej, a nie tylko formularz. Poniższa tabela zbiera kryteria wraz z pytaniami kontrolnymi.

Studio RMA.net jest aplikacją przeglądarkową z rejestrem zgłoszeń, więc kryterium dostępności spełnia z założenia. Szczegóły funkcji opisuje artykuł Studio RMA.net, a sposób działania w chmurze tekst o systemie RMA online. Integracja z CRM lub magazynem podnosi spójność danych w całej firmie, bo zgłoszenie widzi ten sam klient i ta sama historia zamówień.

Przed decyzją warto przejść w wersji demonstracyjnej całą ścieżkę od zgłoszenia do raportu i sprawdzić, czy każdy etap zostawia ślad w rejestrze. Dobrym testem jest zgłoszenie wysłane dwa razy z rzędu, zgłoszenie z niedozwolonym załącznikiem oraz sprawa przekazana do innego działu. Wynik tych prób mówi o systemie więcej niż lista funkcji z broszury.

Koszty wdrożenia i utrzymania

Na cenę systemu składa się nie tylko licencja lub abonament. Do kosztu wdrożenia dochodzą konfiguracja statusów i formularzy, integracje z CRM i magazynem oraz szkolenia zespołu. Po uruchomieniu firma płaci za utrzymanie i aktualizacje.

• Koszt początkowy - analiza procesu i konfiguracja, a także przeniesienie danych z dotychczasowych rejestrów.
• Koszt bieżący - abonament lub opłata za utrzymanie oraz zmiany w konfiguracji w miarę rozwoju firmy.

Rzetelna oferta rozdziela te pozycje, a zakres prac wynika z analizy procesu. Pytanie o cenę bez znajomości liczby kanałów zgłoszeń i planowanych integracji prowadzi do wyceny, która później się zmienia.

Zgłoszenia B2C, kanały i ochrona danych

Reklamacje B2C dotyczą relacji firmy z konsumentem i wynikają najczęściej z wad produktów albo problemów z jakością usługi. Proces składania powinien być dostępny kilkoma kanałami. Klient dzwoni albo pisze e-mail, a część zgłoszeń wpływa przez formularz online. Wszystkie zgłoszenia trafiają do jednego rejestru, a pole kanału wpływu pozwala ocenić, którędy spływa ich najwięcej. Przykład takiego układu udostępnia strona reklamacje B2C, a temat opisuje artykuł reklamacje B2C.

Rejestr zawiera dane osobowe zgłaszających, więc dostęp do nich ogranicza się rolami, a okres przechowywania zapisuje w konfiguracji. W praktyce oznacza to zasadę minimalizacji: formularz zbiera tylko dane potrzebne do rozpatrzenia sprawy, a po upływie okresu retencji pola osobowe warto anonimizować. Wymagania w tym zakresie ustala inspektor ochrony danych lub prawnik firmy zgodnie z RODO.

Program RMA online, który centralizuje zgłoszenia w przeglądarce, zmniejsza ryzyko błędów wynikających z ręcznego przepisywania. Producent opisuje go na stronie Program RMA. Kontakt telefoniczny w sprawie demonstracji systemu to +48 533 322 626.