Jak AI może obsługiwać zagraniczne wysyłki w Sendcloud: statusy, wyjątki i zwroty bez angażowania zespołu

AI podłączone do Sendcloud może odpowiadać klientom z Niemiec, Francji czy Holandii w ich własnym języku, wysyłać alert wewnętrzny, gdy paczka dostanie status "Exception", i przypominać odbiorcy, że punkt odbioru zamknie się za dwa dni. To realne scenariusze, które da się uruchomić przez REST API Sendcloud bez modyfikowania sklepu ani zatrudniania dodatkowej osoby do obsługi wysyłek zagranicznych.

Jakie dane trzyma Sendcloud i co z nich wyciągamy do AI

Sendcloud zbiera w jednym miejscu dane ze wszystkich przewoźników, z którymi współpracujecie: numery śledzenia, statusy przesyłek, adresy odbiorców, nazwy punktów odbioru, historię zdarzeń. Każda paczka ma rekord z polami takimi jak parcel_id, tracking_number, carrier, status, country, to_name, to_email, expected_delivery_date i service_point.

Statusy mają własne kody numeryczne. Status 12 oznacza wyjątek (exception), 1000 to zwrot w drodze, 11 to doręczona, 10 to paczka czekająca w punkcie odbioru. Gdy paczka trafia do punktu, Sendcloud zapisuje też pole pickup_deadline, datę graniczną, do której odbiorca musi ją odebrać.

Do pracy z AI najbardziej przydają się cztery grupy danych:

• Przesyłki zagraniczne z wyjątkiem (status 12) i treść komunikatu od przewoźnika z pola carrier_messages.
• Paczki w punktach odbioru (status 10) z wypełnionym pickup_deadline, które zbliżają się do daty granicznej.
• Aktywne zwroty z portalu zwrotów Sendcloud, z polem return_reason i opcjonalnym komentarzem klienta.
• Adresy e-mail i kody krajów odbiorców przesyłek zagranicznych, gdy klient pyta o status przez czat sklepu lub e-mail.

To nie jest wszystko, co Sendcloud przechowuje, ale to te dane dają AI realny materiał do działania. Reszta to pola operacyjne przydatne przy generowaniu etykiet i obsłudze reguł wyboru przewoźnika, które na tym etapie nie są potrzebne.

Jak fizycznie podłączyć AI do Sendcloud: REST API, klucze, co producent udostępnia

Sendcloud udostępnia REST API w wersji 2. Żeby z niego korzystać, potrzebujecie konta z dostępem do API, który wchodzi od planu "Growth" wzwyż. Klucze generujecie w Ustawieniach konta, w sekcji "Integrations", przycisk "Add integration": dostajecie parę public_key i secret_key. Autentykacja działa przez HTTP Basic Auth, public_key jako login, secret_key jako hasło. Żadnych dodatkowych wniosków ani zgód po stronie Sendcloud nie trzeba składać.

Główne endpointy, z których korzystamy przy integracji z AI:

• GET /api/v2/parcels z filtrowaniem po statusie, dacie i kraju.
• GET /api/v2/parcels/{id} z pełną historią zdarzeń przesyłki.
• GET /api/v2/returns z listą zwrotów zgłoszonych przez portal zwrotów.
• GET /api/v2/statuses ze słownikiem kodów statusów, przydatnym przy pierwszej konfiguracji.

API zwraca JSON. Paginacja działa przez parametry limit i offset. Przy kilkuset przesyłkach dziennie nie ma problemów z wydajnością przy pollingu co kilka minut.

Sendcloud obsługuje też webhooki. Gdy skonfigurujecie webhook w panelu i wpiszecie adres swojego systemu, Sendcloud sam wyśle powiadomienie przy każdej zmianie statusu przesyłki. To szybsze niż regularne odpytywanie. Wymaga jednak, żeby wasz serwer był dostępny z zewnątrz pod stałym adresem. Dla sklepów, które nie mają takiej infrastruktury, polling co 5-10 minut spokojnie wystarczy.

Jedno ograniczenie warte uwagi przed startem: Sendcloud nie podaje wprost, dlaczego paczka dostała wyjątek. Szczegóły są zapisane w polu carrier_messages albo w historii zdarzeń przesyłki pod kluczem parcel_items[x].message. Te komunikaty są po angielsku, niekiedy technicznym angielskim przewoźnika. AI musi je przeczytać i dopiero na tej podstawie klasyfikuje, co się tak naprawdę stało z paczką.

Jak AI odpowiada klientom z zagranicy bez angażowania pracownika

Typowo wygląda to tak, że klient z Holandii pisze przez czat sklepu: "Where is my order?" Ktoś z obsługi musi wejść do Sendcloud, znaleźć paczkę po adresie e-mail lub numerze zamówienia, sprawdzić status i odpisać po angielsku. Albo sprawa czeka w kolejce, bo nikt nie zna angielskiego wystarczająco swobodnie, żeby pisać do klientów.

AI robi to inaczej. Klient podaje numer zamówienia lub adres e-mail. AI odpytuje Sendcloud po polu to_email albo po numerze zamówienia wpisanym w pole order_number przesyłki, wyciąga tracking_number, status, expected_delivery_date i carrier, a następnie odpowiada klientowi w jego języku. Pole country w danych przesyłki wskazuje, gdzie mieszka odbiorca: NL to holenderski, DE to niemiecki, FR to francuski, ES to hiszpański.

U jednego klienta obsługującego wysyłki do siedmiu krajów UE ustawiliśmy automat: gdy wiadomość od klienta zagranicznego zawiera numer zamówienia lub adres e-mail powiązany z przesyłką w Sendcloud, AI samo sprawdza status i odpowiada w języku klienta, bez angażowania polskiego pracownika. Ludzki pracownik dostaje tylko eskalacje, gdy AI nie znajdzie przesyłki albo gdy status jest wyjątkiem wymagającym kontaktu z przewoźnikiem.

Przy odpowiedziach wielojęzycznych ważny jest format daty. Pole expected_delivery_date w API Sendcloud zwraca datę w formacie ISO, np. 2026-11-20. Po holendersku to "20 november 2026", po niemiecku "20. November 2026". AI powinno to przetłumaczyć na lokalny format, a nie podawać surowe ISO. Drobna rzecz, a klient to czuje.

Ten sam mechanizm działa przy obsłudze zapytań o zwroty i reklamacje. Klient pisze, że odesłał paczkę. AI sprawdza endpoint /api/v2/returns po numerze zamówienia i odpisuje, jaki jest aktualny status zwrotu. Bez zaglądania do Sendcloud przez pracownika.

Jak wyłapać wyjątek, zanim klient pierwszy napisze skargę

Status 12 w Sendcloud to ogólny "Exception". Pod nim kryją się różne sytuacje: nieprawidłowy adres, nikt nie otworzył drzwi, przesyłka uszkodzona, brakujące dane celne przy wysyłce spoza UE. Przewoźnik zapisuje szczegóły w carrier_messages, ale te komunikaty są po angielsku, niekiedy łamanym technicznym angielskim: "Delivery attempted, recipient not at home", "Incorrect postcode", "Clearance delay - documents required".

AI czyta te komunikaty i klasyfikuje je na kategorie, każda z własną ścieżką:

• Problem z adresem: wysyłamy do klienta prośbę o weryfikację danych dostawy.
• Brak obecności odbiorcy: sugerujemy przekierowanie do punktu odbioru lub nową próbę dostawy.
• Problem celny: powiadamiamy wewnętrznie osobę odpowiedzialną za dokumenty eksportowe.
• Uszkodzenie: otwieramy wewnętrzny ticket i informujemy klienta o dalszych krokach reklamacyjnych.
• Nieznany powód: wyjątek trafia do ręcznej weryfikacji, a klient dostaje wiadomość, że sprawdzamy sytuację.

Bez tego monitorowania wyjątki albo czekają, aż klient sam napisze, albo ktoś raz dziennie przegląda listę przesyłek z wyjątkiem w panelu. Żaden przewoźnik nie poinformuje was aktywnie i z wyjaśnieniami. Paczka stoi, klient jest niezadowolony, a wy wiecie o tym za późno.

Filtrowanie przez API jest proste: GET /api/v2/parcels?statuses=12 zwraca tylko przesyłki z wyjątkiem. Dorzucacie filtr created_at_after z wczorajszą datą i macie nowe wyjątki z ostatniej doby, nie całą historię konta od początku.

Zwroty zagraniczne: co Sendcloud wie, a co przez nas przepada

Portal zwrotów Sendcloud to osobna domena, którą konfigurujecie w panelu: odbiorca wchodzi, wpisuje numer zamówienia, wybiera powód zwrotu z listy i drukuje etykietę od wskazanego przewoźnika. Dane z każdego zgłoszonego zwrotu trafiają do endpointu GET /api/v2/returns.

Każdy rekord zwrotu ma pola: order_number, return_reason ze standardowym kodem przyczyny ("not_as_expected", "defective", "wrong_product", "changed_mind", "too_late"), comment jako opcjonalny komentarz od klienta w jego języku, status i incoming_parcel z przewidywaną datą przybycia paczki z powrotem do waszego magazynu.

Typowy problem: klient pisze coś w polu comment po niderlandzku albo po niemiecku. Polskie biuro tego nie czyta, więc pół informacji przepada. AI przetłumaczy ten komentarz na polski i doda go do wewnętrznego ticketu albo do notatki przy zamówieniu w sklepie. To prosta rzecz, a dużo wnosi przy obsłudze zwrotów z kilku rynków naraz.

Drugie zastosowanie to analiza wzorców. AI może co tydzień zestawić powody zwrotów za ostatni miesiąc i zgrupować je według kraju i kategorii produktowej. Jeśli return_reason = "wrong_product" powtarza się przy konkretnej kategorii z Niemiec, to sygnał do sprawdzenia opisu produktu w niemieckiej wersji sklepu. Albo błędu przy kompletowaniu. Bez agregacji tych danych widzicie tylko kolejne zwroty, nie wzorzec, który za nimi stoi. I nigdy nie dojdziecie do przyczyny.

Paczki w punktach odbioru: kto pilnuje, że deadline się zbliża

Gdy odbiorca wybrał odbiór w punkcie (Packstation DHL, punkt DPD, punkt GLS, InPost Paczkomat za granicą), Sendcloud przypisuje do przesyłki obiekt service_point z adresem punktu oraz pole pickup_deadline z datą graniczną odbioru. Przewoźnicy mają różne okresy przechowywania. Zależy od przewoźnika i od kraju.

Gdy paczka zbliża się do końca tego okresu, a status nadal jest 10 (w punkcie, nieodebrana), AI wysyła przypomnienie do klienta. Alert ustawiamy na dwa dni przed pickup_deadline: odbiorca dostaje wiadomość, że paczka czeka i za dwa dni wróci do nadawcy. Zdarza się, że klient zapomniał albo zgubił powiadomienie od przewoźnika. Jedno przypomnienie potrafi zapobiec zwrotowi.

To jeden z przypadków, gdzie firmom najbardziej brakuje automatyzacji. Żaden przewoźnik nie wysyła wam zbiorczego raportu "te paczki stoją w punktach i za dwa dni wracają do was". Trzeba to samemu monitorować przez API. Bez automatu ta informacja ginie, a klient dostaje zwrot paczki, bo nikt go nie przypomniał na czas.

Małe ograniczenie techniczne warte sprawdzenia przy wdrożeniu: pole pickup_deadline nie zawsze jest uzupełnione przez Sendcloud od razu po przyjęciu paczki do punktu. Zależy od przewoźnika i od szybkości aktualizacji feedu trackingowego. Gdy pole jest puste, można oszacować deadline na podstawie daty przyjęcia paczki do punktu (zmiana na status 10) i standardowego czasu przechowywania danego przewoźnika. Ten czas wpisujecie ręcznie jako parametr w konfiguracji automatu, osobno dla każdego przewoźnika.

Od czego zacząć, żeby nie robić wszystkiego naraz

Zanim uruchomicie cokolwiek, sprawdźcie w Sendcloud trzy rzeczy:

• Plan subskrypcji: dostęp do REST API jest od planu "Growth" wzwyż. Sprawdźcie to w Ustawieniach konta, zanim zainwestujecie czas w konfigurację.
• Generujecie klucz API w: Ustawienia › Integracje › Sendcloud API, przycisk "Add integration". Dostajecie dwie wartości: public_key i secret_key.
• Sprawdźcie, z jakimi przewoźnikami macie aktywne umowy i czy trackingowe zdarzenia dla tych przewoźników pojawiają się faktycznie w polu carrier_messages. Niektóre tańsze integracje mają opóźnienia lub ograniczone dane zdarzeń.

Polecamy zacząć od jednego scenariusza, nie od wszystkich naraz. Najłatwiej startować z monitorowaniem wyjątków: małe ryzyko, szybki efekt, prosty filtr po API. Obsługa klientów wielojęzycznych to krok drugi, bo wymaga podpięcia kanału komunikacji (czat sklepu lub e-mail). Portal zwrotów i alerty pickup deadline to krok trzeci, gdy macie już działającą integrację i widzicie, że dane z API są wiarygodne na waszych przewoźnikach.

Wdrożenie takiej integracji u klienta z kilkuset wysyłkami tygodniowo zajęło nam od decyzji do działającego automatu kilkanaście dni. Większość czasu poszło na ustalenie, które kanały komunikacji z klientami podpinamy jako pierwsze, a nie na samą technikę.

Jeśli chcecie zobaczyć, jak wyglądałoby to u was konkretnie, zarezerwujcie 15 minut rozmowy. Mamy też realne wdrożenia, gdzie możecie sprawdzić, co i jak działało w firmach o podobnym profilu wysyłek.