Zwrot w sklepie internetowym bardzo często zaczyna się niewinnie: klient pisze „chcę oddać zamówienie”, pracownik prosi o numer zamówienia, później sprawdza datę zakupu, wysyła instrukcję, przepisuje dane do arkusza, zamawia etykietę kurierską, czeka na paczkę i na końcu przekazuje informację do księgowości albo ręcznie uruchamia zwrot płatności. Przy kilku zwrotach tygodniowo da się z tym żyć. Przy kilkudziesięciu dziennie powstaje osobny proces operacyjny, który kosztuje więcej, niż zwykle pokazuje raport sprzedażowy.
To właśnie tutaj pojawia się sensowny pomysł na usługę B2B: automatyzacja obsługi zwrotów w e-commerce, sprzedawana sklepom jako wdrożenie połączone z miesięcznym utrzymaniem. Nie chodzi o stworzenie kolejnego formularza „zwrot towaru”. Wartość zaczyna się wtedy, gdy formularz sam sprawdza zamówienie, kwalifikuje zgłoszenie, tworzy numer RMA, generuje dokumenty lub etykietę, aktualizuje status w systemach sklepu i kieruje do człowieka tylko przypadki, których automat nie powinien rozstrzygać.
Najpierw trzeba usunąć przepisywanie danych, a dopiero później budować „inteligentny” system
Najdroższym błędem przy automatyzacji zwrotów jest zaczynanie od chatbota albo AI. Jeśli pracownik nadal kopiuje numer zamówienia z wiadomości e-mail do panelu sklepu, następnie adres klienta do systemu kurierskiego i kwotę do operatora płatności, problem pozostaje praktycznie ten sam. Zmienia się tylko kanał kontaktu.
Pierwszym celem powinno być stworzenie jednego punktu wejścia dla zwrotu. Klient podaje np. numer zamówienia i adres e-mail wykorzystany podczas zakupu. System pobiera resztę danych automatycznie przez API sklepu, ERP albo system zarządzania zamówieniami.
Minimalny proces może wyglądać tak:
- klient rozpoczyna zwrot przez formularz na stronie sklepu,
- system identyfikuje zamówienie,
- sprawdza datę odbioru przesyłki i status zamówienia,
- pokazuje produkty kwalifikujące się do zwrotu,
- klient wybiera pozycje i liczbę sztuk,
- wybiera powód zwrotu,
- system nadaje zgłoszeniu numer RMA,
- klient otrzymuje instrukcję i — jeżeli sklep korzysta z takiego modelu — etykietę lub kod nadania,
- zgłoszenie trafia do panelu sklepu ze statusem np. „oczekuje na przesyłkę”,
- po przyjęciu paczki magazyn potwierdza towar,
- system przekazuje zaakceptowaną kwotę do modułu finansowego albo operatora płatności.
Dzięki temu dane o kliencie, produkcie, wariancie, cenie i płatności nie są przepisywane ręcznie. To ważniejsze niż efektowny interfejs.
Skalę oszczędności da się policzyć dość łatwo. Jeżeli sklep obsługuje 1000 zwrotów miesięcznie, a pracownik poświęca średnio 4 minuty na przepisywanie danych, wysłanie standardowej odpowiedzi i utworzenie wpisu w arkuszu, daje to około 66,7 godziny pracy miesięcznie. Przy pełnym koszcie godziny pracy wynoszącym przykładowo 45 zł jest to około 3000 zł miesięcznie wyłącznie na czynności, które nie wymagają decyzji człowieka.
Przy 3000 zwrotów ten sam model oznacza już około 200 godzin pracy, czyli praktycznie ponad jeden etat.
Dlatego przed wyceną wdrożenia warto przez tydzień zmierzyć cztery liczby:
- liczbę zgłoszeń zwrotu,
- średni czas pierwszej obsługi jednego zgłoszenia,
- liczbę systemów, do których trzeba przepisać dane,
- procent zgłoszeń wymagających faktycznej decyzji pracownika.
Jeżeli 70–90 proc. przypadków przechodzi według powtarzalnego schematu, automatyzacja zazwyczaj ma mocne uzasadnienie ekonomiczne. Jeśli natomiast większość zwrotów wymaga oględzin produktu, indywidualnej wyceny albo wyjaśnienia sporu z klientem, nie ma sensu obiecywać pełnej automatyzacji. Wtedy automat powinien przede wszystkim zbierać dane i porządkować kolejkę, a decyzję pozostawić człowiekowi.
Trzeba też rozdzielić dwa procesy, które w wielu sklepach są wrzucane do jednego worka: odstąpienie od umowy i zgłoszenie dotyczące niezgodności towaru z umową. Inne są podstawy obsługi, możliwe decyzje i odpowiedzialność za koszty. Jeśli formularz traktuje każde „chcę oddać produkt” identycznie, sklep prędzej czy później zacznie automatyzować błędne decyzje.
W standardowej sprzedaży internetowej konsument ma co do zasady 14 dni na odstąpienie od umowy, liczone w przypadku pojedynczego towaru od jego otrzymania. Po złożeniu oświadczenia sprzedawca powinien zwrócić otrzymane płatności nie później niż w ciągu 14 dni, ale może wstrzymać zwrot pieniędzy do momentu otrzymania rzeczy lub dowodu jej odesłania — zależnie od tego, które zdarzenie nastąpi wcześniej.
To oznacza, że automat nie powinien działać według reguły: „formularz wysłany = natychmiastowy zwrot pieniędzy”. Potrzebny jest warunek płatności, np. potwierdzenie przyjęcia przesyłki albo wiarygodny status nadania, zgodnie z polityką i sytuacją prawną sklepu.
Dobra automatyzacja zwrotów składa się z reguł, integracji i kolejki wyjątków
Najbardziej praktyczny model nie polega na automatyzowaniu wszystkiego. Polega na automatycznym przepuszczaniu prostych przypadków i zatrzymywaniu tych, w których występuje ryzyko.
Można przyjąć trzy ścieżki.
Ścieżka zielona obejmuje typowy zwrot: zamówienie istnieje, dane klienta się zgadzają, produkt kwalifikuje się do odstąpienia, liczba sztuk nie przekracza kupionej ilości, termin nie budzi wątpliwości. System może automatycznie przyjąć zgłoszenie i wygenerować dalsze instrukcje.
Ścieżka żółta obejmuje przypadki wymagające kontroli, np. zgłoszenie złożone na granicy terminu, brak zgodności danych, zwrot tylko części zestawu, produkt z nietypowej kategorii albo znaczna wartość zamówienia.
Ścieżka czerwona powinna zatrzymywać proces w przypadkach takich jak niezgodność numeru zamówienia, próba zwrotu większej liczby sztuk niż zakupiono, wcześniejszy zwrot tej samej pozycji albo sytuacja, w której automatyczne zaakceptowanie roszczenia mogłoby wygenerować stratę.
To właśnie kolejka wyjątków jest jednym z najważniejszych elementów dobrze zaprojektowanej usługi. Jeśli po wdrożeniu pracownik nadal przegląda każde zgłoszenie, nie jest to automatyzacja procesu, lecz cyfrowy formularz.
Technicznie taki system nie musi być od razu osobną aplikacją pisaną od zera. W mniejszym sklepie można zbudować pierwszą wersję z wykorzystaniem istniejącego silnika sklepu, webhooków, narzędzia integracyjnego oraz prostego panelu operacyjnego. Dopiero większa liczba zwrotów uzasadnia budowę własnej warstwy aplikacyjnej.
W polskich sklepach integracja najczęściej musi dotknąć kilku rodzajów systemów jednocześnie:
- platformy sprzedażowej, np. Shopify, WooCommerce, PrestaShop lub Shoper,
- systemu obsługi zamówień albo integratora marketplace,
- WMS lub ERP,
- operatora płatności,
- systemu kurierskiego,
- poczty albo helpdesku,
- księgowości lub systemu fakturowego.
Każda kolejna integracja zwiększa koszt projektu bardziej niż dodanie kolejnego pola do formularza.
Do wstępnego budżetu można przyjmować trzy poziomy projektu. Prosty proces oparty na gotowych integracjach i narzędziach no-code/low-code można kalkulować orientacyjnie na kilka tysięcy złotych za uruchomienie. Projekt obejmujący kilka systemów, własny panel i nietypowe reguły biznesowe częściej wchodzi w zakres kilkunastu–kilkudziesięciu tysięcy złotych. Dedykowana aplikacja obsługująca duże sklepy, wiele magazynów, marketplace’y i rozbudowane uprawnienia może przekroczyć ten poziom wielokrotnie.
Nie warto jednak wyceniać usługi wyłącznie na podstawie liczby ekranów. Znacznie lepszym parametrem jest liczba integracji, reguł i wyjątków, bo to one generują późniejsze problemy.
Przykładowo integracja z operatorem płatności wymaga rozwiązania kwestii:
- pełnego i częściowego zwrotu,
- kilku produktów zwracanych z jednego zamówienia,
- wcześniejszego częściowego refundu,
- rabatów obejmujących całe zamówienie,
- kosztów dostawy,
- płatności dzielonych,
- ponowienia operacji po błędzie API.
Tutaj pojawia się techniczny detal, który bywa pomijany: idempotencja. System musi zabezpieczać się przed wykonaniem tego samego zwrotu płatności dwa razy. Jeśli połączenie z operatorem płatności zerwie się po wysłaniu żądania, aplikacja nie może po prostu wysłać kolejnego identycznego polecenia bez sprawdzenia statusu pierwszej operacji.
To jedna z tych usterek, które na testowym zamówieniu za 79 zł wyglądają niewinnie, a przy większej skali mogą kosztować realne pieniądze.
Podobnie należy traktować automatyczne wiadomości. Klient nie powinien otrzymywać pięciu osobnych e-maili tylko dlatego, że system logistyczny zmienił pięć wewnętrznych statusów. Z perspektywy klienta istotne są zwykle cztery momenty: przyjęcie zgłoszenia, sposób odesłania, przyjęcie przesyłki oraz decyzja o zwrocie pieniędzy.
Usługa zarabia wtedy, gdy sprzedaje wynik operacyjny, a nie sam formularz
Najłatwiej sprzedać taki produkt jako „system zwrotów”. To jednocześnie jeden z najgorszych sposobów pozycjonowania usługi, bo klient natychmiast zaczyna porównywać liczbę funkcji i miesięczne ceny gotowych aplikacji.
Lepszym produktem jest usunięcie konkretnego fragmentu pracy ręcznej.
Przed rozpoczęciem projektu można więc policzyć obecny koszt procesu. Załóżmy:
- 1500 zwrotów miesięcznie,
- średnio 6 minut pracy administracyjnej przy jednym zgłoszeniu,
- 150 godzin pracy miesięcznie,
- koszt pracy 45 zł za godzinę.
Sama część administracyjna procesu kosztuje w takim przykładzie około 6750 zł miesięcznie. Jeśli po wdrożeniu liczba przypadków wymagających ręcznej obsługi spadnie do 25 proc., obciążenie zmniejszy się do około 37,5 godziny. Różnica wynosi ponad 110 godzin miesięcznie.
Nie oznacza to automatycznie oszczędności równej wartości tych godzin. Pracownik nie zawsze znika z listy płac. Zyskiem może być jednak brak potrzeby zatrudnienia kolejnej osoby w sezonie, szybsze odpowiadanie klientom albo przesunięcie zespołu do spraw, których nie da się rozwiązać regułą.
Właśnie dlatego model rozliczenia usługi powinien odpowiadać skali klienta. Sensowne są między innymi:
- jednorazowa opłata wdrożeniowa,
- miesięczna opłata za utrzymanie integracji,
- abonament zależny od liczby zwrotów,
- pakiet obejmujący określoną liczbę zmian reguł i integracji,
- wyższa opłata za SLA lub obsługę awarii.
Szczególnie ryzykowne jest oferowanie „nielimitowanego utrzymania” za stałe kilkaset złotych miesięcznie. API operatora płatności może się zmienić. Sklep może wymienić ERP. Firma kurierska może zmodyfikować format etykiety. Klient może uruchomić drugi magazyn. To nie są poprawki kosmetyczne.
Umowa powinna więc rozróżniać utrzymanie istniejącego procesu od prac rozwojowych.
Warto też ustalić, kto odpowiada za reguły prawne i handlowe. Wykonawca automatyzacji może zaimplementować zasadę wskazaną przez sklep, ale nie powinien samodzielnie wymyślać polityki zwrotowej klienta. Szczególnie dotyczy to kategorii produktów objętych wyjątkami od prawa odstąpienia, produktów wykonywanych według specyfikacji klienta czy przypadków związanych ze stanem zwracanego towaru.
Nie wszystko należy automatyzować.
Jeżeli automat ma sam zdecydować o odmowie zwrotu produktu wartego 4000 zł na podstawie jednego pola zaznaczonego przez klienta, ryzyko jest nieproporcjonalne do zaoszczędzonych kilku minut. W takim miejscu bardziej sensowne jest automatyczne skompletowanie dokumentacji i przekazanie sprawy pracownikowi.
Podobnie z AI. Model językowy dobrze nadaje się do klasyfikowania treści wiadomości, wyciągania numeru zamówienia albo przygotowania odpowiedzi na podstawie zatwierdzonych reguł. Nie powinien jednak swobodnie ustalać, czy klientowi należy się zwrot pieniędzy. Reguły finansowe i prawne powinny być deterministyczne, czyli możliwe do odtworzenia i sprawdzenia.
Trzeba też uwzględnić dane osobowe. System zwrotów nie potrzebuje całej historii klienta tylko dlatego, że API sklepu pozwala ją pobrać. Należy zapisywać dane potrzebne do obsługi zwrotu i ustalić zasady ich retencji. Kopiowanie pełnych danych zamówień do kolejnych arkuszy, skrzynek pocztowych i narzędzi automatyzacyjnych zwiększa liczbę miejsc, które później trzeba zabezpieczać i kontrolować.
Najbardziej irytujący etap takich wdrożeń pojawia się zwykle dopiero po uruchomieniu. Okazuje się, że proces opisany przez właściciela sklepu nie jest procesem rzeczywistym. Magazyn robi coś inaczej, księgowość czegoś nie zwraca automatycznie, część zamówień z marketplace’u nie ma takich samych identyfikatorów jak sklep, a pracownicy od lat obchodzą ograniczenie systemu własnym arkuszem Excela.
Dlatego pierwsza wersja automatyzacji powinna działać na jednym kanale sprzedaży, jednym magazynie i ograniczonej grupie zwrotów. Dopiero po przejściu kilkudziesięciu lub kilkuset rzeczywistych przypadków można rozszerzać proces.
Najgorszą decyzją jest uruchomienie jednocześnie pełnej automatyzacji dla sklepu, Allegro, Amazonu, dwóch magazynów i trzech operatorów płatności. Liczba kombinacji wyjątków rośnie wtedy szybciej niż liczba samych integracji.
FAQ – automatyzacja zwrotów w sklepie internetowym
Czy mały sklep internetowy potrzebuje osobnego systemu zwrotów?
Nie zawsze. Przy kilku lub kilkunastu zwrotach miesięcznie wystarczy dobrze przygotowany formularz połączony z systemem zamówień i automatycznymi wiadomościami. Własny panel zaczyna mieć większy sens wtedy, gdy obsługa zwrotów zajmuje zespołowi regularnie kilka lub kilkanaście godzin miesięcznie albo wymaga przepisywania danych pomiędzy kilkoma systemami.
Czy zwrot pieniędzy można uruchamiać automatycznie od razu po wypełnieniu formularza?
Technicznie tak, ale w wielu procesach byłby to zły pomysł. Sprzedawca może w określonych sytuacjach wstrzymać zwrot płatności do chwili otrzymania rzeczy albo dowodu jej odesłania. Bezpieczniejszy proces wiąże refund z określonym statusem przesyłki lub potwierdzeniem magazynu.
Czy klient zawsze ma 14 dni na zwrot zakupionego przez internet produktu?
Nie. Czternaście dni jest podstawową zasadą przy odstąpieniu od umowy zawartej na odległość, ale istnieją ustawowe wyjątki. Dlatego automat nie powinien kwalifikować zwrotu wyłącznie na podstawie daty zakupu. Musi uwzględniać także rodzaj produktu i charakter transakcji.
Kto pokrywa koszt przesyłki zwrotnej?
Przy zwykłym odstąpieniu od umowy bezpośredni koszt odesłania rzeczy co do zasady ponosi konsument, jeżeli został o tym prawidłowo poinformowany. Inaczej należy traktować sytuacje dotyczące niezgodności towaru z umową. System powinien rozpoznawać te ścieżki, zamiast generować identyczną etykietę dla każdego zgłoszenia.
Czy można zbudować taki proces w Make, Zapierze lub podobnym narzędziu?
Tak, szczególnie jako pierwszą wersję. Problem zaczyna się przy dużej liczbie operacji, skomplikowanych wyjątkach, krytycznych refundach i wymaganiu pełnego audytu działań. Wtedy logikę finansową lepiej przenieść do własnej aplikacji lub stabilnej warstwy backendowej, zamiast opierać ją na długim łańcuchu automatyzacji no-code.
Czy AI jest potrzebne do automatyzacji zwrotów?
Nie. Większość wartości daje integracja systemów i poprawne reguły. AI przydaje się dopiero później, np. do klasyfikowania nietypowych wiadomości klientów, rozpoznawania powodów zwrotów albo przygotowywania odpowiedzi. Nie powinno zastępować jednoznacznych reguł dotyczących pieniędzy.
Ile powinno trwać pierwsze wdrożenie?
Prosty pilotaż obejmujący formularz, pobranie zamówienia, numer RMA, wiadomości i jedną–dwie integracje można planować w skali kilku tygodni pracy. Rozbudowany projekt z ERP, WMS, płatnościami, przewoźnikami i obsługą marketplace’ów wymaga osobnej analizy integracji i testów. Najwięcej czasu zwykle zabierają nie ekrany aplikacji, lecz przypadki wyjątkowe i uzgodnienie odpowiedzialności pomiędzy systemami.
Jak mierzyć, czy automatyzacja faktycznie się opłaciła?
Najlepsze wskaźniki to czas ręcznej obsługi jednego zwrotu, procent zgłoszeń przechodzących bez udziału pracownika, liczba błędów w refundach oraz czas od zgłoszenia do zamknięcia sprawy. Sama liczba obsłużonych formularzy niewiele mówi.
Pierwszym krokiem nie powinien więc być zakup platformy ani budowa aplikacji. Weź 50 ostatnich zwrotów i rozpisz każdą czynność wykonywaną przez człowieka od pierwszej wiadomości klienta do refundu. Zaznacz, gdzie dane są przepisywane, gdzie wysyłana jest zawsze ta sama odpowiedź i gdzie naprawdę potrzebna jest decyzja.
Najpierw usuń ręczne kopiowanie danych pomiędzy systemami. Następnie automatyzuj standardowe komunikaty i statusy. Dopiero na końcu dotykaj decyzji finansowych oraz przypadków wymagających interpretacji. Taka kolejność daje największą redukcję pracy przy najmniejszym ryzyku, że źle zaprojektowany automat zacznie po prostu wykonywać błędy szybciej niż człowiek.
Więcej informacji na: https://hd-biznes.com/blog
