Adam zadzwonił na początku roku z prostym pytaniem: czy da się zrobić narzędzie, które policzy mu trasę zanim odbierze telefon od klienta.
Nie chodziło o GPS. Chodziło o to żeby zanim klient powie "mam ładunek z Lublina do Hamburga", Adam miał już w głowie liczby - dystans, szacowany czas jazdy, orientacyjny koszt. Żeby rozmawiał ze świadomością, nie zaczynał od kalkulowania w głowie podczas rozmowy.
W transporcie drogowym ta pierwsza minuta dużo kosztuje. Kto się pomyli na wycenie - albo traci zlecenie (za drogo) albo traci pieniądze (za tanio). Bez żadnego narzędzia człowiek liczy "na oko" - pamięta kilka stałych tras, resztę szacuje. Przy 40 zapytaniach dziennie to nie jest dobra metoda.
Problem: wycena na żywo to hazard
W firmie transportowej jest kilka momentów które decydują o marży. Jednym z nich jest pierwsza odpowiedź na zapytanie klienta.
Klient pyta: "ile za fracht z Wrocławia do Mediolanu, 24 palety, plandeka, załadunek w środę?". Spedytor ma 30 sekund żeby powiedzieć coś sensownego. Nie żeby skalkulować do złotówki - ale żeby podać widełki, które nie odstraszą klienta i jednocześnie nie przykują firmy do nierentownej stawki.
Doświadczony spedytor zna na pamięć 20 stałych tras. Resztę interpoluje z tego co wie. Problem pojawia się gdy firma rośnie, zlecenia są coraz bardziej zróżnicowane, a nowi pracownicy nie mają jeszcze tego "czucia".
Artur z Jasek Transport - firma transportowa z którą pracuję od roku - pokazał mi kiedyś zestawienie. Kilkanaście procent wycen z poprzedniego kwartału wyszło poniżej kosztu. Część z nich przez błędy w szacowaniu trasy. Odległość z Google Maps zapamiętana "na oko", bez uwzględnienia opłat drogowych, bez realnego czasu jazdy dla ciężarówki (a nie osobowego).
To jest problem który da się rozwiązać narzędziem.
HERE API - dlaczego to, nie Google Maps
Gdy projektowałem kalkulator, pierwsza myśl była oczywista: Google Maps API. Wszyscy znają, dobrze udokumentowane, integracja z wieloma narzędziami.
Odrzuciłem to po kilku godzinach analizy.
Google Maps API w wersji dla deweloperów liczy trasy dla samochodów osobowych. Dla ciężarówki potrzebujesz innych parametrów: ograniczenia wysokości, wagi, zakazy wjazdu do stref miejskich, promy, tunele. Google ma Truck Routing w planach od lat, ale w momencie gdy to pisałem - nie działało na rynkach europejskich tak jak potrzebowałem.
HERE Maps to platforma stworzona dla logistyki. Nie jest to poboczna usługa firmy od wyszukiwarki - to produkt który od 30 lat trafia głównie do branży automotive i transportu. Ich Routing API ma natywną obsługę parametrów dla pojazdów ciężarowych: DMC, wysokość, szerokość, ładunek niebezpieczny. Trasa dla TIR-a wychodzi zupełnie inaczej niż dla osobówki przez te same punkty.
Drugi powód był finansowy. HERE oferuje darmowy tier do 250 000 zapytań miesięcznie. Dla kalkulatora w małej firmie transportowej - to z nadmiarem. Google Maps zaczyna liczyć znacznie wcześniej i drożej.
Trzeci: HERE ma API dla matrix routing - czyli liczenia wielu tras jednocześnie. Przydaje się gdy chcesz porównać kilka wariantów punktów załadunku albo sprawdzić parę tras naraz.
Jak działa kalkulator w praktyce
Spedytor wchodzi na prostą stronę. Wpisuje punkt załadunku i punkt rozładunku - może to być miasto, adres albo kod pocztowy. Wybiera typ pojazdu: solo, naczepa, chłodnia. Jeśli ładunek ma specyficzne parametry (ponadgabaryt, ADR), zaznacza checkbox.
Kliknie "Oblicz" i w ciągu 2 sekund widzi:
- Odległość w km (trasa dla TIR-a, nie osobówki)
- Szacowany czas jazdy bez przerw i z uwzględnieniem obowiązkowych postojów dla kierowcy
- Orientacyjny koszt paliwa przy aktualnych cenach (aktualizowanych raz dziennie z publicznego API GUS)
- Szacowana stawka frachtowa - czyli to co firma powinna zaproponować, żeby zarobić zakładaną marżę
To ostatnie jest wyliczane lokalnie, na podstawie parametrów które Adam ustawia sam w panelu adminstracyjnym: koszt km, docelowa marża, stawki za różne typy naczep. Kalkulator nie zgaduje - stosuje jego stawki do trasy którą policzył HERE.
Wynik można skopiować jednym kliknięciem. Spedytor ma liczby gotowe zanim podniesie słuchawkę albo odpisze na maila.
Co jest pod maską. Architektura bez tajemnic
To nie jest aplikacja z bazą danych, autoryzacją i złożonym backendem. Celowo robiłem to prosto.
Frontend: pojedynczy plik HTML z JavaScriptem. Formularz, logika walidacji, wywołanie API. Hostowany statycznie - bez serwera aplikacyjnego, bez frameworka.
Backend: Python Flask, dwa endpointy. Jeden przyjmuje zapytanie o trasę, wywołuje HERE Routing API, przetwarza odpowiedź i zwraca przeliczone wartości. Drugi serwuje aktualne ceny paliwa (pobierają się rano automatycznym cron-jobem z danych publicznych).
HERE API Key: jeden klucz, przechowywany w zmiennej środowiskowej na serwerze. Nie w kodzie, nie w froncie. Klient nigdy go nie widzi - wszystkie zapytania do HERE idą przez backend, nie bezpośrednio z przeglądarki.
Całość stoi na tanim VPS - 5 euro miesięcznie. Czas odpowiedzi poniżej 2 sekund dla trasy Europa Zachodnia.
Pisanie zajęło mi 3 dni robocze. Połowę z tego to konfiguracja HERE API i testowanie czy trasy dla TIR-ów wychodzą sensownie na kilku znanych trasach które Adam sprawdzał ręcznie.
Nie ma tu żadnej AI w rozumieniu modeli językowych. To klasyczna automatyzacja: API + trochę matematyki + prosta prezentacja wyniku. "AI" zaczyna się gdy do tego systemu podepniesz coś co interpretuje zlecenia z maili albo automatycznie proponuje optymalizację trasy dla kilku zleceń jednocześnie - ale to osobny temat.
Koszty: ile to kosztuje i od czego zależy
HERE API: darmowe do 250 000 zapytań miesięcznie. Jasek Transport robi kilkadziesiąt sprawdzeń dziennie - jesteśmy daleko od tego limitu. Powyżej progu: od 0,0005 USD za routing request. Przy 300 000 zapytań miesięcznie to 25 dolarów.
VPS: 5-6 euro miesięcznie. Wystarczy instancja z 1 vCPU i 1 GB RAM.
Mój czas: 3 dni na budowę, 1 dzień na wdrożenie i testy z Adamem, potem sporadyczne poprawki. Wycena takiego projektu u mnie: 3 000 - 5 000 PLN zależnie od zakresu. Są firmy które za to samo wezmą 15 000 i zbudują z React i mikroserwisami. Można, ale po co.
Utrzymanie: prawie zerowe. Coś się psuje raz na kilka miesięcy - zwykle po aktualizacji biblioteki albo gdy HERE zmienia coś w API. Godzina poprawki.
Łączny koszt rok po wdrożeniu: kilkaset złotych w utrzymaniu VPS i ewentualnych drobnych modyfikacjach.
Co to dało Adamowi po 3 miesiącach
Poprosiłem Adama o konkretne obserwacje po kwartale używania.
Pierwsze: zniknęły "wyceny z sufitu" u nowych pracowników. Mają narzędzie - używają go. Nawet jeśli i tak sprawdzają ręcznie dla pewności, mają punkt odniesienia.
Drugie: czas odpowiedzi na maile z zapytaniami skrócił się z kilku godzin do kilkudziesięciu minut. Wcześniej spedytor musiał liczyć, konsultować, oddzwaniać. Teraz widzi liczby od razu.
Trzecie - i to mnie zaskoczyło - narzędzie obnażyło kilka tras na których firma systematycznie zaniżała stawki. Nie dlatego że kalkulator "powiedział" że tanio - ale dlatego że spedytorzy zaczęli porównywać to co zaoferowali z tym co wychodzi z kalkulatora. I zobaczyli wzorzec.
Nie dam liczby "ile zaoszczędzili" bo nie mam wglądu w ich wyniki i Adam też tego nie mierzył wprost. Ale powiedział jedno zdanie które mi wystarczy: "teraz rozmawiam z klientami inaczej - wiem co mówię".
W branży gdzie marże są cienkie i każda rozmowa jest negocjacją, to jest wartość.
Czego kalkulator nie obejmie
Uczciwie: narzędzie liczy trasę. Nie liczy rzeczywistości.
Korki w trakcie podróży - HERE daje szacunek statystyczny, nie przewidzi wypadku na A1. Ceny frachtów na giełdach zmieniają się codziennie - kalkulator daje orientację, nie aktualną stawkę rynkową. Specyfika klienta - jeden klient płaci terminowo, inny generuje problemy - tego żadne API nie policzy.
Jest też ograniczenie techniczne: HERE Routing API działa dobrze dla tras z A do B. Dla skomplikowanych tras z kilkoma przystankami (załadunek w trzech miejscach, rozładunek w dwóch) logika robi się bardziej złożona i kalkulator nie obsługuje tego w obecnej wersji.
Adam wie o tych ograniczeniach. Kalkulator to pierwsza orientacja, nie ostatnie słowo.
Dla kogo ma sens, dla kogo nie
Ma sens jeśli:
- Masz firmę transportową lub spedycję i Twoi ludzie wyceniają trasy ręcznie lub z pamięci
- Zatrudniasz nowych pracowników i chcesz dać im narzędzie które wyrówna ich wiedzę
- Masz więcej niż 10 zapytań dziennie - poniżej tego ręczne kalkulowanie jest wystarczające
Nie ma sensu jeśli:
- Operujesz na 5 stałych trasach od lat - znasz je na pamięć lepiej niż API
- Korzystasz już z TMS (system zarządzania transportem) który ma wbudowany routing
- Twój problem to nie wycena, tylko coś innego - wtedy to narzędzie nie rozwiąże Twojego problemu
Mam też obserwację ogólniejszą. W transporcie jest dużo narzędzi które "mogą" robić routing. TMS, platformy giełdowe, arkusze Excel z formułami. Większość firm transportowych z którymi rozmawiałem ma przynajmniej dwa z tych narzędzi. I większość spedytorów i tak liczy w głowie albo na Google Maps, bo tamte narzędzia są za skomplikowane w codziennym użyciu.
Proste narzędzie które naprawdę używają - jest warte więcej niż rozbudowany system który stoi nieużywany.
Co mogę dla ciebie zrobić
Jeśli prowadzisz firmę transportową, spedycję lub jakikolwiek biznes gdzie Twoi ludzie codziennie szacują koszty tras - napisz do mnie.
Kalkulator frachtu to kilka dni pracy. Nie tygodnie, nie miesiące. Zależy od tego jak skomplikowany masz proces wyceny i co chcesz żeby narzędzie robiło poza podstawowym routingiem.
Możemy też porozmawiać szerzej o tym co można zautomatyzować w operacjach transportowych: obsługa zapytań z maili, raportowanie tras dla klientów, monitoring kosztów paliwa. Buduję takie rzeczy dla Jasek Transport od roku - jeśli chcesz zobaczyć co konkretnie i z jakim efektem, napisz.
Kontakt: j.cybulski@idea4me.pl
Czytaj też: wywiadzie o konkurencji w branży transportowej, jak sprawić żeby automatyzacja w firmie miała sens.
