Kierowca zatrzymuje samochód przed adresem. Aplikacja zna zlecenie, trasę, położenie pojazdu, planowaną usługę i język pracownika. Mimo to wymaga otwarcia listy, znalezienia właściwej pozycji, zaznaczenia przyjazdu i przejścia do kolejnego ekranu.
Przy kilkudziesięciu punktach każda zbędna czynność powtarza się kilkadziesiąt razy. No-UI zakłada ograniczenie tej obsługi: system przygotowuje kolejny krok, a interfejs pojawia się wtedy, gdy potrzebna jest decyzja, korekta lub dowód wykonania usługi. Kierowca potwierdza to, czego aplikacja nie może wiarygodnie ustalić sama.
Typowy przebieg dostawy może działać w tle
System zna kolejność zleceń, adres, okno dostawy, rodzaj usługi i wynik poprzedniego punktu. Może automatycznie otworzyć właściwe zlecenie, przygotować nawigację, przeliczyć przewidywany czas przyjazdu i pobrać instrukcję w języku kierowcy.
Do tych czynności zwykle wystarczą dane z TMS i jasno opisane reguły procesu. AI może pomóc w rozpoznaniu mowy lub sklasyfikowaniu notatki. Przy przewidywalnej sekwencji zacząłbym od reguł, które zespół potrafi sprawdzić i poprawić.
Kierowca musi zachować możliwość korekty. Plan może nie uwzględniać robót drogowych, miejsca postoju, nietypowego wejścia czy ustaleń z odbiorcą. Aplikacja powinna zapisać powód odstępstwa, aby dyspozytor mógł odróżnić błąd od uzasadnionej zmiany.
Im wyższy koszt błędu, tym mniej autonomii
Przed wdrożeniem podzieliłbym działania na trzy grupy.
System może wykonać sam
- wybrać następne zlecenie i przygotować nawigację;
- uzupełnić dane zlecenia, instrukcje i przewidywany czas przyjazdu;
- zapisać zatwierdzoną operację lokalnie i przesłać ją po odzyskaniu zasięgu.
System może zaproponować krótkie potwierdzenie
- przyjazd rozpoznany na podstawie planu, lokalizacji i zatrzymania pojazdu;
- przejście do kolejnego etapu usługi;
- zamknięcie typowej sekwencji po wykonaniu wymaganych skanów.
Kierowca powinien potwierdzić jawnie
- doręczenie i dowód odbioru;
- brak odbiorcy, odmowę albo uszkodzenie;
- pobranie płatności oraz wynik weryfikacji wieku lub tożsamości;
- zmianę zakresu usługi lub ustaleń z klientem.
Geofence, czyli wirtualna granica wokół adresu, pozwala w przybliżeniu wykryć przyjazd. Dokumentacja Androida zaleca minimalny promień 100–150 metrów; zdarzenia wykrywane w tle mogą docierać z kilkuminutowym opóźnieniem. Lokalizacja może przygotować propozycję statusu, ale nie powinna samodzielnie potwierdzać dotrzymania terminu ani wykonania usługi.
Automatyzacja ogranicza też barierę językową
Gdy system przygotowuje następny punkt i instrukcję usługi, kierowca rzadziej musi szukać funkcji i czytać komunikaty. Krótszy proces pomaga także wtedy, gdy język aplikacji nie jest jego pierwszym językiem.
Różnica między „odbiorcy nie było” a „odbiorca odmówił” może decydować o ponownej próbie, rozliczeniu i treści wiadomości do klienta. Rozpoznawanie mowy albo tłumaczenie mogą podpowiedzieć przyczynę, ale nie powinny samodzielnie zmieniać statusu. Kierowca zatwierdza jedną krótką opcję, pełna wypowiedź zostaje notatką dla dyspozytora, a TMS otrzymuje dopiero zatwierdzone zdarzenie.
Statusy, usługi i instrukcje bezpieczeństwa powinny mieć zatwierdzone wersje w językach załogi. Automatyczne tłumaczenie zostawiłbym do notatek o małym ryzyku, z dostępem do oryginału. Nazwy klientów, adresy, kwoty i identyfikatory muszą pozostać danymi źródłowymi.
W ruchu interfejs powinien niemal zniknąć
Podczas jazdy aplikacja powinna przekazywać tylko informacje potrzebne do prowadzenia oraz krótkie komunikaty, które można zignorować, przerwać lub odtworzyć później. Pełna lista zleceń, formularz szkody, zdjęcia, podpis i zmiana statusu powinny być obsługiwane podczas postoju.
Głos może skrócić pojedynczą czynność, na przykład polecenie „powtórz instrukcję”. Nadal obciąża uwagę. Google w wytycznych Design for Driving zaleca, aby rozmowę można było przerwać i wznowić, a jej tempo pozostawało pod kontrolą kierowcy. Dyktowanie statusów i obsługę wyjątków odłożyłbym do postoju.
Rozpoznawanie mowy trzeba sprawdzić w hałasie kabiny i w językach załogi. Funkcja działająca na urządzeniu z Androidem może być niedostępna albo nie obsługiwać wybranego języka. Po zaparkowaniu kierowca musi móc wykonać tę samą czynność przyciskiem, skanem lub przez kontakt z dyspozytorem.
Rozdzieliłbym tryb jazdy i postoju. W ruchu aplikacja blokuje przeglądanie, wpisywanie i decyzje o wysokim koszcie błędu. Pełny interfejs wraca po bezpiecznym zaparkowaniu. Krótkie zatrzymanie w korku nie powinno odblokowywać formularzy.
Automatyzacja potrzebuje jawnych granic
Kierowca musi wiedzieć, czy system proponuje działanie, czy już je wykonał. Każda automatyczna zmiana powinna mieć zapis przyczyny i możliwość zatrzymania dalszych działań. Przy niejednoznacznym wyjątku system powinien poprosić kierowcę lub dyspozytora o decyzję, zanim zmieni status w TMS albo wyśle wiadomość do klienta.
Obsługę zlecenia oddzieliłbym od oceny pracownika. Ślad GPS użyty do przygotowania statusu przyjazdu nie powinien bez osobnej decyzji stawać się rankingiem kierowcy. Jeśli AI służy do przydzielania zadań lub oceniania pracy, jej zastosowanie wymaga osobnej analizy prawnej, w tym kwalifikacji na gruncie AI Act.
Pilotaż powinien zacząć się od jednej sekwencji
Na pierwszy test wybrałbym przyjazd, wykonanie usługi, odjazd i przygotowanie następnego punktu. Przed zmianą aplikacji zmierzyłbym:
- liczbę dotknięć i otwarć ekranu na jeden punkt;
- czas aktywnego ekranu podczas ruchu i postoju;
- udział statusów błędnych, spóźnionych, brakujących lub cofniętych;
- liczbę telefonów do dyspozytora i rodzaje problemów w poszczególnych językach;
- błędy zapisu i synchronizacji przy słabym zasięgu.
Najpierw system powinien zapisywać propozycje w tle, bez zmiany statusów. Dyspozytor porówna je z działaniami kierowców i sprawdzi przyczyny rozbieżności. Dopiero w ograniczonym pilotażu dopuściłbym automatyczne wykonanie działań o małym ryzyku, zachowując potwierdzenia dla pozostałych.
Test musi objąć urządzenia floty, hałas, słaby zasięg, rękawice oraz nowych i doświadczonych kierowców w każdym potrzebnym języku. Zapis lokalny i późniejsza synchronizacja pozwalają pracować bez sieci. Trzeba jednak ustalić, co się stanie, gdy dyspozytor i kierowca zmienią to samo zlecenie przed odzyskaniem połączenia.
Przed startem uzgodniłbym dopuszczalną liczbę błędnych statusów i wymagane ograniczenie obsługi ekranu. Rozszerzenie automatyzacji powinno zależeć od wyniku rzeczywistych dostaw, bez wzrostu ponownych prób ani pracy dyspozytorów.