Agent AI dla e-commerce - zamówienia, zwroty i reklamacje pod kontrolą

Agent AI w sklepie internetowym może przygotować odpowiedź na pytanie o zamówienie, zebrać informacje do reklamacji i przekazać operatorowi sprawę z aktualnym statusem. Pierwszy zakres warto oprzeć na odczycie danych i szkicach zatwierdzanych przez obsługę. Zmiana zamówienia, decyzja reklamacyjna i zwrot pieniędzy wymagają osobnych uprawnień oraz kontroli wyniku operacji.

Dobry pierwszy proces może wyglądać tak: klient pyta o przesyłkę, system sprawdza jego prawo do danych, odczytuje status w sklepie i systemie dostaw, przygotowuje odpowiedź oraz zapisuje kontekst w helpdesku. Operator zatwierdza szkic albo przejmuje sprawę, jeśli informacje są niepełne lub sprzeczne.

Zakres automatyzacji powinien wynikać z liczby zgłoszeń, czasu pracy obsługi i kosztu pomyłek. Ten poradnik pomaga porównać możliwości obsługi zamówień, zwrotów i reklamacji oraz przygotować wdrożenie do odbioru. Korzyści trzeba zmierzyć na własnym procesie.

Czym różni się agent AI od chatbota w e-commerce

Agent ma kontrolowany dostęp do narzędzi: API sklepu, CRM, helpdesku, magazynu, systemu dostaw, bazy wiedzy i kolejki zadań dla ludzi. Każde połączenie trzeba opisać oddzielnie. Dostęp do odczytu zamówienia nie daje automatycznie prawa do zmiany adresu ani wypłaty pieniędzy.

Od którego procesu zacząć

Sprawdź ostatnie zgłoszenia i wybierz powtarzalną pracę, dla której istnieje wiarygodne źródło odpowiedzi. Jeśli większość pytań dotyczy godzin dostawy i instrukcji zwrotu, zacznij od poprawienia informacji w sklepie oraz szablonów. Połączenie z systemem zamówień przydaje się przy pytaniach o konkretną przesyłkę lub wcześniejszy kontakt.

Nazwy platform nie przesądzają o dostępnej integracji. Przed wyceną trzeba sprawdzić wersję sklepu, uprawnienia API, plan helpdesku i dozwolone operacje. Zakres BaseLinkera w sklepie internetowym pokazuje, jakie dane i wyjątki warto omówić przed połączeniem systemów. To opis zakresu do zaprojektowania, który wymaga sprawdzenia połączeń konkretnego sklepu.

Jak sprawdzić, którego zamówienia dotyczy rozmowa

Numer zamówienia znaleziony w wiadomości pomaga wyszukać rekord. Sam nie dowodzi prawa rozmówcy do jego danych. Mechanizm dostępu powinien korzystać ze sprawdzonej sesji klienta albo innej zatwierdzonej procedury weryfikacji. Nie przekazuj pełnego adresu dostawy tylko dlatego, że ktoś zna numer zakupu i nazwisko.

Fikcyjny przykład: klient odpowiada w starej rozmowie o butach, pytając o kurtkę kupioną miesiąc później. W cytowanym tekście pozostaje numer wcześniejszego zamówienia. System powinien wyjaśnić przypisanie przed przygotowaniem odpowiedzi. Po poprawieniu zamówienia operator musi zobaczyć nowy status i ponownie sprawdzić szkic.

Dane przewoźnika mogą być starsze niż ostatni wpis w sklepie. Pokaż źródło i czas odczytu obu informacji. Przy sprzeczności szkic powinien opisać ustalone fakty i brak potwierdzenia, bez dopisywania terminu doręczenia.

7 przepływów pracy, od których warto zacząć

1. Status zamówienia jako operacja tylko do odczytu

Po sprawdzeniu dostępu system może pobrać informacje potrzebne do konkretnego pytania:

• status zamówienia w platformie sklepu;
• status płatności, z ograniczeniem ujawnianych danych;
• status wysyłki i numer listu przewozowego;
• ostatni komunikat od operatora logistycznego;
• powiązane wcześniejsze kontakty w helpdesku.

Szkic powinien wskazywać, co potwierdzają źródła. Jeśli statusy się różnią, zamówienie obejmuje kilka przesyłek albo brakuje powiązania produktu z paczką, sprawa wymaga wyjaśnienia. Odczyt pozostawia zamówienie i płatność bez zmian. Termin dostawy można podać, gdy wynika z dostępnych danych.

2. Zwroty z regułami i akceptacją

Co do zasady konsument ma 14 dni na odstąpienie od umowy zawartej przez internet. Początek biegu terminu oraz wyjątki trzeba sprawdzić dla danej transakcji. Zakres prawa opisuje UOKiK.

Odstąpienie może nastąpić bez podania przyczyny. Formularz ani agent nie powinny uzależniać przyjęcia takiego oświadczenia od obowiązkowego pola „powód”. Dobrowolną odpowiedź do analizy asortymentu można zebrać oddzielnie, na przykład w kategoriach: rozmiar, uszkodzenie, niezgodność opisu, opóźnienie lub rezygnacja.

Praktyczny przebieg może obejmować:

1. Przyjęcie oświadczenia i ustalenie, którego zakupu oraz pozycji dotyczy.
2. Sprawdzenie daty doręczenia, produktu, ilości i wcześniejszych zwrotów. Dane faktury są potrzebne tam, gdzie służą rozliczeniu.
3. Zapis dobrowolnego powodu, jeśli klient chce go podać.
4. Przygotowanie sprawy w systemie zwrotów albo helpdesku.
5. Przygotowanie instrukcji lub etykiety w zatwierdzonym procesie, po sprawdzeniu dostępności tej operacji.
6. Przekazanie wyjątku do właściwej osoby wraz z danymi i powodem eskalacji.

W pierwszym zakresie operator zatwierdza odpowiedź i operacje zmieniające dane. Zgłoszenie zwrotu, przyjęcie paczki oraz refundacja to osobne zdarzenia. Wypłata pieniędzy wymaga własnej decyzji i potwierdzenia w systemie płatności.

3. Reklamacje i anulowanie według właściwej procedury

Reklamacja dotycząca niezgodności towaru z umową wymaga odrębnej obsługi. Agent może przygotować sprawę, zbierając:

• numer zamówienia i dane kontaktowe w zakresie potrzebnym do obsługi;
• produkt i wariant;
• opis problemu oraz dostępne materiały, na przykład zdjęcia lub wideo;
• żądanie klienta, na przykład naprawę, wymianę, obniżenie ceny albo zwrot pieniędzy;
• istotny kontekst z historii zakupu i wcześniejszego kontaktu.

Operator sprawdza dalszą procedurę oraz podejmuje decyzję. Nie ustawiaj paragonu jako jedynego możliwego dowodu zakupu. UOKiK wyjaśnia zasady reklamacji, w tym znaczenie innych dowodów. Wymagania formularza trzeba dopasować do sprawy, bez blokowania zgłoszenia dlatego, że klient nie dołączył preferowanego przez sklep załącznika.

Dobrze przygotowane zgłoszenie ogranicza ponowne pytania o informacje, które klient już przekazał. Przy brakach operator powinien widzieć, co wiadomo i co trzeba jeszcze wyjaśnić.

Anulowanie zamówienia przed realizacją wymaga sprawdzenia bieżącego stanu w systemie. W czasie rozmowy magazyn mógł już rozpocząć wysyłkę. Słowo „zwrot” w wiadomości nie wystarcza do wybrania operacji. Różnice rozwija poradnik o zwrotach, reklamacjach i anulowaniu.

4. Wiedza produktowa z RAG, oparta na źródłach

Odpowiedź o produkcie powinna wynikać z aktualnych materiałów sklepu:

• kart produktów i tabel rozmiarów;
• instrukcji producenta;
• regulaminów promocji;
• polityki dostaw i zwrotów;
• zatwierdzonych notatek obsługi.

RAG pozwala wyszukać fragmenty materiałów potrzebne do odpowiedzi. Przed wdrożeniem trzeba ustalić źródło prawdy, właściciela dokumentów, sposób aktualizacji indeksu i zachowanie przy brakujących danych.

Odpowiedzi powinny dotyczyć właściwego wariantu i aktualnej instrukcji. Wycofana karta produktu albo regulamin starej promocji muszą zostać rozpoznane przed użyciem. Brak danych o kompatybilności oznacza pytanie do obsługi lub producenta. Podobny opis innego produktu nie wystarcza do zapewnienia, że część będzie pasować.

Agent może wskazać rozmiar na podstawie tabeli i wymiarów podanych przez klienta. Taka podstawa pozwala wyjaśnić rekomendację, ale nie daje pewności dopasowania.

5. CRM i helpdesk jako pamięć operacyjna

Każda obsługiwana sprawa powinna zostawiać zapis pozwalający odtworzyć jej przebieg. Minimum to:

• utworzone lub zaktualizowane zgłoszenie;
• kanał kontaktu;
• identyfikator klienta i właściwego zamówienia;
• użyte źródła oraz czas odczytu;
• szkic, jego akceptacja i odpowiedź wysłana klientowi;
• wykonane operacje oraz ich potwierdzone wyniki;
• powód eskalacji i osoba odpowiedzialna za dalszą obsługę.

Jeśli sklep korzysta z Zendesk, Freshdesk, Intercomu, HubSpot, Salesforce, Pipedrive lub własnego CRM, trzeba sprawdzić dostępne operacje i uprawnienia w używanym planie. Historia sprawy powinna pokazywać, na jakich danych oparto odpowiedź i co wydarzyło się później.

6. Proaktywne komunikaty oparte na zdarzeniach

Przy opóźnieniu, braku magazynowym albo błędzie adresu agent może przygotować komunikat na podstawie zdarzenia z systemu. Warunki powiadomienia i wysyłki trzeba opisać przed uruchomieniem:

• zdarzenie z platformy sklepu lub systemu dostaw rozpoczyna proces;
• treść korzysta z zatwierdzonego szablonu i potwierdzonych danych;
• kanał wysyłki ma odpowiednią podstawę, z uwzględnieniem wymaganych zgód;
• komunikat zawiera tylko obietnice mające oparcie w źródłach;
• wyjątek trafia do kolejki obsługi.

W pierwszej wersji operator zatwierdza treść i wysyłkę. Dotyczy to także SMS-ów, e-maili i komunikacji przez Messenger. Dodanie oferty sprzedażowej do powiadomienia operacyjnego wymaga osobnego sprawdzenia zasad komunikacji marketingowej i zgód klienta.

7. Panel operatora i kontrola spraw

Zespół potrzebuje miejsca, w którym zobaczy:

• aktywne sprawy i ich właścicieli;
• szkice oraz operacje oczekujące na akceptację;
• eskalacje i brakujące informacje;
• błędy integracji;
• powody zatrzymania lub odmowy działania;
• koszt i czas odpowiedzi;
• odpowiedzi wymagające poprawy.

Przy wyborze technologii, na przykład LangGraph, n8n, OpenClaw czy Hermes Agent, trzeba osobno ustalić sposób przechowywania stanu, akceptacji, logowania i obsługi awarii. Sam wybór narzędzia nie rozstrzyga tych wymagań. Dostępność konkretnego połączenia oraz zakres przekazania do utrzymania należy sprawdzić w projekcie.

Co agent może robić sam, a co wymaga akceptacji

Uprawnienia warto podzielić według skutków działania. W proponowanej pierwszej wersji operator zatwierdza odpowiedzi i każdą operację zmieniającą zamówienie lub płatność. Dalsze rozszerzenie zakresu wymaga osobnego uzgodnienia i sprawdzenia.

Narzędzia powinny udostępniać małe, określone operacje. Zakres danych i skutków każdej z nich musi być ograniczony niezależnie od treści rozmowy. Dotyczy to szczególnie płatności, faktur i danych adresowych.

Jak kontrolować refundację i ponowienie

Akceptacja powinna wskazywać zamówienie, pozycje, kwotę, walutę i wersję danych. Zmiana ilości albo wcześniejszy częściowy zwrot wymaga ponownego sprawdzenia. Zgoda na wcześniejszy szkic nie powinna obejmować zmienionej operacji.

Utrata odpowiedzi z systemu płatności nie dowodzi, że refundacja się nie wykonała. Integracja powinna sprawdzić istniejący wynik i używać mechanizmu zapobiegającego powtórzeniu, jeśli dostawca go udostępnia. Sposób potwierdzenia trzeba zweryfikować w konkretnym API. Model nie powinien decydować o ponownej wypłacie na podstawie komunikatu o błędzie sieci.

Operator potrzebuje widoku spraw wstrzymanych, zapisanej zgody i odsyłacza do wyniku w systemie docelowym. Wiadomość „zwróciliśmy pieniądze” może powstać dopiero na podstawie potwierdzonej operacji. Sam zamiar wykonania refundacji nie wystarcza do takiego komunikatu.

Integracje e-commerce

Dla każdego połączenia trzeba ustalić, jakie dane są dostępne, skąd pochodzą identyfikatory i czy system może coś zmieniać.

Przy sklepach na Shopify, WooCommerce, PrestaShop, Magento, Shoper, IdoSell albo własnym backendzie trzeba sprawdzić wersję systemu, dostępność API i role. Lista nazw nie potwierdza gotowej integracji Syntalith ani obsługi każdej funkcji platformy.

Nie każdy sklep potrzebuje od razu połączenia z ERP. Pierwszy projekt może obejmować odczyt z platformy sklepu, system dostaw i przekazanie wyjątków do helpdesku. Ważne, żeby te systemy pozwalały jednoznacznie powiązać klienta, zakup, pozycję i przesyłkę.

Co sprawdzić przed uruchomieniem

Przygotuj oznaczony zestaw zgłoszeń z oczekiwanym wynikiem. Dodaj sprawy, które system ma oddać człowiekowi. Poniższa lista jest propozycją odbioru, a wykonanie prób trzeba zaplanować dla konkretnego sklepu:

• dwa zamówienia klienta w jednym wątku i numer tylko w cytowanej historii;
• osoba bez dostępu próbująca odczytać cudzy zakup;
• odstąpienie bez podanego powodu oraz reklamacja bez paragonu;
• zmiana statusu magazynu po przygotowaniu szkicu;
• częściowa refundacja istniejąca przed nową prośbą;
• utrata odpowiedzi po zapisie i ponowienie tego samego zadania;
• instrukcja w wiadomości nakazująca ujawnienie danych innego klienta.

Mierz poprawność przypisania spraw, czas kontroli szkiców i liczbę błędnych działań. Ustal z góry, które błędy blokują uruchomienie. Sam odsetek odpowiedzi wygenerowanych przez model nie mówi, czy sklep obsłużył zgłoszenie poprawnie.

RODO, retencja i AI Act

Agent do obsługi zamówień może przetwarzać dane kontaktowe, adresy, historię zakupu, treść rozmów i załączniki. Do wyjaśnienia statusu przesyłki nie trzeba przekazywać modelowi całej historii zakupów. Określ pola dopuszczone do odczytu, osoby mające dostęp do zapisów i czas przechowywania kopii roboczych. Zasady minimalizacji i retencji opisuje Europejska Rada Ochrony Danych.

Przed wdrożeniem ustal:

• kto jest administratorem danych, a kto podmiotem przetwarzającym;
• gdzie trafiają wiadomości, załączniki i odpowiedzi modelu;
• czy dochodzi do przekazania danych poza EOG;
• czy dostawca modelu wykorzystuje dane do trenowania;
• jak długo przechowywane są logi i transkrypty;
• jak usuwać lub anonimizować dane po okresie retencji;
• kto ma dostęp do historii spraw i narzędzi administracyjnych.

Okres przechowywania trzeba powiązać z celem i obowiązkami dotyczącymi danej kategorii danych. Logi techniczne, transkrypty, zgłoszenia reklamacyjne, dokumenty księgowe i ewentualne materiały do treningu wymagają osobnych decyzji. Sam dostęp do historii obsługi nie uprawnia do wykorzystania jej w dowolnym innym celu.

Klasyfikację według AI Act trzeba ocenić na podstawie przeznaczenia i sposobu użycia systemu. Opis agenta do zamówień nie stanowi oceny prawnej konkretnego wdrożenia. W projekcie warto zapisać przeznaczenie, ograniczenia, instrukcje użycia, nadzór człowieka, monitoring oraz sposób reakcji na incydent. Te elementy pomagają kontrolować system; formalne obowiązki wymagają odrębnego sprawdzenia.

Obserwowalność: co mierzyć po starcie

Mierz poprawność procesu i pracę pozostałą po stronie obsługi. Przydatne wskaźniki obejmują:

• odsetek spraw poprawnie zamkniętych bez eskalacji;
• odsetek spraw błędnie zamkniętych;
• czas do pierwszej odpowiedzi i czas rozwiązania;
• czas sprawdzenia oraz zakres poprawek szkiców;
• liczbę eskalacji z brakującymi danymi;
• koszt modelu i narzędzi na sprawę;
• liczbę błędów integracji;
• liczbę ręcznych korekt;
• powody zatrzymania lub odmowy wykonania operacji.

Porównuj wyniki z obsługą przed wdrożeniem na podobnych typach spraw. Potrzebne są zapisy rozmów i wywołań narzędzi w ustalonym zakresie. Operator powinien móc sprawdzić, które zamówienie odczytano, jaki status dostawy otrzymano i na jakiej wersji polityki oparto odpowiedź.

Gdzie są realistyczne limity

Agent AI nie naprawi samodzielnie:

• nieaktualnych stanów magazynowych;
• niespójnej polityki zwrotów;
• braku wspólnych identyfikatorów między systemami;
• źle skonfigurowanego helpdesku;
• opóźnień kuriera;
• procesu reklamacyjnego bez opisanej odpowiedzialności;
• konfliktu między regulaminem, praktyką obsługi i prawem konsumenckim.

Może wskazać brak danych, przygotować sprawę i zastosować zatwierdzoną procedurę. Sporne decyzje prawne, finansowe i reklamacyjne pozostają po stronie odpowiedzialnych osób. Warto ustalić, kto przejmuje sprawę przy awarii integracji oraz jak obsługa kontynuuje pracę.

Jak wygląda wdrożenie

Etap 1: mapa procesu. Wybieramy jeden pierwszy proces, a pozostałe zapisujemy do kolejnych etapów. Przy planowaniu można porównać 2-3 przypadki: status zamówienia, prosty zwrot i zebranie danych do reklamacji. Spisujemy systemy, wyjątki, progi eskalacji i odpowiedzialność.

Etap 2: dostęp do danych. Sprawdzamy API, role i tokeny, mechanizm weryfikacji klienta oraz dozwolone odczyty i zapisy. Ustalamy miejsce przechowywania logów i sposób potwierdzania operacji.

Etap 3: baza wiedzy. Porządkujemy FAQ, regulamin zwrotów, procedurę reklamacji, instrukcje produktów i szablony. Każde źródło potrzebuje właściciela i sposobu aktualizacji.

Etap 4: prototyp z ograniczeniami. Pracujemy na uzgodnionych danych testowych, w środowisku testowym albo w trybie szkiców. Obsługa sprawdza odpowiedzi, przypisanie zamówień i zachowanie przy wyjątkach.

Etap 5: produkcja z akceptacją. Pierwszy zakres obejmuje odczyt i przygotowanie spraw. Operator zatwierdza odpowiedzi oraz operacje zmieniające zamówienie lub płatność. Refundacje i sporne reklamacje mają osobne ścieżki decyzji.

Etap 6: monitoring i zmiany. Ustalamy regularny przegląd, na przykład co tydzień. Analizujemy błędy, odmowy, eskalacje i brakujące źródła. Rozszerzenie zakresu opieramy na wynikach oraz dodatkowych próbach odbioru.

Ile kosztuje wdrożenie w Syntalith

Cena zależy od zakresu procesu, dostępności danych, liczby integracji i skutków możliwych błędów. Przy porównywaniu ofert sprawdź, czy obejmują odpowiedzi na FAQ, odczyt konkretnych zamówień, przygotowanie zwrotów czy pracę z ERP. Każdy z tych zakresów ma inne wymagania.

Aktualne progi w cenniku Syntalith wynoszą:

To progi różnych usług. Pełna obsługa zamówień z płatnościami wymaga osobnej wyceny, sprawdzenia dostępu i testów. Stałą cenę konkretnego zakresu ustalamy po analizie danych i integracji, przed umową. Licencje sklepu i helpdesku, użycie modeli, hosting oraz utrzymanie należy uwzględnić oddzielnie.

Syntalith może przygotować wsparcie sprzedaży i obsługi dla powtarzalnych pytań o produkty, zamówienia i zwroty. Jeśli wystarczają odpowiedzi z FAQ, zakres może zakończyć się na uporządkowaniu wiedzy albo narzędziu dla pracownika. Obsługa konkretnego zakupu wymaga dodatkowo sprawdzenia dostępu, danych zamówienia, uprawnień i historii operacji.

Na stronie AI w e-commerce porównujemy możliwe zakresy pracy. Opisane scenariusze wymagają zaprojektowania i sprawdzenia dla konkretnego sklepu.

Dla kogo

Agent AI do operacji e-commerce ma sens, gdy:

• zespół regularnie odpowiada na powtarzalne pytania o status, zwroty i reklamacje;
• dane zamówień są dostępne przez API albo stabilny backend;
• firma ma spisane reguły obsługi i eskalacji;
• sprawy trafiają do wspólnego helpdesku lub CRM;
• właściciel procesu może oceniać odpowiedzi i decyzje;
• sklep może wdrażać kolejne uprawnienia stopniowo.

Przy kilku sprawach dziennie, częstych ręcznych poprawkach zamówień albo braku wiarygodnego źródła statusu warto najpierw uporządkować proces, FAQ i integracje. Uzasadnienie budowy powinno uwzględniać także czas kontroli szkiców, obsługi wyjątków i utrzymania systemu.

Plan wdrożenia obsługi zamówień

1. Wybierz jeden proces. Wskaż powtarzalne pytanie lub czynność i źródło poprawnej odpowiedzi.
2. Spisz decyzje człowieka. Określ, co system odczytuje, co przygotowuje, kto zatwierdza i jakie sprawy zawsze przejmuje obsługa.
3. Sprawdź dane i dostęp. Potwierdź API, role, identyfikatory między systemami oraz sposób weryfikacji klienta.
4. Uruchom pilotaż odczytu i szkiców. Sprawdź zwykłe sprawy, brak dostępu, zmianę danych i ponowienie operacji.
5. Mierz jakość, wolumen i koszt pracy. Uwzględnij czas kontroli, poprawki i eskalacje przed rozszerzeniem uprawnień.

Do rozmowy o wdrożeniu przygotuj kilka zanonimizowanych zgłoszeń, listę systemów i informację, kto dzisiaj zatwierdza zwroty. Na tej podstawie można wybrać pierwszy proces oraz zapisać warunki jego odbioru.

Zobacz ofertę wdrożenia agenta AI.

Powiązane artykuły

• Czym jest agent AI wykonujący pracę w systemach
• Ile kosztuje agent AI? Jak ocenić wycenę
• Co zautomatyzować w firmie? Wybierz pierwszy proces