GizoBOX jest produkcyjnym wdrożeniem white-label przygotowanym przez Softech dla operatora self storage. Zamiast budować odrębny system od zera, zespół wykorzystał wspólny model Rentya i dopasował go do konkretnego obiektu, marki oraz sposobu pracy operatora. Wdrożenie odwzorowuje jednostki magazynowe indoor i outdoor, interaktywną mapę obiektu, dostępność, rezerwację, dokumenty, podpis, płatność, aktywny najem i kontrolę dostępu. Najważniejszym zadaniem nie było więc samo dostarczenie ekranów, lecz połączenie cyfrowego procesu klienta z realnym stanem fizycznych jednostek i operacjami obiektu. Publiczna wersja case study pokazuje potwierdzony zakres wdrożenia i rzeczywiste ekrany, ale nie publikuje wcześniejszych procentowych KPI bez zatwierdzonej metodologii i źródła analitycznego.
Kontekst biznesowy i sytuacja przed wdrożeniem
GizoBOX prowadzi fizyczny obiekt self storage, w którym cyfrowa rezerwacja musi odpowiadać rzeczywistej dostępności konkretnej jednostki. Operacje obejmują jednostki o różnych cechach i lokalizacji, kontakt klienta z marką GizoBOX, formalizację najmu, rozliczenia oraz kontrolę dostępu do obiektu. Wdrożenie musiało więc działać jednocześnie jako kanał sprzedaży, system operacyjny i warstwa łącząca dane z fizyczną usługą.
- Jednostka magazynowa jest fizycznym zasobem przypisanym do określonego miejsca w obiekcie.
- Wdrożenie obejmuje jednostki indoor i outdoor działające w jednym modelu rezerwacji i najmu.
- Klient powinien widzieć konkretną jednostkę, jej parametry, dostępność i warunki przed rozpoczęciem formalizacji.
- Operator potrzebuje możliwości kontroli procesu oraz ręcznej obsługi wyjątków.
- Dokumenty, płatność i dostęp muszą odnosić się do tego samego aktywnego najmu.
- Branding i komunikacja klienta są specyficzne dla GizoBOX, mimo wykorzystania wspólnego rdzenia Rentya.
Stan wyjściowy
Bez wspólnego modelu wdrożeniowego klient, operator i fizyczny obiekt mogą funkcjonować w kilku oddzielnych kontekstach: jednostka jest wskazywana niezależnie od rezerwacji, dokumenty żyją poza płatnością, a dostęp wymaga osobnej decyzji. Celem wdrożenia było uporządkowanie tych zależności w jeden kontrolowany lifecycle, zachowując możliwość pracy operatora tam, gdzie pełna automatyzacja nie jest właściwa.
- Rozproszone informacje o jednostce, rezerwacji i najemcy zwiększają ryzyko niespójności.
- Brak powiązania mapy obiektu z dostępnością utrudnia samoobsługowy wybór konkretnego magazynu.
- Dokumenty i płatność prowadzone poza lifecycle najmu wymagają dodatkowej kontroli operatorskiej.
- Dostęp fizyczny nie powinien być nadawany wyłącznie na podstawie deklaracji klienta.
- Jednostki indoor i outdoor wymagają wspólnego modelu, ale mogą mieć różne cechy operacyjne.
Cele, kryteria sukcesu i ograniczenia
Discovery koncentrowało się na przełożeniu rzeczywistego obiektu na model cyfrowy. Zespół rozdzielił strukturę fizyczną od lifecycle najmu, zmapował miejsca interwencji operatora i określił, które elementy mogą pozostać współdzielone z Rentya, a które muszą być konfigurowalne dla GizoBOX. Szczególną uwagę poświęcono temu, aby mapa jednostek nie była tylko wizualizacją, lecz wejściem do procesu rezerwacji.
Cele produktu
- Odwzorować fizyczny układ obiektu i konkretne jednostki w interfejsie klienta.
- Połączyć dostępność jednostki z rozpoczęciem rezerwacji.
- Utrzymać dokumenty, płatność i aktywny najem w jednym lifecycle.
- Powiązać status najmu z warstwą dostępu do obiektu.
- Zapewnić operatorowi panel do kontroli rezerwacji, najmu i wyjątków.
- Dostosować branding, komunikację i reguły wdrożenia do GizoBOX bez kopiowania rdzenia produktu.
Kryteria sukcesu
- Wybrana jednostka pozostaje jednoznacznie powiązana z rezerwacją i najmem.
- Jednostki indoor i outdoor korzystają ze wspólnego modelu dostępności.
- Proces klienta prowadzi od mapy do formalizacji bez przepisywania danych pomiędzy oddzielnymi systemami.
- Aktywny dostęp może być warunkowany stanem najmu i rozliczeń.
- Operator może przejąć obsługę procesu w sytuacjach wyjątkowych.
- Konfiguracja GizoBOX pozostaje oddzielona od współdzielonej logiki Rentya.
Fizyczny obiekt
Stan systemu musi odpowiadać rzeczywistym jednostkom i ich położeniu; błędna dostępność nie jest wyłącznie problemem interfejsu.
Indoor i outdoor
Różne rodzaje jednostek powinny działać w jednym lifecycle bez utraty cech istotnych dla konkretnej lokalizacji lub typu magazynu.
Dostęp fizyczny
Uprawnienie do obiektu powinno wynikać z kontrolowanego stanu najmu, a integracja musi zachować możliwość obsługi wyjątków.
White-label bez forka
Branding i konfiguracja GizoBOX nie powinny prowadzić do utrzymywania odrębnej kopii całej logiki najmu.
Płatności i dokumenty
Formalizacja wymaga synchronizacji statusów z usługami zewnętrznymi i odporności na opóźnione lub ponowione webhooki.
Analiza i decyzje produktowe
- Zdefiniowano strukturę obiektu, typy jednostek i dane potrzebne do ich prezentacji.
- Powiązano pozycję na mapie z rekordem jednostki i jej stanem dostępności.
- Rozpisano customer journey od wyboru magazynu do aktywnego najmu.
- Oddzielono automatyczne przejścia procesu od decyzji wymagających kontroli operatora.
- Określono granicę między konfiguracją GizoBOX a wspólnym lifecycle Rentya.
- Zmapowano zależności od płatności, podpisu, dokumentów i kontroli dostępu.
- Uwzględniono scenariusze zaległości, anulowania, ponownej próby płatności i zmiany statusu dostępu.
Architektura rozwiązania
Architektura wdrożenia rozdziela powierzchnie GizoBOX i konfigurację konkretnego obiektu od współdzielonej logiki najmu Rentya. Interfejs klienta oraz panel operatora korzystają z jednego API i modelu danych dla jednostek, dostępności, rezerwacji, dokumentów, płatności i najmu. Warstwa integracyjna łączy ten stan z podpisem, płatnościami, przechowywaniem dokumentów i kontrolą dostępu do fizycznego obiektu.
- 01Klient
White-label GizoBOX
Mapa obiektu, wybór jednostki, rezerwacja, formalizacja, płatność i samoobsługa najmu.
Next.jsTypeScriptResponsive UI - 02Operator
Panel operacyjny GizoBOX
Jednostki, dostępność, rezerwacje, najmy, dokumenty, rozliczenia, raporty i obsługa wyjątków.
Next.jsTypeScriptRole-based UI - 03Wspólny rdzeń
Rentya rental lifecycle
Logika jednostek, rezerwacji, najmu, dokumentów, płatności i przejść stanu współdzielona z platformą SaaS.
NestJSPrismaAPI - 04Dane
Stan jednostek i najmu
Centralny model operatora, obiektu, jednostek, klientów, rezerwacji, płatności, dokumentów i historii operacji.
PostgreSQLObject storage - 05Integracje
Płatność, podpis i dostęp
Usługi zewnętrzne formalizują rezerwację i przekładają kontrolowany status najmu na działania poza aplikacją.
StripePrzelewy24SignFlowIoT / access API - 06Konfiguracja
Warstwa GizoBOX
Branding, struktura obiektu, typy jednostek, cenniki, komunikacja i zasady charakterystyczne dla operatora.
White-label configFacility rulesContent
Problemy, decyzje i wdrożone możliwości
Klient musi wybrać konkretny magazyn w fizycznym obiekcie.
Połączyć interaktywną mapę bezpośrednio z rekordami jednostek.
Mapa pokazująca jednostki wraz z ich położeniem, parametrami i dostępnością.
Wybór fizycznego magazynu staje się początkiem tego samego procesu rezerwacji, a nie osobnym zapytaniem do operatora.
Indoor i outdoor mają różne cechy, ale operator potrzebuje jednego procesu najmu.
Modelować typ i parametry jednostki jako konfigurację w ramach wspólnego lifecycle.
Wspólna dostępność i rezerwacja dla jednostek indoor i outdoor z zachowaniem ich cech.
Operator nie musi utrzymywać dwóch niezależnych procesów tylko dlatego, że jednostki mają inną fizyczną formę.
Rezerwacja bez dokumentów i płatności nie oznacza jeszcze aktywnego najmu.
Formalizację potraktować jako kontrolowane przejście stanu.
Umowa, podpis, płatność i status rezerwacji połączone z jednym rekordem najmu.
System może rozróżnić zainteresowanie, zarezerwowaną jednostkę i najem gotowy do aktywacji.
Dostęp do fizycznego obiektu nie powinien być niezależny od stanu najmu.
Powiązać warstwę kontroli dostępu z kontrolowanymi stanami operacyjnymi.
Integracja uprawnień dostępu z aktywnym najmem i obsługą zmian statusu.
Cyfrowy lifecycle może sterować tym, kiedy klient powinien otrzymać lub utracić uprawnienie do obiektu.
Pełna automatyzacja nie obejmie wszystkich wyjątków obiektu.
Zachować panel operatora jako warstwę decyzyjną i kontrolną.
Ręczna obsługa rezerwacji, statusów, płatności, dokumentów i wyjątków.
Zespół może interweniować bez obchodzenia modelu danych lub prowadzenia równoległego procesu poza systemem.
Wdrożenie pod markę operatora może prowadzić do utrzymywania osobnego forka produktu.
Oddzielić konfigurację GizoBOX od współdzielonej logiki Rentya.
White-label branding, struktura obiektu, cenniki i integracje bez kopiowania podstawowego lifecycle.
Zmiany w podstawowym modelu najmu mogą być rozwijane jako część wspólnej platformy, a nie tylko jednego wdrożenia.
Decyzje technologiczne
| Technologia | Rola | Uzasadnienie | Konsekwencja wyboru |
|---|---|---|---|
| Next.js + TypeScript | Interfejs klienta i operatora | Komponentowy frontend pozwala współdzielić wzorce rezerwacji i paneli przy zachowaniu brandingu oraz kontekstu GizoBOX. | Warstwa white-label wymaga dyscypliny w oddzielaniu konfiguracji od zachowania wspólnych komponentów. |
| NestJS / Node.js | API i lifecycle najmu | Reguły jednostek, rezerwacji, dokumentów, płatności i dostępu pozostają poza interfejsem i mogą być współdzielone z rdzeniem Rentya. | Więcej integracji i przejść stanu wymaga testowania idempotencji oraz scenariuszy częściowego niepowodzenia. |
| PostgreSQL + Prisma | Spójny model obiektu i najmu | Relacje między jednostką, dostępnością, rezerwacją, klientem i najmem wymagają transakcyjnego źródła prawdy. | Zmiany modelu domenowego wymagają kontrolowanych migracji, szczególnie gdy dotyczą aktywnych najemów. |
| Stripe + Przelewy24 | Płatności online | Wdrożenie wymaga obsługi cyfrowej płatności jako części formalizacji rezerwacji i dalszych rozliczeń najmu. | Status płatności pochodzi z systemu zewnętrznego, dlatego webhooki i ponowienia muszą być bezpieczne. |
| SignFlow / podpis elektroniczny | Formalizacja umowy | Podpis cyfrowy pozwala włączyć dokument najmu do tego samego procesu co rezerwacja i płatność. | Zewnętrzny dostawca podpisu wprowadza asynchroniczne statusy i wymaga obsługi nieukończonych procesów. |
| API kontroli dostępu / IoT | Połączenie z fizycznym obiektem | Aktywny najem musi przekładać się na właściwe uprawnienia w obiekcie bez ręcznego utrzymywania dwóch niezależnych stanów. | Warstwa dostępu musi mieć bezpieczne procedury awaryjne, ponieważ problem integracji nie może automatycznie oznaczać utraty kontroli nad obiektem. |
Integracje i przepływy danych
Stripe / Przelewy24
platforma ↔ operator płatnościAutoryzacja i rejestracja płatności związanych z rezerwacją oraz najmem.
Webhooki muszą być odporne na ponowienia, opóźnienia i zmianę kolejności zdarzeń.
SignFlow
platforma ↔ podpis elektronicznyGenerowanie i podpisywanie dokumentów związanych z formalizacją najmu.
Status dokumentu musi być synchronizowany bez traktowania nieukończonego podpisu jako aktywnego najmu.
Kontrola dostępu / IoT
platforma → uprawnienia obiektu + status zwrotnyNadanie lub odebranie dostępu w zależności od kontrolowanego stanu najmu i decyzji operatora.
Integracja powinna obsługiwać błędy komunikacji, ponowienia i ręczną ścieżkę awaryjną operatora.
Przechowywanie dokumentów
platforma ↔ storageBezpieczne przechowywanie umów i dokumentów powiązanych z konkretną rezerwacją lub najmem.
Rekord domenowy przechowuje referencję i uprawnienia zamiast uzależniać logikę najmu od samego pliku.
AI, bezpieczeństwo i niezawodność
Kontrola dostępu użytkowników
Panel operatora i powierzchnie klienta wymagają rozdzielenia uprawnień do danych oraz operacji.
Idempotentne zdarzenia integracyjne
Powtórzony webhook płatności, podpisu lub dostępu nie powinien tworzyć drugiego skutku biznesowego.
Audit trail zmian
Zmiany statusu rezerwacji, najmu, dokumentu i dostępu powinny pozostawiać historię przydatną przy obsłudze wyjątków.
Ręczna ścieżka awaryjna
Integracja z fizycznym dostępem nie może usuwać możliwości kontrolowanej interwencji operatora.
Stan transakcyjny jako źródło prawdy
Dostępność i aktywny najem wynikają ze wspólnego modelu danych, a nie wyłącznie z cache lub stanu interfejsu.
Realizacja, testy i uruchomienie
- 101 — Analiza obiektu
Odwzorować realną strukturę GizoBOX i sposób obsługi klienta.
- model jednostek indoor/outdoor
- mapa procesu klienta i operatora
- lista integracji i wyjątków
Rezultat: Powstał model wdrożenia oddzielający strukturę obiektu od współdzielonego lifecycle Rentya.
- 202 — White-label i UX
Dopasować klientowską warstwę produktu do marki i fizycznego obiektu.
- branding GizoBOX
- interaktywna mapa jednostek
- flow wyboru i podsumowania rezerwacji
Rezultat: Klient może rozpocząć rezerwację od konkretnej jednostki widocznej w kontekście obiektu.
- 303 — Formalizacja i rozliczenia
Połączyć dokumenty, podpis i płatność z rezerwacją oraz aktywnym najmem.
- integracja płatności
- workflow podpisu
- statusy formalizacji i najmu
Rezultat: Formalizacja stała się kontrolowanym etapem tego samego lifecycle zamiast osobnym procesem.
- 404 — Dostęp i operacje
Połączyć cyfrowy status najmu z operacjami fizycznego obiektu.
- integracja dostępu
- panel operatora
- obsługa wyjątków i historii zmian
Rezultat: Operator otrzymał jedną warstwę kontroli dla jednostek, najmu i działań związanych z dostępem.
- 505 — Testy i rozwój produkcyjny
Sprawdzić cały workflow oraz zachowanie w scenariuszach częściowego niepowodzenia.
- testy end-to-end
- testy integracji i webhooków
- iteracje UX na podstawie użycia
Rezultat: Wdrożenie mogło być rozwijane jako konfiguracja wspólnej platformy, nie jako odrębny fork produktu.
Testy lifecycle
Scenariusze obejmują wybór jednostki, rezerwację, formalizację, płatność, aktywację, zmianę stanu i zakończenie najmu.
Testy integracji
Płatności, podpis oraz dostęp wymagają kontroli webhooków, błędów połączenia i ponowionych zdarzeń.
Testy operatora
Obsługa ręczna i wyjątki są testowane tak, aby operator mógł odzyskać kontrolę bez naruszania spójności danych.
Testy responsywne
Mapa, booking i samoobsługa klienta muszą pozostać użyteczne na desktopie i urządzeniach mobilnych.
Wdrożenie iteracyjne
Rozwój produkcyjny jest prowadzony etapami, co pozwala dopracowywać konfigurację GizoBOX bez kopiowania rdzenia platformy.
Co potwierdza opis projektu
W P1-E2 publikujemy wyłącznie zakres, który można powiązać z rzeczywistymi ekranami GizoBOX, materiałami projektu lub udokumentowanym modelem wdrożenia. Wcześniejsze deklaracje wzrostu konwersji i redukcji czasu obsługi nie są wykorzystywane jako wynik case study, ponieważ repozytorium nie zawiera zatwierdzonego baseline, okresu pomiaru i źródła analitycznego pozwalającego odtworzyć te wskaźniki.
| Zakres | Podstawa | Materiał | Potwierdzenie | Granice wniosku |
|---|---|---|---|---|
| GizoBOX posiada operacyjny panel do obsługi obiektu i procesów najmu. | rzeczywisty ekran produktu | GB-01 — panel operatora | Potwierdzone | Ekran potwierdza istnienie powierzchni operacyjnej, ale nie przedstawia wszystkich ról ani modułów. |
| Wdrożenie wykorzystuje interaktywną mapę do wyboru konkretnej jednostki. | rzeczywisty ekran produktu | GB-02 — mapa obiektu | Potwierdzone | Materiał pokazuje interfejs wyboru i nie opisuje całej logiki dostępności po stronie backendu. |
| Proces zawiera etap podsumowania rezerwacji przed formalizacją. | rzeczywisty ekran produktu | GB-03 — podsumowanie rezerwacji | Potwierdzone | Ekran nie dowodzi automatycznie finalizacji płatności ani podpisu w każdym scenariuszu. |
| Ekosystem GizoBOX obejmuje mobilną powierzchnię samoobsługi klienta. | rzeczywisty ekran produktu | GB-04 — interfejs mobilny | Potwierdzone | Materiał nie oznacza, że wszystkie funkcje panelu operatora są dostępne mobilnie. |
| Jednostki indoor i outdoor mogą być odwzorowane w jednym modelu obiektu. | diagram modelu wdrożenia | GB-05 — model obiektu | Potwierdzone przez klienta | Diagram przedstawia logiczną strukturę opisaną dla wdrożenia i nie ujawnia pełnego technicznego schematu danych. |
| Customer journey prowadzi od wyboru jednostki do aktywnego najmu i dostępu. | diagram procesu | GB-06 — customer journey | Potwierdzone w produkcie | Publiczny diagram pokazuje główną ścieżkę i upraszcza wyjątki, anulowania oraz ręczne decyzje operatora. |
| Cyfrowy stan najmu jest powiązany z warstwą fizycznego dostępu. | diagram architektury wdrożenia | GB-07 — digital ↔ physical | Potwierdzone w produkcie | Diagram nie ujawnia protokołu ani kompletnej topologii infrastruktury kontroli dostępu. |
| Operator zachowuje kontrolę nad wyjątkami w rezerwacji, najmie i rozliczeniach. | diagram workflow | GB-08 — workflow operatora | Potwierdzone w produkcie | Materiał opisuje kategorie decyzji i nie stanowi pełnej instrukcji operacyjnej obiektu. |
| Konfiguracja GizoBOX jest oddzielona od współdzielonego rdzenia Rentya. | diagram white-label | GB-09 — model white-label | Potwierdzone w produkcie | Diagram pokazuje granicę odpowiedzialności na poziomie produktu, a nie pełny układ repozytoriów lub deploymentów. |
| Dokumenty, podpis, płatność i dostęp tworzą kolejne kontrolowane etapy formalizacji najmu. | diagram formalizacji | GB-10 — formalizacja i dostęp | Potwierdzone w produkcie | Kolejność poszczególnych integracji może zależeć od konkretnego wariantu płatności lub obsługi operatorskiej. |
Jak czytać te informacje
- Rzeczywiste ekrany potwierdzają obecność określonych powierzchni produktu, ale nie są samodzielnym dowodem wpływu biznesowego.
- Diagramy GB-05–GB-10 są uproszczonym opisem publicznym i nie ujawniają poufnej topologii produkcyjnej.
- Informacja o jednostkach indoor i outdoor pochodzi z kontekstu wdrożenia i jest prezentowana jako cecha konfiguracji operatora.
- Integracje płatności, podpisu i dostępu są opisywane na poziomie ich roli w procesie, bez ujawniania sekretów lub danych infrastruktury.
- Procentowe KPI wymagają osobnego źródła analitycznego przed ponowną publikacją.
Zmiana procesu, konsekwencje decyzji i wnioski
| Obszar | Przed wdrożeniem | Po wdrożeniu | Wpływ biznesowy |
|---|---|---|---|
| Wybór jednostki | Fizyczna jednostka i informacja sprzedażowa mogą funkcjonować jako osobne konteksty. | Interaktywna mapa prowadzi do konkretnego rekordu jednostki i rezerwacji. | Mniej miejsca na niejednoznaczność pomiędzy tym, co klient wybrał, a tym, co operator obsługuje. |
| Indoor / outdoor | Różne typy magazynów mogą wymagać osobnych sposobów prezentacji i obsługi. | Typ jednostki jest częścią wspólnego modelu obiektu i najmu. | Jeden proces może obsługiwać zróżnicowany fizyczny zasób operatora. |
| Formalizacja | Umowa, płatność i rezerwacja mogą wymagać ręcznego uzgadniania statusów. | Statusy są powiązane z jednym lifecycle rezerwacji i najmu. | Operator ma jeden kontekst do oceny, czy najem może przejść do kolejnego etapu. |
| Dostęp | Uprawnienia fizycznego obiektu mogą być utrzymywane niezależnie od aplikacji najmu. | Warstwa dostępu jest połączona z kontrolowanym stanem najmu i decyzjami operatora. | Zmiany w najmie mogą być odzwierciedlane w operacjach obiektu bez utrzymywania dwóch niezależnych źródeł decyzji. |
| Rozwój produktu | Dostosowanie pod operatora może prowadzić do trwałego forka kodu i rozbieżności produktu. | Konfiguracja GizoBOX pozostaje warstwą na wspólnym rdzeniu Rentya. | Wspólne ulepszenia lifecycle mogą być rozwijane bez utrzymywania całkowicie osobnego produktu. |
Wspólny rdzeń Rentya
- Alternatywa
- Osobny produkt zbudowany wyłącznie dla GizoBOX
- Konsekwencja
- Konfiguracja wymaga jasno zdefiniowanych punktów rozszerzeń zamiast dowolnych zmian w każdym miejscu systemu.
- Uzasadnienie
- Wspólny lifecycle ogranicza duplikację i pozwala rozwijać podstawowy model self storage również dla kolejnych konfiguracji.
Interaktywna mapa jako część booking flow
- Alternatywa
- Lista jednostek bez kontekstu fizycznego
- Konsekwencja
- Mapa zwiększa wymagania dotyczące spójności danych położenia, dostępności i responsywności interfejsu.
- Uzasadnienie
- Dla konkretnego obiektu położenie fizycznej jednostki jest częścią decyzji klienta, a nie wyłącznie dekoracją.
Dostęp powiązany ze stanem najmu
- Alternatywa
- Niezależne ręczne zarządzanie uprawnieniami
- Konsekwencja
- Błąd integracji wymaga procedury awaryjnej i nie może blokować bezpiecznego zarządzania obiektem.
- Uzasadnienie
- Połączenie redukuje liczbę miejsc, w których operator musi ręcznie utrzymywać ten sam stan biznesowy.
Automatyzacja z możliwością przejęcia przez operatora
- Alternatywa
- W pełni automatyczny flow bez ręcznej kontroli
- Konsekwencja
- Panel musi obsługiwać więcej statusów, powodów i decyzji operatorskich.
- Uzasadnienie
- Fizyczny obiekt, płatności i dostęp generują wyjątki, których nie należy maskować przez wymuszanie automatycznego happy path.
Najważniejsze lekcje
- Wdrożenie white-label jest skuteczne wtedy, gdy konfiguracja operatora nie przenika do współdzielonej logiki w sposób utrudniający kolejne aktualizacje.
- Mapa fizycznego obiektu powinna być powiązana z modelem jednostek i dostępnością, a nie funkcjonować jako osobna wizualizacja.
- Dostęp do obiektu należy traktować jako skutek kontrolowanego stanu biznesowego, ale zawsze z bezpieczną ścieżką operatorską.
- Indoor i outdoor nie wymagają dwóch produktów, jeśli cechy jednostki są modelowane jako dane i reguły domenowe.
- Płatność i podpis są procesami asynchronicznymi; lifecycle musi tolerować opóźnienia, retry i częściowe ukończenie.
- Rzeczywiste wdrożenie ujawnia wyjątki, których platformowy model SaaS nie powinien ignorować — to one pomagają rozwijać wspólny rdzeń.
Dla jakich organizacji ten model jest istotny
Operatorzy self storage z obiektem mieszanym
Firmy posiadające jednostki indoor i outdoor, które chcą obsługiwać je w jednym procesie cyfrowym.
Obiekty przechodzące na samoobsługę
Operatorzy, którzy chcą połączyć booking online, dokumenty, płatności i dostęp bez likwidowania panelu kontroli.
Sieci wymagające white-label
Marki potrzebujące własnego frontu, cenników i konfiguracji na wspólnym, rozwijanym rdzeniu platformy.
Firmy integrujące software z fizycznym dostępem
Organizacje, w których decyzja biznesowa w aplikacji powinna przekładać się na uprawnienia do fizycznego zasobu.
Operatorzy modernizujący istniejące procesy
Firmy, które potrzebują warstwy samoobsługi bez utraty możliwości ręcznej obsługi wyjątków i operacji obiektu.
Powiązana wiedza i usługi
Rentya — platforma SaaS self storage
Platformowy rdzeń, na którym oparto model jednostek, rezerwacji i najmu GizoBOX.
Tworzenie aplikacji webowych
Projektowanie paneli operatorskich, portali klienta i aplikacji procesowych.
Tworzenie aplikacji mobilnych
Mobilna samoobsługa klienta korzystająca ze wspólnego lifecycle i API.
Next.js
Frontend dla mapy, rezerwacji, portalu klienta i panelu operatora.
Node.js
Backend dla logiki rezerwacji, najmu, integracji i przejść stanu.
API
Warstwa integracyjna dla płatności, podpisu, dokumentów i kontroli dostępu.
Gizo Rental
Inny przykład połączenia cyfrowego lifecycle z fizycznym zasobem i operacjami operatora.
Aplikacja mobilna self storage — wyszukiwanie i rezerwacja
Materiał rozwijający temat mobilnej ścieżki wyszukiwania i rezerwacji magazynu.
Potrzebujesz systemu dopasowanego do realnego obiektu self storage?
Możemy połączyć booking, jednostki, dokumenty, płatności, samoobsługę klienta i kontrolę dostępu w jednym modelu, a następnie skonfigurować go pod strukturę i proces konkretnego operatora.
Najważniejsze potwierdzone fakty
Poniższe informacje podsumowują potwierdzony zakres produktu i nie zawierają niezatwierdzonych danych o wzroście.
- 1
Softech wdrożył GizoBOX jako osobną implementację white-label dla operatora self storage.
- 2
GizoBOX wykorzystuje współdzielony model Rentya, ale posiada własny branding, strukturę obiektu i konfigurację operatorską.
- 3
Wdrożenie GizoBOX obsługuje jednostki magazynowe indoor i outdoor w jednym modelu rezerwacji i najmu.
- 4
Interaktywna mapa GizoBOX łączy położenie fizycznej jednostki z jej wyborem i rozpoczęciem rezerwacji.
- 5
Proces GizoBOX łączy rezerwację z dokumentami, podpisem, płatnością i aktywnym najmem.
- 6
Panel operatora GizoBOX służy do kontroli jednostek, rezerwacji, najmu, rozliczeń i sytuacji wyjątkowych.
- 7
Warstwa kontroli dostępu może być powiązana ze stanem aktywnego najmu w systemie.
- 8
Rentya i GizoBOX są prezentowane przez Softech jako dwa różne case studies: platforma SaaS i konkretne wdrożenie operatorskie.
- 9
Rzeczywiste ekrany GizoBOX potwierdzają obecność panelu operatora, interaktywnej mapy, podsumowania rezerwacji i interfejsu mobilnego.
- 10
Publiczny case study GizoBOX nie publikuje wcześniejszych procentowych KPI bez zatwierdzonego baseline i źródła analitycznego.
- 11
Architektura GizoBOX oddziela konfigurację operatora od współdzielonego lifecycle najmu Rentya.
- 12
Softech zaprojektował wdrożenie tak, aby automatyzacja nie usuwała możliwości kontrolowanej interwencji operatora.
Materiały wizualne
Diagramy przedstawiają potwierdzony zakres produktu i przepływy opisane w materiale. Nie są makietami ani deklaracją nieudokumentowanych wyników.
FAQ
Czym GizoBOX różni się od Rentya?
Rentya jest wielokrotnego użytku platformowym rdzeniem SaaS. GizoBOX jest konkretnym wdrożeniem white-label, w którym ten model został dopasowany do marki, struktury obiektu, jednostek indoor i outdoor oraz procesów konkretnego operatora.
Czy system obsługuje jednocześnie jednostki indoor i outdoor?
Tak. Wdrożenie odwzorowuje różne typy jednostek w jednym modelu dostępności i najmu, jednocześnie zachowując ich położenie, parametry oraz reguły operatorskie.
Jak klient wybiera konkretny magazyn?
Interaktywna mapa łączy fizyczne położenie jednostki z jej dostępnością i parametrami, dzięki czemu wybór konkretnego magazynu staje się początkiem tego samego procesu rezerwacji.
Czy operator może obsłużyć rezerwację ręcznie?
Tak. Panel operatora pozostaje warstwą kontroli i pozwala obsługiwać sytuacje, które nie powinny być wymuszane wyłącznie przez automatyczny flow klienta.
Jak dokumenty i płatność łączą się z najmem?
Umowa, podpis i płatność są elementami formalizacji rezerwacji. Ich status może warunkować przejście do aktywnego najmu i nadanie odpowiednich uprawnień.
Czy system może integrować się z kontrolą dostępu?
Tak. Wdrożenie przewiduje integrację z warstwą dostępu obiektu, tak aby status aktywnego najmu mógł być powiązany z uprawnieniami klienta.
Czy GizoBOX jest osobnym produktem od Rentya?
GizoBOX jest osobną implementacją operatorską i osobnym wdrożeniem marki. Wspólny rdzeń technologiczny pozostaje częścią platformowego podejścia Rentya.
Czy taki model można dostosować do innego obiektu self storage?
Tak, ale zakres konfiguracji zależy od struktury jednostek, polityki cenowej, płatności, dokumentów, kontroli dostępu i sposobu pracy konkretnego operatora.
