Gizo Rental to produkcyjna aplikacja mobilna i system webowy zaprojektowane przez Softech dla wielooddziałowego procesu wynajmu podnośników, dźwigów, wózków i innych maszyn. Rozwiązanie porządkuje drogę klienta B2B od wyszukania sprzętu według parametrów i sprawdzenia dostępności, przez wybór oddziału, geolokalizację oraz kalkulację transportu, po weryfikację firmy, dokumenty, podpis elektroniczny i płatność lub preautoryzację. Wspólny model domenowy prowadzi następnie zlecenie przez rezerwację, wydanie, transport, aktywny najem, przedłużenie, zwrot i końcowe rozliczenie. Case study opisuje potwierdzony zakres produktu, widoczny w istniejących ekranach, materiałach projektowych i strukturze systemu. Nie publikuje niezatwierdzonych danych o konwersji, liczbie użytkowników, skróceniu czasu obsługi ani oszczędnościach.
Kontekst biznesowy i sytuacja przed wdrożeniem
Wynajem maszyn jest procesem transakcyjno-operacyjnym, w którym decyzja zakupowa zależy jednocześnie od parametrów sprzętu, miejsca realizacji, dostępności oddziałowej, kosztu transportu, wiarygodności kontrahenta oraz warunków finansowych. Gizo potrzebowało kanału samoobsługowego, który nie odcina klienta od realiów operacyjnych sieci oddziałów.
- Oferta obejmuje maszyny o różnych parametrach technicznych, zastosowaniach i wymaganiach transportowych.
- Dostępność oraz możliwość realizacji zamówienia są związane z konkretnym oddziałem i terminem.
- Koszt transportu zależy od adresu realizacji, trasy i reguł biznesowych.
- Klient firmowy musi przekazać dane potrzebne do weryfikacji, umowy i rozliczenia.
- Zespół operacyjny potrzebuje wspólnego statusu zlecenia od rezerwacji do zamknięcia najmu.
Stan wyjściowy
Przed ujednoliceniem procesu wiele informacji było ustalanych sekwencyjnie: klient pytał o sprzęt, pracownik sprawdzał dostępność, oddział i transport, a następnie osobno zbierano dane firmy, przygotowywano dokumenty i uzgadniano płatność. Taki model zwiększał liczbę kontaktów potrzebnych do zamknięcia jednego zamówienia i utrudniał klientowi śledzenie aktualnego etapu.
- Parametry sprzętu i dostępność wymagały ręcznego doprecyzowania.
- Wycena transportu była oddzielona od wyboru maszyny i miejsca realizacji.
- Dane kontrahenta były zbierane w kilku momentach procesu.
- Dokumenty, podpis i płatność tworzyły osobne ścieżki komunikacji.
- Informacje o wydaniu, aktywnym najmie, przedłużeniu i zwrocie nie były prezentowane klientowi w jednym przebiegu.
Cele, kryteria sukcesu i ograniczenia
Prace rozpoczęły się od rozpisania realnego przebiegu najmu oraz punktów, w których klient i operator podejmują decyzje. Zamiast odwzorowywać dokumenty jeden do jednego, zespół zdefiniował model zamówienia, zasady dostępności, odpowiedzialność oddziału oraz kontrolowane przejścia pomiędzy etapami.
Cele produktu
- Zbudować mobilny kanał samoobsługowego wynajmu dla klientów B2B.
- Połączyć katalog techniczny z dostępnością i logiką oddziałów.
- Automatyzować wstępną kalkulację transportu na podstawie lokalizacji.
- Przeprowadzić klienta przez weryfikację, dokumenty i płatność w jednym procesie.
- Utworzyć spójny model statusów od rezerwacji do zwrotu i rozliczenia.
- Zapewnić zespołowi operacyjnemu kontrolę nad wyjątkami i decyzjami wymagającymi interwencji.
Kryteria sukcesu
- Klient może znaleźć maszynę na podstawie parametrów użytkowych bez rozpoczynania od telefonu.
- Adres realizacji i termin są częścią zamówienia przed przygotowaniem dokumentów.
- System potrafi powiązać zamówienie z oddziałem i regułami transportu.
- Dane firmy, podpis i płatność są przypisane do tego samego zlecenia.
- Każdy etap cyklu najmu ma jednoznaczny status widoczny w systemie.
- Przedłużenie i zwrot są obsługiwane jako kontrolowane przejścia, a nie luźne notatki.
Złożoność katalogu
Maszyny różnią się wysokością roboczą, udźwigiem, masą, napędem i osprzętem, dlatego wyszukiwanie musi operować na danych technicznych, a nie wyłącznie na nazwach.
Dostępność oddziałowa
Ta sama kategoria sprzętu może być dostępna w innym oddziale lub terminie, co wpływa na wykonalność i koszt realizacji.
Transport ciężkiego sprzętu
Odległość nie jest jedynym czynnikiem; wycena musi uwzględniać reguły firmy i możliwość ręcznej decyzji operacyjnej.
Proces B2B
Przed umową i płatnością system musi zebrać dane firmy oraz powiązać je z konkretnym zamówieniem.
Zależności zewnętrzne
Geokodowanie, trasy, e-podpis i płatności są usługami zewnętrznymi, więc proces musi przewidywać oczekiwanie, błąd lub ponowienie.
Analiza i decyzje produktowe
- Rozdzielono wybór kategorii, konkretnej maszyny, terminu i adresu realizacji.
- Zdefiniowano dane potrzebne do orientacyjnej wyceny transportu oraz moment ręcznej weryfikacji.
- Ustalono, które dane kontrahenta są wymagane przed przygotowaniem umowy.
- Połączono dokument, podpis i płatność z jednym identyfikatorem zlecenia.
- Zaprojektowano statusy rezerwacji, wydania, transportu, aktywnego najmu, przedłużenia, zwrotu i rozliczenia.
- Uwzględniono wyjątki: brak dostępności, zmianę oddziału, zmianę terminu, odrzuconą płatność i korektę dokumentu.
Architektura rozwiązania
Architektura oddziela kanały klienta i operatora od wspólnej logiki najmu. Aplikacja mobilna oraz panel webowy korzystają z API, które odpowiada za katalog, dostępność, oddziały, transport, kontrahentów, dokumenty, płatności i statusy. Dane transakcyjne są przechowywane centralnie, a integracje z mapami, trasami, podpisem i płatnościami są obsługiwane jako osobne zależności.
- 01Kanał klienta
Aplikacja mobilna
Katalog, parametry techniczne, termin, adres, rezerwacja, dokumenty, płatność i status najmu.
React NativeTypeScript - 02Kanał operacyjny
Panel webowy
Obsługa dostępności, decyzji oddziałowych, wyjątków, dokumentów, płatności i zmian statusu.
ReactMaterial UITypeScript - 03Logika domenowa
API procesu najmu
Spójne reguły katalogu, rezerwacji, transportu, weryfikacji i cyklu zlecenia.
Node.jsPHP - 04Dane
Stan zamówień i dostępności
Centralne dane klientów, maszyn, oddziałów, rezerwacji, dokumentów, płatności i historii zmian.
PostgreSQL/MySQLRedis - 05Usługi zewnętrzne
Lokalizacja, dokumenty i rozliczenie
Geokodowanie, estymacja trasy, podpis elektroniczny, płatności i przechowywanie plików.
GeocodingRoute Estimation APIe-SignPayment APIS3/Blob Storage - 06Uruchomienie
Środowisko produkcyjne
Konteneryzacja i rozdzielenie usług ułatwiają wdrożenia, monitoring oraz rozwój kolejnych modułów.
DockerKubernetes
Problemy, decyzje i wdrożone możliwości
Klient nie wie, który model spełnia wymagania zadania.
Oprzeć katalog na parametrach technicznych i kategoriach.
Filtrowanie po wysokości, udźwigu, masie, napędzie i innych cechach sprzętu.
Klient może zawęzić ofertę przed kontaktem z oddziałem.
Dostępność zależy od oddziału i terminu.
Powiązać ofertę i rezerwację z lokalizacją operacyjną.
Wybór oddziału oraz branch-aware dostępność sprzętu.
Zamówienie od początku zawiera kontekst miejsca realizacji.
Transport wymaga osobnej, ręcznej kalkulacji.
Włączyć adres i trasę do procesu zamówienia.
Geokodowanie, estymacja trasy i reguły kosztu transportu.
Klient i operator pracują na tych samych danych lokalizacyjnych.
Dane klienta firmowego są zbierane wielokrotnie.
Utworzyć jeden profil kontrahenta powiązany ze zleceniem.
Formularz danych firmy i etap weryfikacji B2B.
Dokumenty i płatność korzystają ze spójnego zestawu danych.
Papierowa lub mailowa umowa przerywa proces mobilny.
Połączyć przygotowanie dokumentu z podpisem elektronicznym.
Generowanie dokumentów i przepływ e-podpisu przypisany do zamówienia.
Status dokumentu jest częścią cyklu zlecenia.
Zaliczka, depozyt lub preautoryzacja są ustalane poza systemem.
Obsłużyć warunki finansowe w tym samym przebiegu.
Integracja płatności i preautoryzacji z rezerwacją.
System może kontrolować, czy warunek finansowy został spełniony przed wydaniem.
Zespół i klient używają różnych określeń etapu realizacji.
Zdefiniować jeden model stanów najmu.
Statusy rezerwacji, wydania, transportu, aktywnego najmu, przedłużenia, zwrotu i rozliczenia.
Obie strony mogą odwoływać się do tego samego etapu zlecenia.
Przedłużenie i zwrot generują wyjątki czasowe oraz finansowe.
Traktować je jako kontrolowane przejścia modelu, a nie osobne wiadomości.
Walidacja przedłużenia, zmiana terminu, zwrot i końcowe rozliczenie.
Historia zlecenia pozostaje kompletna również po rozpoczęciu najmu.
Decyzje technologiczne
| Technologia | Rola | Uzasadnienie | Konsekwencja wyboru |
|---|---|---|---|
| React Native | Aplikacja klienta na iOS i Android | Jeden kod produktu mobilnego ułatwia utrzymanie wspólnego procesu i interfejsu na obu platformach. | Funkcje zależne od urządzenia wymagają testów na obu systemach i kontrolowanej obsługi bibliotek natywnych. |
| React + Material UI | Panel operacyjny i interfejsy webowe | Komponentowy interfejs wspiera rozbudowane formularze, statusy i widoki operacyjne. | Spójność design systemu wymaga dyscypliny przy rozwoju kolejnych modułów. |
| Node.js / PHP | API oraz logika domenowa procesu najmu | Warstwa serwerowa centralizuje zasady rezerwacji, transportu, dokumentów, płatności i zmian statusu. | Wielotechnologiczne zaplecze wymaga jasno zdefiniowanych granic odpowiedzialności i kontraktów API. |
| PostgreSQL/MySQL + Redis | Dane transakcyjne, dostępność i dane pomocnicze | Relacyjny model pasuje do powiązań pomiędzy klientem, sprzętem, oddziałem, dokumentem, płatnością i statusem. | Zmiany modelu cyklu najmu wymagają bezpiecznych migracji oraz utrzymania zgodności istniejących zamówień. |
| Geocoding + Route Estimation API | Adres realizacji, dobór oddziału i estymacja transportu | Dane lokalizacyjne są potrzebne wcześniej niż ręczne przygotowanie finalnej oferty transportowej. | Wynik zewnętrznego API jest estymacją i musi być podporządkowany regułom operacyjnym firmy. |
| Payment API + e-Sign | Warunki finansowe, dokumenty i zdalne zawarcie umowy | Połączenie tych kroków domyka samoobsługową ścieżkę klienta B2B. | Statusy zewnętrznych usług muszą być mapowane na wewnętrzne stany zlecenia i obsługiwać opóźnienie lub błąd. |
Integracje i przepływy danych
Geokodowanie i trasy
adres ↔ dane trasyNormalizacja miejsca realizacji, porównanie lokalizacji i wsparcie kalkulacji transportu.
Wynik jest walidowany przez reguły biznesowe; brak odpowiedzi lub niejednoznaczny adres wymaga korekty albo decyzji operatora.
Podpis elektroniczny
zamówienie → dokument → status podpisuZdalne zawarcie dokumentów powiązanych z konkretnym najmem.
System musi rozróżniać dokument przygotowany, wysłany, podpisany, odrzucony i wymagający korekty.
Płatności i preautoryzacje
zamówienie ↔ operator płatnościObsługa warunku finansowego przed wydaniem oraz powiązanie wyniku z zamówieniem.
Powrót statusu jest obsługiwany niezależnie od ekranu klienta, a nieudana lub wygasła operacja może zostać ponowiona zgodnie z regułami.
Przechowywanie dokumentów
system ↔ bezpieczny magazyn plikówPrzechowywanie umów i materiałów powiązanych z historią zlecenia.
Pliki są identyfikowane przez powiązanie z zamówieniem i etapem procesu, a dostęp jest oddzielony od publicznego katalogu.
AI, bezpieczeństwo i niezawodność
Spójność statusów
Przejścia cyklu najmu są walidowane, aby zlecenie nie ominęło wymaganych etapów dokumentowych, finansowych lub operacyjnych.
Dane kontrahenta
Dane firmy są przechowywane w kontekście konta i zamówienia oraz wykorzystywane tylko w procesach, które ich wymagają.
Statusy integracji
Podpis i płatność są traktowane jako procesy zewnętrzne, których wynik może przyjść z opóźnieniem albo wymagać ponowienia.
Historia zlecenia
Zmiany najmu, terminu i statusu tworzą ciągłą historię potrzebną klientowi oraz zespołowi operacyjnemu.
Kontrola wyjątków
Brak dostępności, zmiana oddziału, korekta dokumentu i nieudana płatność prowadzą do jawnego stanu wymagającego decyzji, zamiast znikać w komunikacji poza systemem.
Realizacja, testy i uruchomienie
- 1Etap 1
Model procesu i zakres MVP
- Mapa cyklu najmu
- Role klienta, oddziału i operatora
- Lista wyjątków oraz wymaganych danych
Rezultat: Jednoznaczna definicja zamówienia oraz etapów, które aplikacja i panel muszą obsłużyć.
- 2Etap 2
Katalog i doświadczenie mobilne
- Filtry parametrów technicznych
- Karta maszyny i termin
- Nawigacja kategorii oraz oddziału
Rezultat: Klient może rozpocząć proces od dopasowania sprzętu, zamiast od ogólnego zapytania.
- 3Etap 3
Dostępność, lokalizacja i transport
- Powiązanie sprzętu z oddziałem
- Geokodowanie adresu realizacji
- Reguły estymacji transportu
Rezultat: Zamówienie zawiera dane potrzebne do oceny dostępności i logistyki przed przygotowaniem umowy.
- 4Etap 4
Kontrahent, dokumenty i płatność
- Formularz i walidacja danych firmy
- Generowanie i podpis dokumentów
- Płatność, zaliczka lub preautoryzacja
Rezultat: Najważniejsze kroki formalne są przypisane do jednego zamówienia i mają kontrolowany status.
- 5Etap 5
Operacje najmu i uruchomienie
- Statusy wydania i transportu
- Aktywny najem, przedłużenie i zwrot
- Testy scenariuszy klienta oraz operatora
Rezultat: Produkcyjny proces prowadzi zlecenie od rezerwacji do zamknięcia bez utraty historii etapów.
Reguły katalogu i dostępności
Sprawdzono filtrowanie parametrów, powiązanie z oddziałem i zachowanie dla braku dostępnego sprzętu.
Adresy i transport
Testy obejmowały poprawne, niepełne i niejednoznaczne adresy oraz scenariusze wymagające ręcznej korekty.
Dokumenty i płatności
Zweryfikowano przejścia dla przygotowania, podpisu, odrzucenia, płatności, błędu i ponowienia.
Cykl najmu
Scenariusze obejmowały rezerwację, wydanie, aktywny okres, zmianę terminu, przedłużenie, zwrot i zamknięcie.
Aplikacja i panel
Przepływy klienta i operatora zostały sprawdzone jako jeden proces korzystający ze wspólnych danych.
Co potwierdza opis projektu
Opis został przygotowany na podstawie istniejących ekranów aplikacji, materiałów projektowych oraz modelu funkcjonalnego systemu. Weryfikacja dotyczy tego, jakie procesy i możliwości zostały wdrożone. Liczbowe rezultaty biznesowe nie są prezentowane, ponieważ repozytorium nie zawiera zatwierdzonego eksportu analitycznego z baseline, okresem porównawczym i źródłem danych.
| Zakres | Podstawa | Materiał | Potwierdzenie | Granice wniosku |
|---|---|---|---|---|
| System zawiera katalog sprzętu oparty na parametrach technicznych. | Ekran produkcyjny | GR-01 — katalog i filtry maszyn | Potwierdzone | Materiał potwierdza interfejs i zakres filtrowania, ale nie pokazuje pełnej bazy sprzętu. |
| Aplikacja mobilna łączy wybór maszyny z terminem, adresem i rozpoczęciem rezerwacji. | Ekrany aplikacji | GR-02 — karta maszyny i przebieg mobilny | Potwierdzone | Ekrany nie potwierdzają liczby ukończonych rezerwacji ani konwersji. |
| Interfejs uwzględnia wybór oddziału i kategorie sprzętu. | Ekran aplikacji | GR-03 — oddział i katalog mobilny | Potwierdzone | Materiał nie potwierdza aktualnej liczby oddziałów ani poziomu dostępności. |
| Aplikacja klienta i panel operacyjny korzystają ze wspólnej logiki procesu najmu. | Model architektury | GR-04 — architektura logiczna rozwiązania | Potwierdzone w produkcie | Diagram upraszcza komponenty i nie ujawnia poufnej topologii infrastruktury. |
| Model zlecenia obejmuje rezerwację, wydanie, aktywny najem, przedłużenie, zwrot i rozliczenie. | Model procesu | GR-05 — cykl najmu | Potwierdzone w produkcie | Diagram potwierdza zaprojektowane etapy, a nie liczbę zleceń przechodzących przez każdy z nich. |
| Adres realizacji, oddział i reguły trasy są częścią procesu kalkulacji transportu. | Model przepływu | GR-06 — dobór oddziału i transport | Potwierdzone w produkcie | Końcowa cena może wymagać decyzji operacyjnej i nie jest gwarantowana wyłącznie przez estymację trasy. |
| Weryfikacja firmy, dokumenty, podpis i płatność są powiązane z jednym zamówieniem. | Model przepływu | GR-07 — weryfikacja, dokumenty i płatność | Potwierdzone w produkcie | Zakres opisuje przebieg produktu bez ujawniania dostawców, warunków handlowych ani danych klientów. |
Jak czytać te informacje
- Ekrany potwierdzają istnienie funkcji, ale nie dowodzą ich wykorzystania przez określoną liczbę użytkowników.
- Diagramy upraszczają architekturę i nie stanowią dokumentacji infrastruktury ani zabezpieczeń klienta.
- Nie publikujemy wcześniejszych wartości procentowych dotyczących konwersji, czasu obsługi i liczby połączeń bez źródła.
- Liczba oddziałów i aktualna skala operacyjna powinny być okresowo potwierdzane z klientem.
- Opis wpływu dotyczy zmiany możliwości procesu, a nie zatwierdzonego wyniku finansowego.
Zmiana procesu, konsekwencje decyzji i wnioski
| Obszar | Przed wdrożeniem | Po wdrożeniu | Wpływ biznesowy |
|---|---|---|---|
| Wyszukiwanie sprzętu | Ogólne zapytanie i ręczne doprecyzowanie parametrów. | Katalog i filtry techniczne dostępne w aplikacji. | Klient rozpoczyna rozmowę z lepiej dopasowanym wyborem maszyny. |
| Oddział i dostępność | Oddział oraz termin były ustalane po otrzymaniu zapytania. | Lokalizacja i dostępność są częścią modelu rezerwacji. | Zamówienie wcześniej uwzględnia realia operacyjne realizacji. |
| Transport | Adres i koszt transportu były kalkulowane osobno. | Geokodowanie, trasa i reguły transportowe są połączone z zamówieniem. | Klient oraz operator odnoszą się do jednego zestawu danych lokalizacyjnych. |
| Weryfikacja i umowa | Dane firmy oraz dokumenty przechodziły przez osobne wiadomości i pliki. | Profil kontrahenta i dokument są przypisane do zlecenia. | Zmniejsza się ryzyko pracy na niespójnych danych. |
| Płatność | Warunek finansowy był potwierdzany poza głównym przebiegiem. | Płatność lub preautoryzacja ma status w tym samym zamówieniu. | Wydanie sprzętu może zależeć od jawnego wyniku procesu finansowego. |
| Aktywny najem i zwrot | Zmiany terminu, przedłużenie i zwrot wymagały dodatkowej komunikacji. | Cykl najmu zawiera kontrolowane etapy przedłużenia, zwrotu i rozliczenia. | Historia zamówienia pozostaje kompletna po rozpoczęciu realizacji. |
Samoobsługa mobilna z kontrolą operatora
- Alternatywa
- Całkowicie ręczna obsługa albo pełna automatyzacja bez możliwości ingerencji.
- Konsekwencja
- Nie każdy przypadek może zostać zamknięty automatycznie, więc panel musi obsługiwać wyjątki.
- Uzasadnienie
- Wynajem ciężkiego sprzętu wymaga połączenia wygody klienta z odpowiedzialnością operacyjną.
Automatyczna sugestia oddziału z możliwością korekty
- Alternatywa
- Sztywny wybór najbliższego oddziału lub zawsze ręczna decyzja.
- Konsekwencja
- System musi przechowywać zarówno wynik reguły, jak i ostateczną decyzję operacyjną.
- Uzasadnienie
- Najbliższa lokalizacja nie zawsze ma właściwy sprzęt albo najlepszą możliwość transportu.
Jeden model cyklu najmu
- Alternatywa
- Osobne listy statusów dla aplikacji, oddziału i płatności.
- Konsekwencja
- Model wymaga precyzyjnych reguł przejść i migracji przy jego rozwoju.
- Uzasadnienie
- Wspólny stan ogranicza rozbieżności między klientem, dokumentem, płatnością i operacjami.
Estymacja transportu wspierana przez mapy
- Alternatywa
- Wyłącznie ręczna wycena transportu.
- Konsekwencja
- Estymacja nie może zastąpić reguł firmy ani decyzji dla nietypowego przewozu.
- Uzasadnienie
- Automatyczna informacja przyspiesza przygotowanie zamówienia, zachowując kontrolę operacyjną.
Płatność i podpis jako integracje zewnętrzne
- Alternatywa
- Ręczne potwierdzanie przelewów i dokumentów przesyłanych e-mailem.
- Konsekwencja
- System musi obsługiwać asynchroniczne statusy, przerwy i ponowienia.
- Uzasadnienie
- Integracje umożliwiają zdalne domknięcie procesu bez utraty śladu zamówienia.
Najważniejsze lekcje
- W rental software katalog produktu nie może być oddzielony od dostępności, lokalizacji i logistyki.
- Adres realizacji powinien pojawić się wcześnie, ponieważ wpływa na oddział, transport i wykonalność zamówienia.
- Dane kontrahenta należy zbierać raz i wykorzystywać w dokumentach, płatnościach oraz historii zlecenia.
- Podpis i płatność wymagają jawnych stanów pośrednich; samo przekierowanie do zewnętrznej usługi nie domyka procesu.
- Przedłużenie i zwrot są częścią produktu, a nie wyłącznie operacją wykonywaną po sprzedaży.
- Największą wartość daje wspólny model cyklu najmu używany przez aplikację klienta i zespół operacyjny.
Dla jakich organizacji ten model jest istotny
Wynajem maszyn budowlanych
Firmy zarządzające flotą podnośników, wózków, dźwigów, agregatów i specjalistycznego osprzętu.
Sieci wielooddziałowe
Operatorzy, dla których lokalizacja sprzętu, dostępność i transport wpływają na każde zamówienie.
Rental B2B z dokumentami
Organizacje wymagające weryfikacji firmy, umowy, podpisu i warunków finansowych przed wydaniem.
Wynajem z aktywnym cyklem najmu
Firmy obsługujące przedłużenia, zwroty, rozliczenia i zmiany po rozpoczęciu usługi.
Cyfryzacja istniejących operacji
Zespoły chcące dodać samoobsługową aplikację bez utraty kontroli nad procesem oddziałowym.
Powiązana wiedza i usługi
Tworzenie aplikacji mobilnych
Projektowanie i rozwój produkcyjnych aplikacji iOS i Android połączonych z logiką biznesową.
Tworzenie aplikacji webowych
Panele operacyjne, portale klientów i systemy obsługi złożonych procesów.
Automatyzacja procesów biznesowych
Łączenie statusów, dokumentów, płatności i działań operatora w kontrolowane procesy.
React Native
Wspólna warstwa aplikacji mobilnej dla iOS i Android z możliwością integracji natywnej.
Node.js
API oraz usługi wspierające procesy transakcyjne i integracje zewnętrzne.
System zarządzania self-storage
Powiązany przykład cyfryzacji wynajmu, dokumentów, płatności i obsługi operatora.
Foodeli — logistyka ostatniej mili
Przykład systemu, w którym lokalizacja, dostępność i operacje terenowe tworzą jeden proces.
Planujesz aplikację lub system obsługi wynajmu maszyn?
Możemy przełożyć katalog, dostępność, oddziały, transport, dokumenty, płatności oraz cykl najmu na jeden spójny produkt mobilny i webowy.
Najważniejsze potwierdzone fakty
Poniższe informacje podsumowują potwierdzony zakres produktu i nie zawierają niezatwierdzonych danych o wzroście.
- 1
Softech zaprojektował i wdrożył dla Gizo produkcyjną aplikację mobilną oraz webowe zaplecze obsługi wynajmu maszyn.
- 2
Gizo Rental wspiera wyszukiwanie sprzętu według parametrów technicznych i kategorii.
- 3
Proces rezerwacji łączy wybraną maszynę z terminem, adresem realizacji i kontekstem oddziału.
- 4
System wykorzystuje geokodowanie oraz dane trasy jako wsparcie kalkulacji transportu.
- 5
Przepływ klienta B2B obejmuje zebranie i walidację danych kontrahenta.
- 6
Dokumenty oraz status podpisu elektronicznego są powiązane z konkretnym zamówieniem.
- 7
Rozwiązanie obsługuje płatność, zaliczkę lub preautoryzację jako element procesu najmu.
- 8
Wspólny model cyklu najmu obejmuje rezerwację, wydanie, transport, aktywny najem, przedłużenie, zwrot i rozliczenie.
- 9
Aplikacja klienta i panel operacyjny korzystają ze wspólnej logiki domenowej najmu.
- 10
Gizo Rental został zbudowany jako system wielokanałowy obejmujący aplikację mobilną i interfejs webowy.
- 11
Publiczne case study nie publikuje niezatwierdzonych wskaźników konwersji, liczby użytkowników ani redukcji czasu obsługi.
- 12
Materiały GR-01–GR-07 dokumentują katalog, aplikację mobilną, architekturę oraz kluczowe przepływy procesu.
Materiały wizualne
Diagramy przedstawiają potwierdzony zakres produktu i przepływy opisane w materiale. Nie są makietami ani deklaracją nieudokumentowanych wyników.
FAQ
Jak system dobiera oddział do zamówienia?
Adres realizacji i wybrany sprzęt są zestawiane z dostępnością oddziałową. System może wskazać właściwy oddział, a proces pozostawia zespołowi możliwość kontroli decyzji operacyjnej.
Jak obliczany jest koszt transportu maszyny?
Adres jest geokodowany, a wycena wykorzystuje odległość lub estymowaną trasę oraz reguły przypisane do transportu. Szczegółowe stawki pozostają konfigurowalne po stronie modelu biznesowego.
Czy aplikacja obsługuje klientów firmowych?
Tak. Proces zbiera dane kontrahenta B2B potrzebne do weryfikacji, przygotowania dokumentów i realizacji płatności.
Czy umowa i płatność mogą być wykonane zdalnie?
Zakres rozwiązania obejmuje przygotowanie dokumentów do podpisu elektronicznego oraz obsługę płatności, zaliczki lub preautoryzacji zgodnie z regułami zamówienia.
Jak system prowadzi aktywny najem?
Zlecenie przechodzi przez kontrolowane statusy obejmujące rezerwację, wydanie, transport, aktywny okres, przedłużenie, zwrot i rozliczenie.
Czy klient może przedłużyć wynajem?
Model lifecycle uwzględnia przedłużenie jako osobny etap wymagający sprawdzenia dostępności, warunków czasowych i rozliczenia.
Czy aplikacja działa razem z panelem operacyjnym?
Tak. Aplikacja klienta i zaplecze webowe korzystają ze wspólnej logiki domenowej, dzięki czemu dane zamówienia i statusy pozostają spójne.
