Jak AI łączy się z Google Maps i co robi z adresami klientów, trasami i czasem dojazdu?

Google Maps Platform udostępnia REST API, które można wprost podłączyć do asystenta AI. Podajecie adres klienta, asystent wyciąga z niego dokładne współrzędne geograficzne, sprawdza czas przejazdu i układa kolejność wizyt tak, żeby serwisanci nie jeździli przez całe miasto bez ładu. Do uruchomienia potrzeba konta Google Cloud z włączonymi usługami Maps i kluczem API: resztę konfiguruje asystent, a operatorzy widzą gotowe trasy w swoim systemie zleceń.

Jak fizycznie wygląda podłączenie: Google Maps Platform, klucz API i co dostajecie

Google Maps Platform to zestaw osobnych usług REST API, każda z własnym adresem endpointu i własnym sposobem rozliczania. Nie ma tu pliku wymiany, eksportu CSV ani bazy danych do podłączenia. Asystent wywołuje API przez HTTPS, wysyła adres lub listę punktów, a w odpowiedzi dostaje JSON z danymi geograficznymi.

Co trzeba mieć, żeby to uruchomić:

• Konto Google Cloud z aktywnym projektem i podpiętą metodą płatności. Google nalicza za każde zapytanie do API, więc konto bez karty kredytowej nie obsłuży produkcyjnego ruchu.
• Klucz API, generowany w Google Cloud Console w sekcji "Credentials". To string zaczynający się od "AIza...", który trafia do każdego zapytania. Warto od razu ograniczyć go do adresu IP serwera i do wybranych usług, żeby zablokować nieautoryzowane użycie.
• Włączone konkretne usługi: Geocoding API (adresy na współrzędne i odwrotnie), Routes API (następca starszego Directions API: trasy i czas przejazdu), Distance Matrix API (macierz czasu między listą punktów), Places API (wyszukiwanie i walidacja adresów).

Czego Google nie udostępnia: danych o ruchu do masowego pobrania, historycznej bazy adresowej na własny serwer ani możliwości offline. Każde obliczenie musi przejść przez ich API w czasie rzeczywistym. Jedyną legalną drogą do tych danych jest właśnie wywołanie API w momencie, gdy asystent tego potrzebuje. Jeden punkt, który warto sprawdzić przed uruchomieniem: projekt w Google Cloud musi mieć skonfigurowane "billing account". Bez tego API zwraca REQUEST_DENIED nawet przy poprawnym kluczu.

Co wyciągamy z każdego z tych API w praktyce:

• Geocoding API: wchodzi "ul. Nowy Świat 15, Warszawa", wychodzi latitude 52.2297, longitude 21.0218 i pole "formatted_address" z adresem znormalizowanym przez Google. Gdy adres jest niepewny, API zwraca "partial_match: true" i pole "location_type: APPROXIMATE" zamiast "ROOFTOP". To sygnał do weryfikacji.
• Routes API: podajecie origin i destination, ustawiacie travelMode (DRIVE, WALK, TRANSIT) i opcjonalnie departureTime dla konkretnej godziny wyjazdu. W odpowiedzi dostajecie "duration" i "distanceMeters". Z parametrem departureTime API korzysta z historycznych wzorców ruchu dla tej godziny i dnia tygodnia.
• Distance Matrix API: wchodzi lista N adresów startowych i M docelowych. Wychodzi tabela N×M z czasami przejazdu i odległościami między każdą parą. Dla 3 serwisantów i 12 klientów na dziś dostajecie 36 wartości w jednym zapytaniu.

Klucz API ląduje w zaszyfrowanych ustawieniach narzędzia portalu, nie w kodzie i nie w pliku tekstowym. Asystent dostaje oddzielne narzędzie dla każdego przypadku: jedno do geokodowania, drugie do liczenia trasy, trzecie do macierzy. Każde zwraca ustrukturyzowany JSON, z którego asystent wyciąga konkretne pola i zwraca je do systemu zleceń.

Jak AI poprawia błędne adresy, zanim serwisant wyjedzie w pole

Adresy wpadają do systemu zleceń z różnych źródeł. Formularz na stronie, mail od klienta, zapis telefoniczny przez operatora. I tam właśnie są błędy. "Piotrkowska 44 m 4 Lodz" zamiast "al. Piotrkowska 44/4, 90-001 Łódź". Albo po prostu brakuje numeru lokalu, albo klient napisał nazwę osiedla zamiast ulicy.

Gdy asystent próbuje geokodować taki adres, Geocoding API zwraca "partial_match: true" lub lokalizację z polem "location_type: APPROXIMATE" zamiast oczekiwanego "ROOFTOP". To sygnał, że adres jest niedokładny i wymaga sprawdzenia przed wysłaniem serwisanta. Bez tego sprawdzenia serwisant startuje z nawigacją na zły punkt i traci czas na szukanie. Albo dzwoni do biura i do klienta. Albo zlecenie wraca jako "niewykonane, klient nieosiągalny", a problem był w błędnym adresie od pierwszego wpisu.

Co robi asystent w takiej sytuacji:

• Wywołuje Places API z zapytaniem "text search" dla fragmentu adresu i okolic wskazanych przez klienta w zgłoszeniu.
• Zwraca operatorowi dwa-trzy możliwe dopasowania z dokładnym adresem z bazy Google.
• Operator klika właściwe: poprawiony adres trafia do karty zlecenia, a geokod zostaje zapisany obok oryginału.
• Gdy operatora nie ma pod ręką (zgłoszenie nocne, weekend), asystent może automatycznie wysłać do klienta SMS z prośbą o potwierdzenie, z linkiem do prostego formularza potwierdzającego.

Typowy przypadek: firma serwisująca klimatyzatory. Klient wpisał w formularzu "Marki, ul. Lipowa, obok kościoła". Asystent geokoduje, dostaje APPROXIMATE, wywołuje text search w okolicach Marek dla "Lipowa". Wraca z trzema możliwymi ulicami w okolicy. Operator widzi je obok siebie, klika tę właściwą, dopisuje numer domu z notatki telefonicznej. Zlecenie idzie dalej już z dokładnym geokod-em.

Jak AI układa kolejność wizyt, żeby serwisanci nie wozili się bez sensu

To największa wartość z całego zestawu. Mamy dziś 10 adresów do obsłużenia, 2 serwisantów i 8 godzin roboczych. W jakiej kolejności powinni jechać? W tradycyjnym podejściu dyspozytor układa to z głowy albo według kodu pocztowego, co daje trasę dalece od optymalnej.

Asystent podchodzi do tego inaczej. Geokoduje wszystkie adresy, wysyła je do Distance Matrix API i dostaje macierz czasów przejazdu między każdą parą punktów. Na tej podstawie szuka dobrej kolejności wizyt, biorąc pod uwagę:

• punkt startowy każdego serwisanta (magazyn, dom, ostatni klient poprzedniego dnia),
• przewidywany czas trwania każdej wizyty (z pola "czas_uslugi" w karcie zlecenia),
• okna czasowe klientów, gdy je macie ("dostępny 10:00-14:00"),
• priorytet zlecenia (awaria jedzie przed przeglądem planowym).

Wynik: serwisant dostaje listę adresów w kolejności, z szacowanym czasem dojazdu do każdego. Dyspozytor widzi plan całego dnia dla wszystkich serwisantów na jednym ekranie. Nikt nic nie liczy ręcznie.

U jednego klienta, firmy serwisującej urządzenia chłodnicze w Trójmieście, codziennie o 7:30 asystent pobiera listę aktywnych zleceń na ten dzień, geokoduje adresy i wysyła je do Distance Matrix API. Dyspozytor widzi macierz i od razu wie, że dwóch serwisantów pokryje Zaspę i Moreny, a trzeci ogarnie Wrzeszcz i Oliwę. Bez tego liczyli z głowy albo według kodu pocztowego.

Jedno ważne zastrzeżenie: Routes API z departure_time liczy czas przejazdu na podstawie historycznych wzorców ruchu dla tej godziny i dnia tygodnia. Nie zna dzisiejszego wypadku na trasie S6 ani zamkniętego odcinka po awarii. Do bieżącej nawigacji serwisanci używają telefonu. Asystent daje plan dnia i szacunki, nie zastępuje GPS-u w samochodzie.

Czas dojazdu w wycenie: koniec z ryczałtem "na oko"

Firma hydrauliczna, serwis AGD, firma montażowa. Wszyscy mają w cenniku pozycję "dojazd". I większość liczy to z doświadczenia: "Wilanów to jakieś 20 zł", "za Legionowo doliczamy 50 zł", "poniżej 15 km gratis". Nikt nie sprawdza tego przy każdym zleceniu.

Gdy asystent przygotowuje wycenę dla nowego klienta, może od razu sprawdzić trasę. Pobiera adres klienta z karty zlecenia, wywołuje Routes API z adresem bazy jako origin i adresem klienta jako destination, ustawia departureTime na planowaną godzinę wyjazdu. Dostaje dystans w metrach i czas przejazdu w sekundach. Te liczby trafiają wprost do wyceny jako osobna pozycja: "dojazd: 34 km, szacowany czas dojazdu: 48 minut" i kwota według stawki zdefiniowanej w konfiguracji narzędzia.

Co to zmienia: wyceny przestają być zaniżone dla klientów na obrzeżach. Klient dostaje konkretną informację zamiast ryczałtu z sufitu. A gdy zlecenie jest na tyle daleko, że dojazd zaburza opłacalność, asystent może automatycznie oznaczyć je do decyzji menedżera, zanim wycena pójdzie do klienta. To szczególnie istotne przy pracach zlecanych przez formularze i chatboty, gdzie klient składa zamówienie bez rozmowy z handlowcem.

Zlecenia spoza obszaru: AI wyłapuje je przy wejściu, nie po fakcie

Wiele firm ma określony obszar działania. Obsługujecie trzy województwa, ale nie jedziecie na drugi koniec kraju. Albo działacie w promieniu 80 km od siedziby. Albo obsługujecie konkretne powiaty, bo macie tam serwisantów i zaplecze.

Problem pojawia się, gdy klient spoza zasięgu złoży zlecenie przez stronę albo zadzwoni. Bez automatyki zlecenie wchodzi do kolejki, operator pracuje nad ofertą, a dopiero przy wydawaniu dyspozycji ktoś zauważa, że adres jest 350 km od bazy. Stracony czas, często też niezręczna rozmowa z klientem, który zdążył na coś czekać.

Asystent sprawdza to przy samym wejściu zlecenia:

• Geokoduje adres klienta, dostaje współrzędne.
• Sprawdza, czy współrzędne mieszczą się w zdefiniowanym obszarze: albo okrąg z centrum i promieniem w kilometrach, albo wielokąt: lista par lat/lng opisujących kontur obszaru obsługi.
• Gdy adres jest poza obszarem: zlecenie dostaje flagę "poza zasięgiem" i zatrzymuje się do decyzji, zamiast wchodzić do normalnej kolejki.
• Asystent może jednocześnie odpowiedzieć klientowi, że sprawdzi dostępność i wróci z informacją, zamiast milczeć przez kilka godzin.

Obszar definiujemy raz w konfiguracji narzędzia. Dla prostych przypadków wystarczy promień od adresu centrali. Dla firm z nieregularnym zasięgiem (obsługujecie całe woj. mazowieckie, ale nie Radom i okolice) lepszy jest wielokąt z narysowaną granicą. Trzecia opcja: zamiast geometrii liczymy maksymalny czas przejazdu z bazy do adresu klienta przez Routes API. Gdy Routes API zwraca "duration" powyżej np. 90 minut, zlecenie trafia do flagi, niezależnie od tego, gdzie leży geograficznie. Ta metoda dobrze się sprawdza dla firm, gdzie granica zasięgu zależy od czasu jazdy, a nie od linii województwa na mapie.

Od czego zaczynacie

Zanim cokolwiek podłączymy, warto odpowiedzieć na jedno pytanie: który z tych problemów kosztuje Was teraz najbardziej: błędne adresy i serwisanci szukający budynku przez 20 minut, trasy ułożone "mniej więcej", dojazdy liczone ryczałtem, który nie pokrywa kosztów dla dalszych klientów, czy zlecenia spoza zasięgu blokujące czas operatora? Zaczynamy od jednego przypadku, bo każdy wymaga osobnego narzędzia i osobnej logiki.

Po stronie technicznej kroki są powtarzalne. Zakładacie projekt w Google Cloud Console, włączacie wybrane usługi, generujecie klucz API i ograniczacie go do adresu IP serwera portalu. Klucz idzie do zaszyfrowanych ustawień narzędzia, nie w kod. Asystent dostaje narzędzie wywołujące konkretny endpoint i wraca z ustrukturyzowaną odpowiedzią. Dane do pracy bierzemy z systemu zleceń lub CRM: pole "adres_klienta", ewentualnie "termin_wizyty" i "szacowany_czas_uslugi". Gdy te pola są w bazie portalu albo dostępne przez API systemu zewnętrznego, asystent sięga po nie automatycznie przy każdym nowym zgłoszeniu.

Chcecie zobaczyć, jak to wygląda na realnych danych Waszej firmy? Umówcie się na 15 minut rozmowy, pokażemy konkretny przykład z branży zbliżonej do Waszej. Możecie też zajrzeć do realnych wdrożeń i sprawdzić, jak inne firmy podłączyły swoje systemy zleceń do danych geograficznych.