Śledzenieprzesyłekwczasierzeczywistymiczegonaprawdęwymaga

Każdy przewoźnik opisuje paczkę inaczej. Jak sprowadzamy to do dziewięciu statusów, skąd biorą się aktualizacje i co celowo zostawiamy Tobie.

tutorials
Biała furgonetka dostawcza na wiejskiej drodze, uchwycona w ruchu w ujęciu z panoramowaniem

Zdjęcie: Jan Kopřiva na Unsplash

Pytanie „gdzie jest moje zamówienie?” to najdroższy e-mail, jaki dostaje sklep internetowy. Nie dlatego, że trudno na nie odpowiedzieć, ale dlatego, że odpowiedź oznacza wejście na stronę przewoźnika, wklejenie numeru, odczytanie duńskiego statusu, który znaczy coś nieco innego niż norweski, i przepisanie tego własnymi słowami.

Rozwiązaniem nie jest ładniejszy szablon e-maila. Jest nim faktyczny stan paczki we własnym systemie, w formie, która wygląda tak samo dla każdego przewoźnika, z którego korzystasz.

Dziewięć statusów, celowo

Każdy przewoźnik wymyśla własne słownictwo. My sprowadzamy je wszystkie do dziewięciu:

  • created, etykieta wysyłkowa istnieje, a przewoźnik o niej wie
  • awaiting_pickup, czeka na odbiór przez przewoźnika
  • picked_up, paczka jest u przewoźnika
  • in_transit, w drodze przez sieć przewoźnika
  • out_for_delivery, w samochodzie kuriera
  • ready_for_pickup, w punkcie odbioru, czeka na odbiorcę
  • delivered
  • returned
  • exception, coś poszło nie tak

Statusy delivered i returned są końcowe. Gdy paczka osiągnie jeden z nich, przestajemy odpytywać przewoźnika i nic nie może jej z niego wyprowadzić. Przewoźnik, który trzy dni później ponownie wyśle stare zdarzenie, nie cofnie doręczenia paczki. Brzmi to oczywiście, dopóki nie zobaczysz, jak dzieje się to w cudzym systemie.

Dwie drogi, którymi docierają aktualizacje

Przewoźnicy dzielą się na dwa obozy i każdy obsługujemy na jego własnych zasadach.

Większość udostępnia API śledzenia przesyłek, więc je odpytujemy. Zadanie uruchamiane co godzinę pyta o wszystko, co nie osiągnęło jeszcze statusu końcowego, i mapuje to, co wróci.

Niektórzy sami wysyłają dane (push). Event Cast od Bring oraz Instabox, Budbee i Porterbuddy przesyłają zdarzenia na bieżąco. Subskrybujemy je w chwili nadania, a zdarzenia trafiają na adres URL wywołania zwrotnego.

Push jest lepszy i korzystamy z niego wszędzie, gdzie przewoźnik go oferuje. Obie ścieżki kończą się jednak w tym samym miejscu: w jednej usłudze, która usuwa zduplikowane zdarzenia, zapisuje je i aktualizuje przesyłkę, dzięki czemu historia przesyłki wygląda identycznie niezależnie od tego, jak została wypełniona. Nie musisz wiedzieć ani zastanawiać się, do którego obozu należy dany przewoźnik.

Czego celowo nie robimy

Nie wysyłamy e-maili do Twoich klientów. Nie ma strony śledzenia z marką Zippendo, która umieszczałaby naszą nazwę na dole Twojego procesu dostawy.

Zamiast tego dostajesz webhook tracking.updated przy każdej zmianie stanu przesyłki, a to samo zdarzenie jest dostępne w Klaviyo, Customer.io, Mailchimp, SendGrid, Zapier i Make. Wiadomość pozostaje Twoja: Twoje słowa, Twój szablon, Twoja domena nadawcza i Twoja decyzja, czy status „w doręczeniu” zasługuje na SMS.

Uważamy, że to właściwy podział. Ty znasz swoich klientów. My wiemy, gdzie jest paczka.

Od czego zacząć

Włącz webhook tracking.updated i skieruj go do czegoś, co zapisuje logi. Przez tydzień obserwuj, jak prawdziwe paczki przechodzą przez dziewięć statusów, zanim cokolwiek na tym zautomatyzujesz. Szybko przekonasz się, którzy przewoźnicy są rozmowni, a którzy milkną na dwa dni w połowie drogi, i warto to wiedzieć, zanim obiecasz klientowi przedział czasowy dostawy.

Tags

trackingcarrierswebhooksdoświadczenie klienta