Klient firmy logistycznej nie chce już dzwonić, żeby dowiedzieć się, gdzie jest jego paczka. Otwiera telefon, wpisuje numer przesyłki i oczekuje mapy, statusu oraz realnego ETA. Jeśli tego nie dostanie od Ciebie, znajdzie przewoźnika, który mu to da. Dlatego śledzenie przesyłek i portal klienta przestały być dodatkiem, a stały się częścią samej usługi logistycznej.
Z naszego doświadczenia wąskim gardłem rzadko bywa sam pomysł na funkcje. Trudność tkwi w tym, żeby zbudować track and trace, który uciągnie ruch, podłączy się do TMS i telematyki, a przy tym będzie zrozumiały dla klienta nietechnicznego. Nawet jeśli nie pokazujemy tu konkretnego wdrożenia w tej branży, dajemy ludzi i kompetencje, którzy takie systemy projektują i utrzymują, w modelu wzmocnienia zespołu lub zespołu dedykowanego.
Czego naprawdę oczekuje dziś klient firmy logistycznej?
Oczekiwania przesunęły się mocno w stronę samoobsługi: klient chce załatwić sprawę sam, o dowolnej porze, bez kontaktu z opiekunem. Przekłada się to na kilka twardych wymagań wobec oprogramowania.
- Widoczność w czasie rzeczywistym - gdzie jest przesyłka i co się z nią działo.
- Wiarygodne ETA - nie „do końca tygodnia”, tylko konkretne okno czasowe.
- Proaktywna informacja - powiadomienie zanim klient zacznie się niepokoić.
- Jeden punkt dostępu - portal, w którym widać wszystkie zlecenia, nie pojedyncze linki.
Spełnienie tych oczekiwań wyraźnie obniża ruch na infolinii, bo większość pytań „gdzie jest moja przesyłka” rozwiązuje się bez udziału człowieka.
Jak zaprojektować stronę śledzenia przesyłek (statusy, zdarzenia, ETA)?
Strona track and trace wygląda prosto, a pod spodem jest zdarzeniowa. Jej sercem jest historia zdarzeń przesyłki (event log): przyjęcie do magazynu, załadunek, przeładunek w hubie, wyjazd w trasę, doręczenie. Każde zdarzenie ma znacznik czasu, lokalizację i źródło, a na tej podstawie wyliczamy aktualny status i prognozowane ETA.
Projektujemy to tak, aby model danych oddzielał zdarzenie techniczne (surowy skan, telemetria) od statusu prezentowanego klientowi. Dzięki temu dokładamy nowe źródło danych albo zmieniamy nazewnictwo statusów bez przebudowy całego ekranu. ETA liczymy na danych historycznych i bieżącej pozycji pojazdu, a nie na sztywnym planie, bo tylko wtedy prognoza ma wartość.
Jak zbudować portal klienta i portal partnera (uwierzytelnianie, role)?
Portal to miejsce, w którym klient loguje się do pełnego obrazu swoich zleceń, a partner lub przewoźnik widzi tylko swój wycinek. Kluczowe są tu uwierzytelnianie i role, bo od nich zależy, kto co zobaczy.
- Uwierzytelnianie - logowanie e-mail/hasło, logowanie firmowe (SSO, OAuth) i opcjonalnie drugi składnik.
- Model ról (RBAC) - nadawca, odbiorca, spedytor, przewoźnik, administrator konta.
- Wielopodmiotowość - jeden portal obsługuje wiele firm klienckich, z rozdzieleniem danych.
- Uprawnienia do danych - klient widzi swoje zlecenia, partner swoje zadania, nikt cudzych.
Największą pułapką jest tu nie wygląd, tylko poprawne odcięcie danych między podmiotami, dlatego rozdział uprawnień projektujemy od pierwszego dnia.
Jak obsłużyć potwierdzenia dostaw (POD: podpis, zdjęcie, geolokalizacja)?
Potwierdzenie dostawy (Proof of Delivery) zamyka cykl życia przesyłki i bywa dowodem w sporach. Dziś rzadko jest to papier. Kierowca potwierdza doręczenie w aplikacji mobilnej, a system zbiera komplet dowodów i przypina je do zlecenia.
Składa się na to zwykle podpis odbiorcy na ekranie, zdjęcie paczki lub miejsca pozostawienia oraz geolokalizacja i znacznik czasu z momentu doręczenia. Projektujemy to z myślą o pracy offline, bo kierowca w trasie regularnie traci zasięg. Aplikacja zapisuje POD lokalnie i synchronizuje go z backendem po odzyskaniu połączenia, żeby żaden dowód nie przepadł, a gotowe potwierdzenie ląduje w portalu klienta jako element historii przesyłki.
Jak zrobić powiadomienia i alerty wyjątków (zdarzenia)?
Dobry track and trace nie czeka, aż klient sam sprawdzi status, tylko wysyła sygnał, gdy dzieje się coś istotnego. Warto rozdzielić dwa rodzaje komunikatów: rutynowe powiadomienia o postępie i alerty o wyjątkach, czyli sytuacjach wymagających reakcji.
- Powiadomienia o zdarzeniach - przyjęcie, wyjazd w trasę, „dziś na doręczeniu”, doręczono.
- Alerty wyjątków - opóźnienie, nieudane doręczenie, uszkodzenie, utknięcie w odprawie.
- Kanały - e-mail, SMS, push w aplikacji, a dla klientów systemowych webhook.
- Reguły - kto dostaje jaki alert i po jakim czasie następuje eskalacja.
Alerty budujemy na tym samym strumieniu zdarzeń, który zasila stronę śledzenia. Jedno źródło prawdy obsługuje ekran i powiadomienia, więc klient i operator widzą to samo.
Jak podłączyć to do TMS i telematyki?
Portal jest tak dobry, jak dane, które do niego wpływają, a te rzadko powstają w samym portalu. Realną pracą jest więc integracja z systemem TMS i z telematyką pojazdów: z TMS pobieramy zlecenia, trasy i statusy operacyjne, a z telematyki i urządzeń kierowców pozycję GPS oraz zdarzenia z trasy.
Spinamy te źródła warstwą integracyjną, zwykle przez API i webhooki, a przy wymianie wsadowej także przez pliki (EDI, CSV). Istotne jest ujednolicenie: różni przewoźnicy i różne urządzenia opisują te same zdarzenia inaczej, więc mapujemy je na wspólny słownik statusów, zanim trafią do klienta. Dzięki temu portal pokazuje spójny obraz niezależnie od liczby źródeł.
Jakie kompetencje dostarczamy do takiego projektu?
Skład dobieramy pod konkretny zakres, a nie „na zapas”. Projekt track and trace łączy backend zdarzeniowy, aplikację mobilną i integracje, więc zwykle potrzeba zespołu obejmującego kilka ról.
- Backend developer budujący model zdarzeń, API i logikę statusów oraz ETA.
- Frontend developer składający portal klienta i stronę śledzenia.
- Mobile developer odpowiadający za aplikację z POD i pracą offline.
- Specjalista od integracji spinający TMS, telematykę i wymianę danych z partnerami.
- DevOps stawiający chmurę, CI/CD i monitoring pod ruch produkcyjny.
Te role obsadzamy specjalistami zweryfikowanymi przed startem. Opcjonalnie dokładamy warstwę AI/Data (w Grupie RITS kompetencje LLM/dane rozwijają nasze zespoły AI/Data) do prognozy ETA czy wykrywania anomalii w trasie, ale traktujemy to jako kompetencję, a nie gotowe pudełko.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, z doświadczeniem w projektach przemysłowych i systemach łączących urządzenia, chmurę i aplikacje. Nie udajemy, że mamy w szufladzie gotowe wdrożenie track and trace, za to dajemy ludzi, którzy taki system zaprojektują i utrzymają razem z Twoim zespołem.
- Obsadzamy role pod specyfikację projektu, a kompetencje sprawdzamy przed wejściem.
- Wchodzimy w model wzmocnienia zespołu lub zespołu dedykowanego, zależnie od tego, czy masz już trzon zespołu.
- Pracujemy w zbliżonej strefie czasowej, więc przeglądy kodu i spotkania idą bez długiego rozruchu.
- Projektujemy track and trace end-to-end: od strumienia zdarzeń, przez POD, po integracje.
Przy nowym produkcie częściej jest to projekt dedykowanego oprogramowania, a przy rozwoju istniejącego portalu wzmocnienie zespołu. Różnice między tymi modelami rozpisaliśmy w artykule o modelach współpracy IT.
Od czego zacząć budowę śledzenia i portalu?
Zacznij od jednego pytania, które najczęściej trafia na infolinię („gdzie jest moja przesyłka i kiedy dojedzie”). Odpowiedź na nie wyznacza minimalny model zdarzeń, pierwszy ekran track and trace i integrację, która musi powstać najpierw. Resztę portalu dokładasz warstwami, gdy fundament już działa.
Budujesz śledzenie przesyłek albo portal klienta w logistyce? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój track and trace.