Rentya to platforma SaaS zaprojektowana przez Softech dla operatorów self storage, którzy potrzebują jednego środowiska do zarządzania lokalizacjami, jednostkami, dostępnością, rezerwacjami, dokumentami, płatnościami i aktywnym najmem. Rdzeń produktu porządkuje lifecycle najmu i udostępnia go w panelu operatora, warstwie samoobsługi najemcy oraz aplikacji mobilnej. Architektura oddziela wspólną logikę domenową od konfiguracji konkretnego operatora, dzięki czemu można zmieniać strukturę obiektów, cenniki, branding i integracje bez przepisywania procesu od początku. Case study opisuje potwierdzony zakres platformy i świadomie nie publikuje wcześniejszych procentowych deklaracji efektywności, dla których w repozytorium nie ma zatwierdzonego baseline ani źródła analitycznego.
Kontekst biznesowy i sytuacja przed wdrożeniem
Self storage łączy sprzedaż internetową z długotrwałą relacją najmu i operacją fizycznego obiektu. Operator musi wiedzieć, które jednostki są dostępne, na jakich warunkach mogą być wynajęte, czy dokumenty i płatności są kompletne oraz jaki jest bieżący status każdego najmu. Rentya powstała jako produktowy rdzeń, który porządkuje te zależności i może być konfigurowany pod różne modele operatorskie.
- Obiekt składa się z lokalizacji, stref i jednostek o własnej dostępności oraz parametrach.
- Rezerwacja musi blokować właściwą jednostkę i przejść do formalizacji najmu.
- Umowa, podpis i płatność należą do tego samego procesu biznesowego co rezerwacja.
- Po aktywacji najmu system nadal obsługuje należności, dokumenty i zmiany statusu.
- Operator i najemca potrzebują różnych interfejsów, ale wspólnego źródła danych.
- Rdzeń SaaS musi pozostawać konfigurowalny dla kolejnych wdrożeń i white-label.
Stan wyjściowy
Bez wspólnego modelu domenowego operator musi łączyć dostępność, dane klienta, dokumenty, płatności i status najmu pomiędzy kilkoma narzędziami lub ręcznymi czynnościami. Każdy dodatkowy kanał — widget, portal klienta czy aplikacja mobilna — zwiększa ryzyko rozbieżności, jeśli nie korzysta z tej samej logiki rezerwacji i najmu.
- Dostępność jednostek może być aktualizowana niezależnie od procesu rezerwacji.
- Dokumenty i rozliczenia mogą żyć poza głównym rekordem najmu.
- Cenniki i rabaty trudno utrzymać spójnie w kilku kanałach sprzedaży.
- Portal klienta bez wspólnego API może prezentować inny stan niż panel operatora.
- Każde kolejne wdrożenie operatorskie zwiększa koszt, jeśli podstawowa logika jest kopiowana zamiast konfigurowana.
Cele, kryteria sukcesu i ograniczenia
Discovery skoncentrowało się na oddzieleniu elementów uniwersalnych dla self storage od elementów zależnych od konkretnego operatora. Zespół rozrysował encje obiektu i jednostki, statusy dostępności, rezerwacji i najmu, punkty formalizacji oraz odpowiedzialność operatora i najemcy. To pozwoliło budować produkt jako konfigurowalną platformę, a nie zestaw ekranów przypisanych do jednego wdrożenia.
Cele produktu
- Zdefiniować jeden model obiektu, jednostki, dostępności, rezerwacji i najmu.
- Połączyć formalizację najmu z dokumentami, podpisem i płatnością.
- Udostępnić wspólny backend dla panelu operatora, portalu najemcy i mobile.
- Zbudować konfigurowalne cenniki, rabaty i reguły wynajmu.
- Zapewnić operatorowi raportowanie dostępności, zajętości, płatności i dokumentów.
- Oddzielić wspólny rdzeń SaaS od brandingu i konfiguracji konkretnego wdrożenia.
Kryteria sukcesu
- Ta sama jednostka nie może być jednocześnie dostępna i zarezerwowana w sprzecznych kanałach.
- Rezerwacja, dokumenty, płatność i aktywny najem mają jednoznaczną relację w danych.
- Panel operatora i samoobsługa klienta odczytują ten sam status najmu.
- Cenniki i reguły można zmieniać bez przebudowy podstawowego workflow.
- Nowe wdrożenie może korzystać ze wspólnego rdzenia przy własnym brandingu i konfiguracji.
- Niepowodzenie zewnętrznej integracji nie może pozostawić procesu w niejednoznacznym stanie.
Złożona struktura obiektów
Operatorzy mogą używać różnych układów lokalizacji, stref, pięter i typów jednostek, dlatego model nie może zakładać jednego schematu obiektu.
Długotrwały lifecycle
Najem trwa dłużej niż pojedyncza transakcja e-commerce i obejmuje należności, przedłużenia, dokumenty oraz zakończenie.
Spójność dostępności
Rezerwacja musi zmieniać stan jednostki tak, aby różne kanały nie oferowały tej samej przestrzeni w sprzeczny sposób.
Zależności płatnicze i dokumentowe
Płatność, podpis i generacja pliku są usługami zewnętrznymi lub asynchronicznymi i wymagają kontrolowanych statusów oraz ponowień.
Konfigurowalność SaaS
Rdzeń produktu musi pozostać wspólny, a jednocześnie pozwalać różnym operatorom zmieniać branding, ceny, strukturę i integracje.
Analiza i decyzje produktowe
- Mapowanie operatora, lokalizacji, stref i jednostek.
- Definicja dostępności i przejść rezerwacji.
- Model aktywnego najmu oraz cyklicznych należności.
- Rozdzielenie interfejsów operatora i najemcy od wspólnego API.
- Identyfikacja konfiguracji white-label: branding, ceny, reguły i integracje.
- Ustalenie miejsc, w których proces musi obsługiwać błąd, retry lub ręczną decyzję.
Architektura rozwiązania
Rentya wykorzystuje wspólny backend domenowy jako źródło prawdy dla kanałów operatorskich i klienckich. Warstwa danych odwzorowuje obiekt, jednostkę, dostępność, rezerwację, najem, dokument i rozliczenie, a integracje zewnętrzne realizują płatności, pliki, komunikację i — zależnie od wdrożenia — dostęp do obiektu.
- 01Kanały operatorskie
Panel zarządzania
Obsługa lokalizacji, jednostek, rezerwacji, najemców, płatności, dokumentów, cenników i raportów.
ReactTypeScript - 02Kanały klienta
Portal i aplikacja
Wyszukiwanie, rezerwacja, dokumenty, płatności i bieżąca obsługa najmu.
ReactReact NativeExpo - 03Rdzeń domenowy
API i lifecycle najmu
Jedno miejsce dla dostępności, rezerwacji, najmu, zasad cenowych i statusów procesu.
NestJSNode.jsREST API - 04Dane
Model transakcyjny
Trwałe relacje operatora, obiektów, jednostek, klientów, dokumentów i rozliczeń.
PostgreSQLPrisma ORMRedis - 05Integracje
Płatności, pliki i usługi zewnętrzne
Usługi niezbędne do formalizacji i obsługi najmu, izolowane od głównego modelu domenowego.
StripeS3 / Blob Storagee-Sign / access integrations - 06Konfiguracja
White-label i reguły operatora
Warstwa brandingu, cenników, struktury obiektu i integracji zależnych od wdrożenia.
Product configurationFeature flags / rules
Problemy, decyzje i wdrożone możliwości
Dostępność jednostek może rozjechać się między kanałami.
Trzymać stan jednostki i rezerwacji w jednym modelu.
Wspólna dostępność dla panelu operatora i kanałów klienta.
Każdy kanał korzysta z tego samego źródła prawdy.
Proces najmu jest dłuższy niż sama rezerwacja.
Zdefiniować lifecycle od dostępności do zakończenia najmu.
Statusy rezerwacji, dokumentów, płatności i aktywnego najmu.
Operator i klient widzą spójny etap procesu.
Cenniki różnią się między jednostkami i operatorami.
Oddzielić reguły cenowe od kodu podstawowego workflow.
Konfigurowalne cenniki, rabaty i promocje.
Oferta może ewoluować bez przebudowy lifecycle najmu.
Dokumenty i płatności często działają w osobnych narzędziach.
Powiązać je bezpośrednio z rezerwacją i najmem.
Generowanie dokumentów, podpis i status płatności w jednym rekordzie procesu.
Formalizacja nie traci kontekstu wybranej jednostki i klienta.
Operator i najemca potrzebują innych interfejsów.
Rozdzielić powierzchnie produktu, ale nie logikę domenową.
Panel operatora, portal najemcy i warstwa mobilna korzystające ze wspólnego API.
Nowy kanał nie wymaga kopiowania reguł najmu.
Każdy operator ma inny branding i część reguł.
Wprowadzić warstwę konfiguracji white-label.
Konfiguracja brandingu, struktury, cenników i integracji.
Wdrożenie może korzystać ze wspólnego rdzenia bez udawania identycznego modelu biznesowego.
Integracja zewnętrzna może odpowiedzieć z opóźnieniem lub błędem.
Modelować status integracji niezależnie od stanu biznesowego.
Kontrolowane oczekiwanie, ponowienie i obsługa błędów płatności, dokumentów i plików.
Awaria usługi zewnętrznej nie musi tworzyć niejednoznacznego najmu.
Decyzje technologiczne
| Technologia | Rola | Uzasadnienie | Konsekwencja wyboru |
|---|---|---|---|
| React + TypeScript | Panele webowe operatora i najemcy | Komponentowy model pozwala rozwijać rozbudowane workflow i współdzielić typy domenowe. | Rozbudowany panel wymaga dyscypliny w zarządzaniu stanem i granicach komponentów. |
| React Native + Expo | Warstwa mobilna najemcy | Jedna baza produktu wspiera iOS i Android przy zachowaniu wspólnego lifecycle. | Integracje zależne od urządzenia wymagają testów na obu platformach. |
| NestJS + Node.js | API i logika domenowa SaaS | Modułowa struktura backendu odpowiada podziałowi na obiekty, najem, płatności i dokumenty. | Granice modułów trzeba utrzymywać konsekwentnie wraz z rozwojem produktu. |
| PostgreSQL + Prisma | Model transakcyjny i relacje najmu | Relacyjna baza dobrze odwzorowuje zależności operatora, jednostki, rezerwacji i płatności. | Zmiany modelu wymagają kontrolowanych migracji i zgodności z historycznymi danymi. |
| Redis | Cache i procesy pomocnicze | Pozwala odciążyć powtarzalne odczyty i obsługiwać krótkotrwałe stany techniczne. | Cache nie może zastępować trwałego źródła prawdy dla najmu. |
| Stripe i usługi dokumentowe | Płatności, formalizacja i pliki | Wydzielone integracje pozwalają łączyć proces biznesowy z wyspecjalizowanymi usługami. | Backend musi obsługiwać webhooks, opóźnienia, retry i idempotencję. |
Integracje i przepływy danych
Stripe
Rentya ↔ dostawca płatnościPłatności online i statusy rozliczeń powiązane z najmem.
Status biznesowy jest aktualizowany po potwierdzonym zdarzeniu, z obsługą ponowień i idempotencji.
Usługa podpisu / dokumentów
Rentya → dokument → podpis / plikFormalizacja warunków najmu w tym samym workflow co rezerwacja.
Proces przechowuje status dokumentu i nie zakłada natychmiastowego sukcesu integracji.
S3 / Blob Storage
Rentya ↔ magazyn plikówPrzechowywanie wygenerowanych dokumentów i materiałów powiązanych z najmem.
Referencje plików pozostają w modelu aplikacji, a dostęp może być kontrolowany niezależnie.
Integracje obiektowe
Rentya ↔ system operatoraOpcjonalne połączenie procesu cyfrowego z dostępem lub inną automatyką konkretnego wdrożenia.
Integracja jest warstwą wdrożeniową i nie zmienia podstawowego modelu jednostki oraz najmu.
AI, bezpieczeństwo i niezawodność
Kontrola dostępu do danych
Role operatora i najemcy otrzymują dostęp tylko do funkcji i danych potrzebnych w danym kontekście.
Spójność statusów
Zmiany dostępności, rezerwacji, płatności i najmu są kontrolowanymi przejściami, a nie niezależnymi flagami interfejsu.
Idempotencja integracji
Powtórzony webhook lub retry nie powinien tworzyć drugiej płatności, dokumentu albo zmiany stanu.
Trwałość danych
Dane transakcyjne i referencje dokumentów pozostają w trwałym modelu niezależnie od cache i procesów pomocniczych.
Rozdzielenie konfiguracji
Branding i reguły konkretnego wdrożenia są oddzielone od wspólnego lifecycle najmu, co ogranicza ryzyko przypadkowego wpływu na inne konfiguracje.
Realizacja, testy i uruchomienie
- 101 — Discovery
Zdefiniować uniwersalny model self storage i granice konfiguracji operatora.
- Mapa encji i relacji
- Lifecycle rezerwacji i najmu
- Zakres panelu operatora i najemcy
Rezultat: Powstał model produktu niezależny od pojedynczego ekranu lub wdrożenia.
- 202 — Rdzeń SaaS
Zbudować API, dane i panel operatorski dla obiektów, jednostek, rezerwacji i najmu.
- Model danych i migracje
- Moduły backendu
- Panel operatorski
Rezultat: Podstawowa logika self storage działa w jednym źródle prawdy.
- 303 — Formalizacja i billing
Połączyć dokumenty, podpis, płatności i cykliczne należności z lifecycle najmu.
- Przepływ dokumentów
- Integracja płatnicza
- Statusy rozliczeń
Rezultat: Rezerwacja może przejść do aktywnego najmu bez utraty kontekstu danych i rozliczeń.
- 404 — Samoobsługa
Udostępnić klientowi web i mobile korzystające ze wspólnej logiki.
- Portal najemcy
- Warstwa mobilna
- Wspólne kontrakty API
Rezultat: Operator i najemca pracują na tym samym stanie najmu w różnych interfejsach.
- 505 — Konfiguracja wdrożeń
Przygotować rdzeń do white-label, zmian cen, brandingu i integracji operatorskich.
- Konfiguracja produktu
- Reguły cenników i promocji
- Punkty integracyjne
Rezultat: Platformę można dostosować do realiów konkretnego operatora bez kopiowania całej logiki najmu.
Testy lifecycle
Scenariusze obejmują przejścia od dostępnej jednostki przez rezerwację, formalizację i płatność do aktywnego oraz zakończonego najmu.
Testy dostępności
Sprawdzane są konflikty rezerwacji, zmiany stanu jednostki i zgodność kanałów korzystających z tego samego API.
Testy integracji
Płatności, dokumenty i pliki są testowane także dla opóźnień, błędów i ponowionych zdarzeń.
Testy konfiguracji
Zmiany brandingu, cen i reguł wdrożenia nie mogą naruszać wspólnego modelu najmu.
Kontrolowane wydania
Zmiany domenowe i migracje danych są wdrażane w sposób kompatybilny z istniejącymi rekordami najmu.
Co potwierdza opis projektu
W P1-E1 celowo nie publikujemy wcześniejszych wartości procentowych przypisanych do Rentya, ponieważ polskie i angielskie etykiety nie opisywały tych samych metryk, a repozytorium nie zawiera zatwierdzonego baseline, okresu pomiarowego ani eksportu analitycznego. Publiczne rezultaty są więc przedstawione jako potwierdzony zakres produktu, relacje domenowe i wdrożone możliwości systemu.
| Zakres | Podstawa | Materiał | Potwierdzenie | Granice wniosku |
|---|---|---|---|---|
| Rentya korzysta ze wspólnej architektury dla kanałów operatora i najemcy. | diagram architektury | RT-01 — diagram architektury produktu | Potwierdzone w produkcie | Diagram opisuje logiczną odpowiedzialność warstw, a nie pełną topologię infrastruktury produkcyjnej. |
| Proces obejmuje rezerwację, formalizację i aktywny najem jako jeden lifecycle. | diagram procesu | RT-02 — lifecycle najmu | Potwierdzone w produkcie | Diagram pokazuje główne stany i nie prezentuje wszystkich wyjątków operatorskich. |
| Model danych rozróżnia operatora, lokalizacje, strefy i jednostki magazynowe. | diagram domenowy | RT-03 — model operatora i obiektu | Potwierdzone w produkcie | Publiczny materiał upraszcza relacje i nie ujawnia pełnego schematu bazy danych. |
| Dokumenty, podpis i płatność są częścią formalizacji najmu. | diagram workflow | RT-04 — płatności i dokumenty | Potwierdzone w produkcie | Materiał nie deklaruje konkretnego dostawcy podpisu dla każdego wdrożenia. |
| Panel operatora, portal najemcy i mobile mogą korzystać z jednego modelu danych. | diagram kanałów | RT-05 — powierzchnie produktu | Potwierdzone w produkcie | Zakres interfejsu może różnić się między konkretnymi konfiguracjami produktu. |
| Platforma oddziela wspólny rdzeń od konfiguracji white-label operatora. | diagram konfiguracji | RT-06 — model white-label | Potwierdzone w produkcie | Diagram potwierdza kierunek architektury produktu, ale nie oznacza, że wszystkie możliwe konfiguracje zostały już wdrożone produkcyjnie. |
Jak czytać te informacje
- Brak zatwierdzonego baseline dla skrócenia czasu obsługi.
- Brak źródła analitycznego dla procentowej redukcji pracy manualnej.
- Brak podstawy do publikacji 100% procesu online jako KPI biznesowego.
- Brak zatwierdzonego testimonialu przypisanego bezpośrednio do produktu Rentya.
- Wdrożenia white-label mogą mieć inny zakres modułów i integracji.
Zmiana procesu, konsekwencje decyzji i wnioski
| Obszar | Przed wdrożeniem | Po wdrożeniu | Wpływ biznesowy |
|---|---|---|---|
| Model danych | Obiekt, jednostka, rezerwacja i rozliczenie mogą żyć w osobnych narzędziach. | Wspólny model domenowy łączy te elementy w jednym lifecycle. | Mniej rozbieżności między kanałami i statusem operacyjnym. |
| Dostępność | Kanał sprzedaży może nie odzwierciedlać aktualnego stanu jednostki. | Rezerwacja i dostępność korzystają ze wspólnego źródła danych. | Spójniejsza prezentacja jednostek operatorowi i klientowi. |
| Formalizacja | Dokument, podpis i płatność są osobnymi krokami poza głównym rekordem. | Każdy element formalizacji jest powiązany z rezerwacją i najmem. | Czytelniejszy stan procesu i mniej ręcznego łączenia danych. |
| Kanały | Każdy nowy interfejs może wymagać osobnej implementacji reguł. | Operator, web najemcy i mobile wykorzystują wspólne API. | Rozwój kolejnych kanałów bez powielania lifecycle najmu. |
| Wdrożenia | Nowy operator oznacza kopiowanie produktu i reguł. | Rdzeń jest oddzielony od warstwy white-label i konfiguracji. | Większa możliwość ponownego wykorzystania architektury produktu. |
Wspólny rdzeń zamiast osobnych aplikacji operatorskich
- Alternatywa
- Budowa niezależnego systemu dla każdego operatora.
- Konsekwencja
- Rdzeń wymaga bardziej rygorystycznego modelowania konfiguracji i granic domenowych.
- Uzasadnienie
- Pozwala rozwijać produkt bez kopiowania podstawowych reguł najmu.
Jedno źródło prawdy dla dostępności
- Alternatywa
- Osobna dostępność w widgetach i panelach.
- Konsekwencja
- Więcej operacji musi przechodzić przez centralne API.
- Uzasadnienie
- Spójność jednostki jest ważniejsza niż lokalna prostota pojedynczego kanału.
Stanowy lifecycle najmu
- Alternatywa
- Luźny zestaw flag i notatek operatorskich.
- Konsekwencja
- Dodanie nowego stanu wymaga świadomej definicji przejść.
- Uzasadnienie
- Długotrwały najem wymaga jednoznacznej historii i warunków biznesowych.
Konfigurowalność white-label
- Alternatywa
- Kodowanie reguł konkretnego operatora bezpośrednio w produkcie.
- Konsekwencja
- Konfiguracja wymaga walidacji i testów kombinacji ustawień.
- Uzasadnienie
- Oddzielenie produktu od wdrożenia zwiększa użyteczność platformy jako SaaS.
Najważniejsze lekcje
- W self storage model jednostki i dostępności powinien powstać przed projektowaniem ekranów sprzedażowych.
- Lifecycle najmu powinien obejmować okres po dokonaniu płatności, a nie kończyć się na checkout.
- Dokumenty i rozliczenia są częścią domeny najmu, nie dodatkowymi modułami bez kontekstu.
- Wspólne API dla operatora i klienta ogranicza rozbieżności pomiędzy kanałami.
- White-label działa najlepiej, gdy konfiguruje model operatorski, a nie kopiuje cały kod produktu.
- Metryki biznesowe należy publikować dopiero po zdefiniowaniu baseline, okresu i źródła danych.
Dla jakich organizacji ten model jest istotny
Operatorzy self storage
Firmy zarządzające jedną lub wieloma lokalizacjami, które chcą połączyć sprzedaż online z operacją najmu.
Sieci rozwijające nowe lokalizacje
Organizacje potrzebujące wspólnego modelu jednostek, cen i najmu przy zachowaniu konfiguracji lokalnej.
Produkty white-label
Firmy chcące wdrażać wspólny rdzeń pod różnymi markami i konfiguracjami operatorskimi.
PropTech z cyklicznym billingiem
Produkty łączące zasób fizyczny, rezerwację, dokumenty i długotrwałe rozliczenie.
Powiązana wiedza i usługi
Tworzenie aplikacji webowych
Architektura paneli operacyjnych i aplikacji SaaS opartych na procesach biznesowych.
Tworzenie aplikacji mobilnych
Warstwa mobilna najemcy korzystająca ze wspólnego backendu i lifecycle produktu.
MVP i rozwój produktu SaaS
Discovery, model domenowy i iteracyjny rozwój produktu od rdzenia do kolejnych modułów.
Next.js / React
Technologie frontendowe dla interfejsów operatora i klienta.
Node.js
Backend dla API, integracji i procesów domenowych platformy.
GizoBOX — wdrożenie white-label
Osobny case study pokaże, jak wspólny model self storage został dopasowany do realiów konkretnego operatora i obiektu.
Gizo Rental
Inny przykład systemu, który łączy samoobsługę klienta z operacyjnym lifecycle fizycznego zasobu.
Aplikacja mobilna self storage — wyszukiwanie i rezerwacja
Materiał opisujący warstwę mobilną i wyszukiwanie ofert w ekosystemie Rentya.
Planujesz własny system do zarządzania self storage?
Możemy pomóc zaprojektować model jednostek, rezerwacji, najmu, płatności i konfiguracji operatorskiej, a następnie przełożyć go na produkcyjny system webowy i mobilny.
Najważniejsze potwierdzone fakty
Poniższe informacje podsumowują potwierdzony zakres produktu i nie zawierają niezatwierdzonych danych o wzroście.
- 1
Softech zaprojektował i rozwija Rentya jako platformę SaaS do zarządzania procesami self storage.
- 2
Rentya modeluje operatorów, lokalizacje, strefy i jednostki magazynowe wraz z ich dostępnością.
- 3
Platforma łączy rezerwację jednostki z dokumentami, podpisem, płatnością i aktywnym najmem.
- 4
Panel operatora, portal najemcy i warstwa mobilna mogą korzystać ze wspólnego API i modelu domenowego.
- 5
Rentya obsługuje konfigurowalne cenniki, rabaty i reguły przypisane do procesu najmu.
- 6
Zakres produktu obejmuje płatności online oraz logikę cyklicznych należności związanych z aktywnym najmem.
- 7
Dokumenty i referencje plików są powiązane z rezerwacją lub najmem, a nie utrzymywane jako osobny proces bez kontekstu.
- 8
Architektura oddziela wspólny rdzeń Rentya od brandingu i konfiguracji wdrożenia white-label.
- 9
GizoBOX jest odrębnym wdrożeniem operatorskim i powinien być prezentowany jako osobny case study, a nie jako synonim platformy Rentya.
- 10
Publiczny case study Rentya nie publikuje wcześniejszych procentowych KPI bez zatwierdzonego baseline i źródła analitycznego.
- 11
Platforma została zaprojektowana z myślą o dalszym rozszerzaniu integracji, reguł biznesowych i kanałów klienta.
Materiały wizualne
Diagramy przedstawiają potwierdzony zakres produktu i przepływy opisane w materiale. Nie są makietami ani deklaracją nieudokumentowanych wyników.
FAQ
Czym Rentya różni się od pojedynczego wdrożenia self storage?
Rentya jest platformowym rdzeniem SaaS. Modeluje obiekty, jednostki, dostępność, rezerwacje, najem, dokumenty i rozliczenia w sposób, który może być konfigurowany pod różne wdrożenia. Konkretna implementacja white-label, taka jak GizoBOX, dodaje własny branding, strukturę obiektu, reguły i integracje.
Czy Rentya obsługuje wiele lokalizacji i różne typy jednostek?
Model produktu zakłada lokalizacje, strefy i jednostki z własną dostępnością, parametrami oraz regułami cenowymi. Pozwala to odwzorować różne układy obiektów bez zmiany podstawowego lifecycle najmu.
Jak wygląda proces najmu w Rentya?
Proces łączy wybór dostępnej jednostki, rezerwację, dane najemcy, dokumenty, podpis, płatność i przejście do aktywnego najmu. Późniejsze zdarzenia, takie jak przedłużenie, należność czy zakończenie, pozostają częścią tego samego modelu.
Czy platforma obsługuje płatności cykliczne?
Tak. Zakres produktu obejmuje płatności online i logikę cyklicznych należności powiązaną z aktywnym najmem i statusem rozliczeń.
Czy można przygotować wdrożenie white-label?
Tak. Architektura rozdziela wspólny rdzeń domenowy od konfiguracji konkretnego operatora, co pozwala dostosować branding, strukturę obiektów, cenniki i wybrane integracje.
Czy najemca ma własny panel i aplikację mobilną?
Rentya obejmuje warstwę samoobsługi najemcy w webie oraz możliwość obsługi mobilnej. Obie powierzchnie korzystają z tego samego modelu rezerwacji, dokumentów, płatności i aktywnego najmu.
Jakie dane operacyjne może obsługiwać platforma?
Zakres obejmuje między innymi dostępność i zajętość jednostek, statusy najmu, płatności, dokumenty, cenniki oraz raportowanie operacyjne i finansowe.
Czy Rentya może integrować się z systemami dostępu?
Architektura przewiduje integracje z zewnętrznymi usługami związanymi z obsługą obiektu, w tym z warstwą kontroli dostępu, jeśli wymaga tego konkretne wdrożenie.
Czy platforma nadaje się do dalszego rozwijania?
Tak. Modułowa architektura pozwala rozwijać nowe reguły biznesowe, raporty, integracje i kanały bez przebudowy całego modelu najmu.
