Automatyzacja reklamacji: jak dotrzymać terminu 14 dni (i jak nie zgubić żadnego zgłoszenia)

Dlaczego ten proces traktuję inaczej niż resztę automatyzacji

W większości projektów automatyzacyjnych, które robimy, mówimy klientowi: „to podniesie efektywność, skróci czas obsługi, odciąży ludzi”. Przy reklamacjach mówię co innego: to nie jest kwestia wygody, tylko ryzyka prawnego. Jeśli przedsiębiorca sprzedający konsumentom nie odpowie na reklamację w terminie 14 dni, prawo w wielu przypadkach każe uznać, że reklamację zaakceptował milcząco, nawet jeśli merytorycznie była bezzasadna. To zupełnie inna kategoria błędu niż spóźniona faktura czy niewysłany newsletter.

W małych firmach reklamacje wpadają zwykle trzema, czterema różnymi kanałami naraz: skrzynka biurowa, formularz na stronie, czasem telefon spisywany „na kartce”, do tego panel sprzedażowy Allegro albo innego marketplace'u. Termin biegnie od momentu zgłoszenia niezależnie od tego, czy ktoś akurat zauważył wiadomość w zalanej skrzynce. To jest dokładnie ten typ procesu, w którym pojedyncze przeoczenie kosztuje realne pieniądze, a nie tylko traci się trochę czasu.

Co faktycznie liczy się do 14 dni

Podstawą jest art. 561⁵ Kodeksu cywilnego: jeśli konsument zażądał wymiany towaru, usunięcia wady albo obniżenia ceny z podaną kwotą, a sprzedawca nie ustosunkował się do żądania w terminie 14 dni, uznaje się, że żądanie uznał za uzasadnione. To domniemanie działa na niekorzyść sprzedawcy automatycznie, bez żadnego dodatkowego postępowania. Termin liczy się w dniach kalendarzowych, nie roboczych, więc weekend i święta go nie zatrzymują.

W praktyce firmowej dorzuca się do tego jeszcze oczekiwania wynikające z regulaminów sklepów czy zasad marketplace'ów, które często powtarzają ten sam 14-dniowy standard jako dobrą praktykę, nawet tam, gdzie formalnie zastosowanie mają inne przepisy ustawy o prawach konsumenta. Dla uproszczenia procesu w firmie przyjmujemy jeden, najbardziej rygorystyczny termin jako wewnętrzny SLA: 14 dni kalendarzowych od wpływu zgłoszenia, liczone od dnia następnego. To eliminuje dyskusje „czy ta konkretna reklamacja podlega pod 14, czy pod 30 dni” i upraszcza logikę automatu.

Gdzie najczęściej gubią się zgłoszenia

Zanim zaczniemy budować cokolwiek w n8n czy Make, sprawdzamy u klienta jedną rzecz: ile kanałów faktycznie przyjmuje reklamacje i czy ktokolwiek ma pełny obraz wszystkich naraz. Typowy obrazek w małej firmie handlowej wygląda tak: reklamacje z maila biurowego czyta osoba X, z formularza na stronie dostaje powiadomienie osoba Y, a z panelu Allegro nikt nie sprawdza regularnie, bo „wpada tam rzadko”. Termin biegnie identycznie we wszystkich trzech przypadkach, tylko świadomość tego terminu jest rozproszona między ludźmi, którzy często nie wiedzą nawzajem o swoich zgłoszeniach.

Drugi częsty problem to brak jednego miejsca, w którym widać datę wpływu. Reklamacja leży w skrzynce mailowej, ktoś ją przeczyta za tydzień, bo akurat był urlop, i wtedy dopiero „zaczyna” liczyć czas od momentu przeczytania, a nie od faktycznej daty wpływu. To błąd, który w kontroli czy sporze sądowym kosztuje firmę wiarygodność, bo data w nagłówku maila jest dowodem, niezależnie od tego, kiedy ktoś go otworzył.

Pipeline: jak to budujemy w n8n lub Make

Nasze podejście do tego konkretnego procesu zawsze ma te same cztery elementy, niezależnie od branży klienta: rejestrację zgłoszenia w jednym miejscu, automatyczny licznik dni, eskalację przed upływem terminu i log dowodowy. Dopiero na tej bazie dokładamy szczegóły specyficzne dla danej firmy.

1. Rejestracja zgłoszenia

Każdy kanał, mail, formularz, webhook z marketplace'u, podłączamy do jednego miejsca docelowego, zwykle arkusza Google Sheets, Airtable albo tabeli w systemie sprzedażowym, jeśli klient już takiego używa. Automat w n8n nasłuchuje skrzynki (filtr po temacie lub skrzynce dedykowanej reklamacjom), wyciąga dane zgłaszającego, numer zamówienia, treść i, co najważniejsze, dokładny znacznik czasu wpływu. Ten sam mechanizm podpinamy pod formularz na stronie i webhook z panelu sprzedażowego, jeśli API na to pozwala. Efekt: niezależnie skąd przyszło zgłoszenie, ląduje w jednym rejestrze z jednym formatem daty.

2. Licznik dni i status

Każdy wiersz w rejestrze dostaje automatycznie wyliczoną datę graniczną (data wpływu plus 14 dni kalendarzowych) oraz status liczony dynamicznie: „nowe”, „w toku”, „zostało X dni”, „po terminie”. To nie jest skomplikowana logika, ale właśnie dlatego tak dobrze nadaje się do automatyzacji: prosty, powtarzalny rachunek, który człowiek robi niechętnie i z błędami, bo nikt nie chce codziennie ręcznie liczyć dni dla dwudziestu otwartych spraw.

3. Eskalacja przed terminem

Tu dzieje się właściwa robota automatu. Ustawiamy progi: powiadomienie na Slacku lub mailem do osoby odpowiedzialnej, gdy zostały 4 dni robocze, drugie, ostrzejsze powiadomienie przy 2 dniach, i trzecie, które trafia już do właściciela lub kierownika, jeśli sprawa wciąż wisi na dzień przed terminem. W jednym wdrożeniu dla firmy handlowej taka trójstopniowa eskalacja wystarczyła, żeby w ciągu kilku miesięcy liczba reklamacji obsłużonych „na styk”, czyli w ostatnim dniu terminu, spadła niemal do zera, bo wcześniej ludzie po prostu nie widzieli, że zegar tyka, dopóki nie było za późno.

4. Log dowodowy

Każda zmiana statusu, każda wysłana odpowiedź do klienta, każde powiadomienie eskalacyjne zapisujemy z dokładnym znacznikiem czasu w osobnej zakładce lub tabeli historii. To jest element, który klienci najczęściej bagatelizują na etapie projektowania, a doceniają dopiero, gdy trafia się spór. Mając log z dokładnymi datami: kiedy zgłoszenie wpłynęło, kiedy ktoś odpowiedział, jaką treść wysłano, firma ma twardy dowód, że dotrzymała terminu, zamiast tłumaczyć się na pamięć miesiąc po fakcie.

Czego automat tu nie robi i dlaczego to dobrze

Automat w tym procesie pilnuje terminu i widoczności, ale nie ocenia reklamacji merytorycznie i nie wysyła samodzielnie decyzji do klienta. To świadoma decyzja projektowa, nie ograniczenie techniczne, bo dałoby się dołożyć moduł, który np. automatycznie odrzuca reklamacje bez paragonu. Nie robimy tego, bo ocena zasadności reklamacji to decyzja, która wymaga kontekstu: stanu towaru, historii klienta, czasem po prostu zdrowego rozsądku, którego akurat w tym miejscu nie chcemy oddawać maszynie. Automat robi może 70-80% roboty, czyli całe pilnowanie, przypominanie i dokumentowanie, ale ostateczna odpowiedź merytoryczna zawsze wychodzi od człowieka.

Druga rzecz, na którą zwracam uwagę klientom: automatyzacja nie zastąpi dobrego regulaminu reklamacji ani jasnej instrukcji, kto w firmie jest właścicielem procesu. Jeśli eskalacja trafia do kogoś, kto i tak nie ma uprawnień, żeby podjąć decyzję, cały mechanizm traci sens. Zanim zaczynamy wdrożenie, ustalamy z klientem, kto konkretnie odpowiada za każdy etap i co się dzieje, jeśli ta osoba jest na urlopie, bo właśnie wtedy najczęściej dochodzi do przeoczeń.

Jak to wygląda w praktyce przy wdrożeniu

Typowe wdrożenie tego pipeline'u w małej firmie zajmuje od kilku do kilkunastu godzin pracy, w zależności od liczby kanałów wejściowych i tego, czy system sprzedażowy ma sensowne API. Najwięcej czasu pochłania nie sama logika licznika dni, tylko integracja z marketplace'ami, bo nie każdy panel sprzedażowy udostępnia webhooki w wygodnej formie, czasem trzeba sięgnąć po scraping lub cykliczne odpytywanie API co kilka godzin zamiast powiadomień w czasie rzeczywistym.

Narzędziowo najczęściej używamy n8n, bo daje pełną kontrolę nad logiką i można go hostować samodzielnie, co ma znaczenie przy danych osobowych klientów zgłaszających reklamacje. Make sprawdza się równie dobrze przy prostszych konfiguracjach i krótszym czasie wdrożenia, kosztem mniejszej elastyczności przy bardziej nietypowych integracjach. Wybór narzędzia zależy od tego, ile kanałów trzeba spiąć i czy firma planuje w przyszłości rozbudowywać ten proces o kolejne automatyzacje, np. automatyzację obsługi klienta w szerszym zakresie, nie tylko reklamacji.

Jeśli firma sprzedaje głównie przez sklep internetowy i marketplace'y, ten sam pipeline zwykle łączymy z szerszym procesem zamówień i zwrotów, bo dane o reklamacji i tak trzeba zestawić z numerem zamówienia i historią klienta. W takich przypadkach projektujemy to razem z automatyzacją procesów e-commerce, żeby nie budować dwóch osobnych, niekomunikujących się systemów.

Koszt przeoczenia kontra koszt wdrożenia

Warto postawić te dwie rzeczy obok siebie wprost. Koszt wdrożenia pipeline'u to zwykle kilka-kilkanaście godzin pracy nad automatyzacją plus utrzymanie, które przy prostym procesie jest minimalne, bo nie ma tu skomplikowanych reguł biznesowych wymagających ciągłych poprawek. Koszt przeoczenia terminu to z kolei nie tylko domniemane uznanie reklamacji, które może oznaczać zwrot pieniędzy za towar, który był sprzedany prawidłowo, ale też utratę czasu na spór, ewentualne koszty prawnika, a czasem po prostu utratę klienta, który zapamięta firmę jako taką, co „olała” zgłoszenie. Przy nawet kilku reklamacjach miesięcznie ryzyko jednego przeoczenia w skali roku nie jest teoretyczne, tylko realne, zwłaszcza w sezonach wzmożonej sprzedaży, kiedy liczba zgłoszeń rośnie, a uwaga zespołu spada.