AI dla e-commerce — automatyzacja obsługi zamówień i zwrotów

Większość ofert automatyzacji dla e-commerce zaczyna się od wyboru narzędzia. Naszym zdaniem to odwrotna kolejność: narzędzie jest ostatnią decyzją, a nie pierwszą, i dlatego tyle wdrożeń kończy się działającym panelem, do którego po miesiącu nikt nie zagląda. Punktem wyjścia nie jest więc pytanie, co model potrafi, tylko która czynność powtarza się w sklepie kilkadziesiąt razy dziennie i za każdym razem wygląda tak samo. Do automatyzacji nadają się procesy powtarzalne, opisane regułami i oparte na danych, które sklep już ma w swoim systemie. Agent AI radzi sobie tam, gdzie odpowiedź da się wyprowadzić ze stanu zamówienia, kartoteki produktu albo regulaminu, a wynik jego pracy da się sprawdzić. Im bardziej sprawa wymaga oceny handlowej, negocjacji albo decyzji o pieniądzach klienta, tym mniej sensu ma oddawanie jej maszynie bez nadzoru. Taką powtarzalną czynność opisujemy krok po kroku, a dopiero potem dobieramy narzędzie — i regularnie kończy się na tym, że wystarczy scenariusz w Make albo n8n, a model językowy jest potrzebny wyłącznie do zrozumienia treści wiadomości od klienta. Mówimy to również wtedy, gdy oznacza to mniejsze zlecenie dla nas, bo alternatywą jest sprzedanie Wam modelu językowego do zadania, które rozwiązuje zwykły warunek w scenariuszu.

Jest też sytuacja, w której odradzamy wdrożenie w ogóle. Jeżeli do sklepu przychodzi kilka wiadomości dziennie, a zwroty zdarzają się kilka razy w miesiącu, agent AI się nie zwróci — i powiemy to na pierwszej rozmowie, zamiast wystawić fakturę i zostawić Was z systemem do obsługi kilku spraw tygodniowo. Automatyzacja opłaca się tam, gdzie jest wolumen i powtarzalność; przy małej skali te same pieniądze więcej zrobią w sklepie, który po prostu nie generuje pytań: w czytelnych kosztach dostawy, uczciwym statusie magazynowym i regulaminie napisanym po ludzku. To mniej efektowna odpowiedź niż „wdrożymy Wam AI”, ale przy takiej skali uważamy ją za jedyną uczciwą.

• Odpowiedzi na pytania o status zamówienia, termin wysyłki i formę płatności — na podstawie danych z systemu sklepu, a nie domysłów modelu.
• Wstępna kwalifikacja zgłoszeń zwrotu i reklamacji: kompletność danych, numer zamówienia, zdjęcia, zachowany termin.
• Porządkowanie kartotek produktowych: warianty, rozmiary, parametry, wskazanie brakujących pól.
• Skracanie i tłumaczenie istniejących opisów do formatów wymaganych przez marketplace'y.
• Przygotowanie odpowiedzi na powtarzalne wiadomości, do zatwierdzenia przez zespół obsługi.
• Monitorowanie przesyłek i informowanie klienta o zmianie statusu w InPost albo DPD.

Nie nadają się do pełnej automatyzacji sprawy, w których błąd kosztuje pieniądze albo reputację: decyzje o zwrocie środków, indywidualne rabaty, spory z klientem, treści dotyczące bezpieczeństwa produktu i zgodności z prawem. W tych miejscach agent może przygotować materiał — zebrać historię zamówienia, wskazać zapis regulaminu, zaproponować treść odpowiedzi — ale zatwierdza człowiek. Znamy kontrargument: że to marnowanie potencjału i że model „przecież sobie poradzi”. Wybieramy mimo to wersję wolniejszą, bo koszt jednej głośnej pomyłki wobec klienta bywa wyższy niż oszczędność na wszystkich pozostałych, poprawnie obsłużonych sprawach — a płaci za nią Wasza marka, nie nasza. Taki podział jest też wygodny wdrożeniowo: łatwiej rozszerzać zakres automatyzacji, gdy proces działa poprawnie, niż wycofywać się z niego po incydencie z klientem.

Agent obsługuje zamówienia przez integracje: nie wie nic sam z siebie, tylko odpytuje systemy, w których dane realnie się znajdują. Brzmi banalnie, a jest to etap pomijany najczęściej — spotykamy rozwiązania, w których „inteligentna obsługa klienta” sprowadza się do modelu odpowiadającego z własnej wiedzy o sklepie, którego nigdy nie widział. Taki asystent robi dobre wrażenie dokładnie do pierwszego pytania o konkretną paczkę. Sensowne wdrożenie oznacza w praktyce połączenie sklepu z bramką płatności (Przelewy24, Stripe, BLIK, PayU), z przewoźnikiem (InPost, DPD) i z magazynem, a następnie zbudowanie warstwy, która z tych źródeł składa jedną odpowiedź. Klient pyta o paczkę — agent odczytuje numer zamówienia, sprawdza status płatności i status przesyłki, po czym odpowiada konkretem: co zostało nadane, kiedy i pod jaki adres. Gdy któregoś elementu brakuje albo dane są sprzeczne, zgłasza to zespołowi zamiast zgadywać. To jest różnica między automatyzacją a chatbotem, który brzmi pewnie i myli się bez ostrzeżenia.

Przy budowie mamy jedno twarde uprzedzenie: między własnym kodem a gotową platformą wybieramy platformę, dopóki się da. Scenariusz w Make albo n8n jest mniej efektowny niż napisany od zera mikroserwis i przyznajemy, że własny kod pisze się przyjemniej — ale to Wy płacicie za jego utrzymanie przez kolejne lata, a my nie chcemy być jedyną osobą, która rozumie, dlaczego integracja z kurierem przestała działać. Własny kod dokładamy tam, gdzie platforma naprawdę nie wystarcza: przy nietypowej logice, dużych wolumenach albo interfejsie akceptacji, którego nie da się złożyć z gotowych klocków. Ta kolejność jest tańsza dla klienta i mniej opłacalna dla wykonawcy, więc rzadko słyszy się ją w ofercie.

1. 01Mapa procesuSpisujemy krok po kroku, jak dziś wygląda obsługa wybranego typu zgłoszenia i kto podejmuje w nim decyzje.
2. 02Podłączenie źródeł danychUstalamy, skąd pochodzą statusy zamówień, płatności i przesyłek, i budujemy do nich dostęp — bramka płatności, przewoźnik, system sklepu.
3. 03Reguły i graniceDefiniujemy, co agent robi samodzielnie, co przekazuje człowiekowi i w jakich sytuacjach ma się zatrzymać oraz poprosić o pomoc. Tę listę wyjątków uważamy za ważniejszą od listy funkcji: to ona decyduje, czy z agenta da się korzystać bez ciągłego sprawdzania go.
4. 04Testy na danych historycznychPuszczamy agenta na zamkniętym zbiorze starych zgłoszeń i porównujemy jego odpowiedzi z tym, co zrobił zespół.
5. 05Uruchomienie z człowiekiem w pętliStart na części ruchu, z panelem akceptacji i logiem każdego działania, żeby dało się cofnąć zmianę i wskazać jej autora.

Po opłaceniu zamówienia sklep wystawia fakturę i tu automatyzacja spotyka się z obowiązkiem ustawowym. Krajowy System e-Faktur objął od 1 lutego 2026 r. przedsiębiorców, u których sprzedaż z VAT przekroczyła w 2025 r. 200 mln zł, a od 1 kwietnia 2026 r. pozostałych przedsiębiorców, w tym sektor MŚP (Ministerstwo Finansów, ksef.podatki.gov.pl). Dla sklepu oznacza to, że fakturowanie musi być przewidywalne i logowane: automat może przygotować dane do faktury i pilnować kompletności, ale format oraz moment wystawienia wynikają z przepisów, a nie z ustawień narzędzia. Uważamy, że akurat fakturowanie jest ostatnim miejscem, w którym warto być kreatywnym — jeżeli ktoś obiecuje, że jego narzędzie „samo załatwi zgodność”, to obietnica nie do dotrzymania, bo za wystawiony dokument odpowiada przedsiębiorca, nie dostawca oprogramowania.

Może przygotować projekt opisu, ale nie powinna być ostatnim ogniwem przed publikacją. Powiedzmy od razu rzecz, której klienci nie chcą słyszeć, bo o masowe generowanie opisów pytają nas najczęściej: katalog wypełniony hurtowo wyprodukowanym tekstem to najszybszy sposób, żeby wyglądać jak każdy inny sklep w kategorii. Wszyscy sięgają po te same modele i te same dane producenta, więc jedyna rzecz, która Was odróżniała — sposób opisania towaru — znika w ciągu jednego wieczoru. Mówimy to klientom, którzy przychodzą właśnie po tę usługę, i zwykle proponujemy odwrotność: mniej tekstów, ale pisanych przez człowieka tam, gdzie decyduje się sprzedaż, a automat do roboty mechanicznej. Z pracą mechaniczną model językowy radzi sobie dobrze: przepisze specyfikację producenta na zdania, ujednolici długość opisów w kategorii, przygotuje warianty tekstu pod rozmiary i kolory, skróci opis do limitu znaków marketplace'u. Problem zaczyna się tam, gdzie model uzupełnia luki: dopisuje parametr, którego nie było w karcie produktu, przypisuje certyfikat albo przesadza z obietnicą działania. Opis towaru jest elementem umowy z konsumentem i podstawą reklamacji — jeżeli obiecuje coś, czego produkt nie robi, konsekwencje ponosi sklep, nie narzędzie. Dlatego opisy generowane masowo bez korekty człowieka traktujemy jako ryzyko dla marki i dla zgodności, a nie jako oszczędność.

• Bezpiecznie: przepisanie parametrów z karty producenta na czytelny opis, bez zmiany treści merytorycznej.
• Bezpiecznie: warianty tekstu dla rozmiarów, kolorów i kompletów, gdzie różnica wynika z danych w kartotece.
• Bezpiecznie: skracanie i tłumaczenie istniejących opisów z zachowaniem parametrów technicznych.
• Ryzykownie: dopisywanie cech i zastosowań, których nie ma w karcie produktu.
• Ryzykownie: treści o zdrowiu, składzie, bezpieczeństwie, certyfikatach i zgodności — te wymagają weryfikacji u źródła.
• Ryzykownie: publikacja bez logu pokazującego, kto zaakceptował opis i kiedy.

Praktyczny układ wygląda tak: agent generuje opisy do kolejki roboczej, osoba odpowiedzialna za kategorię zatwierdza je pojedynczo albo pakietami, a system zapisuje, kto i kiedy zaakceptował treść. Przy dużych katalogach warto ustawić progi — na przykład automatyczna publikacja tylko dla produktów, w których wszystkie pola kartoteki są kompletne, a reszta trafia do przeglądu. Dzięki temu skala zostaje po stronie automatu, odpowiedzialność po stronie człowieka, a w razie sporu da się wykazać, na jakiej podstawie powstał opis. Wiemy, że to wolniejsze niż kliknięcie „generuj wszystko”, i część sklepów wybierze szybszą drogę. Naszym zdaniem różnica między tymi dwiema drogami nie ujawnia się w dniu publikacji, tylko przy pierwszej reklamacji dotyczącej treści opisu — a wtedy nikt nie pyta, które narzędzie tekst napisało, tylko kto go zatwierdził.

Wdrożenie zaczynamy od jednego procesu i pilotażu, a nie od przebudowy całej obsługi sklepu. To świadoma rezygnacja z większego zlecenia na starcie: duży projekt łatwiej sprzedać, ale znacznie trudniej udowodnić w nim, że cokolwiek zadziałało, bo wszystko zmienia się naraz. Pierwszy etap to warsztat: wybieramy proces, który powtarza się najczęściej, spisujemy go krok po kroku i ustalamy, po czym poznamy, że agent działa poprawnie. Drugi etap to dane i integracje — sprawdzamy, skąd pochodzą statusy zamówień, płatności i przesyłek oraz kto ma do nich dostęp. Trzeci to budowa: scenariusze w Make albo n8n, warstwa aplikacyjna w Next.js, React i TypeScript, hosting na Vercel. Czwarty to testy na danych historycznych i uruchomienie z człowiekiem w pętli. Wdrożenia agentów AI zaczynają się od 10 000 zł, a ostateczna wycena zależy od liczby integracji i wymagań wobec danych. Ceny nie podajemy przed warsztatem, bo byłaby zgadywaniem — a zgadnięta cena jest zawsze albo za wysoka dla Was, albo za niska dla nas i wtedy ktoś na niej oszczędza w trakcie.

Po uruchomieniu proces wymaga utrzymania: zmienia się regulamin, dochodzą nowe warianty produktów, przewoźnik zmienia format statusów, a bramka płatności aktualizuje API. To jest część, którą oferty wdrożeń AI przemilczają najchętniej — sprzedaje się moment uruchomienia, a kosztuje wszystko, co dzieje się po nim. Dlatego wdrożeniu towarzyszy opieka Wataha Care w trzech wariantach — Basic 100 zł, Pro 200 zł albo Premium 300 zł miesięcznie, zależnie od zakresu — i rozmawiamy o niej przed podpisaniem umowy, a nie kwartał później. Uczciwie dodajemy drugą rzecz: opublikowanego wdrożenia agenta AI w e-commerce jeszcze nie mamy, więc kupujecie u nas sposób pracy i 45 zrealizowanych projektów webowych, a nie sprawdzoną instalację z własnej branży. Dla sklepu jest to zaleta i ryzyko naraz i wolimy, żebyście wiedzieli o tym przed decyzją, a nie po niej. Pracujemy zdalnie w całej Polsce, a na spotkania dojeżdżamy w promieniu około 40 kilometrów od Radomska, czyli między innymi do Częstochowy (około 40 km drogą). Nie prowadzimy biura obsługi klientów — cała współpraca toczy się online, od warsztatu po przekazanie dokumentacji.