GizoBOX is a production white-label implementation delivered by Softech for a self-storage operator. Rather than building a separate system from scratch, the team reused the shared Rentya model and adapted it to a specific facility, brand and operating workflow. The implementation represents indoor and outdoor storage units, an interactive facility map, availability, booking, documents, signature, payment, active rental and access control. The core challenge was therefore not simply delivering screens but connecting the customer's digital journey with the real state of physical units and facility operations. The public case study presents the confirmed implementation scope and actual product screens, while earlier percentage-based KPIs remain unpublished without an approved methodology and analytics source.
Business context and the situation before implementation
GizoBOX operates a physical self-storage facility where digital booking must correspond with the real availability of a specific unit. Operations cover units with different characteristics and positions, the customer's relationship with the GizoBOX brand, rental formalisation, billing and facility access. The implementation therefore needed to work at the same time as a sales channel, an operations system and a layer connecting data with a physical service.
- A storage unit is a physical asset assigned to a specific position within the facility.
- The deployment covers indoor and outdoor units within one booking and rental model.
- A customer should see a specific unit, its attributes, availability and conditions before formalisation begins.
- The operator needs control of the workflow and a way to handle exceptions manually.
- Documents, payment and access must refer to the same active rental.
- Branding and customer communication are specific to GizoBOX even though the shared Rentya core is reused.
Before state
Without a shared implementation model, customer, operator and physical facility can operate in separate contexts: a unit can be selected independently of a booking, documents can live outside payment, and access can require a separate decision. The objective was to connect these dependencies in one controlled lifecycle while keeping operator intervention where full automation is not appropriate.
- Disconnected unit, booking and tenant information increases the risk of inconsistent state.
- A facility map without availability data makes self-service selection of a specific unit difficult.
- Documents and payment outside the rental lifecycle create additional operator-control work.
- Physical access should not be activated solely from a customer's declaration.
- Indoor and outdoor units need a shared model while retaining different operational attributes.
Goals, success criteria and constraints
Discovery focused on translating a real facility into a digital operating model. The team separated physical structure from the rental lifecycle, mapped operator-intervention points and identified which elements could remain shared with Rentya and which needed GizoBOX-specific configuration. Particular attention was given to making the unit map an entry point into booking rather than a decorative visualisation.
Product goals
- Represent the physical facility layout and specific units in the customer interface.
- Connect unit availability with the start of a booking.
- Keep documents, payment and active rental within one lifecycle.
- Connect rental state with the facility access layer.
- Give the operator a panel for bookings, rentals and exception handling.
- Adapt branding, communication and deployment rules to GizoBOX without duplicating the product core.
Success criteria
- The selected unit remains explicitly connected with the booking and rental.
- Indoor and outdoor units use one availability model.
- The customer journey moves from map to formalisation without re-entering data across separate systems.
- Active access can depend on rental and settlement state.
- The operator can take control of the workflow in exception scenarios.
- GizoBOX configuration remains separated from the shared Rentya logic.
Physical facility
System state must correspond with real units and their positions; incorrect availability is not merely a user-interface problem.
Indoor and outdoor
Different unit types need one lifecycle without losing attributes important to a specific position or storage type.
Physical access
Facility permission should derive from a controlled rental state, while the integration must preserve exception handling.
White-label without a fork
GizoBOX branding and configuration should not require maintaining a separate copy of the complete rental logic.
Payments and documents
Formalisation requires synchronising state with external services and handling delayed or repeated webhooks.
Analysis and product decisions
- The facility structure, unit types and information required for presentation were defined.
- Map position was connected with the unit record and its availability state.
- The customer journey was mapped from storage-unit selection to active rental.
- Automatic workflow transitions were separated from decisions requiring operator control.
- The boundary between GizoBOX configuration and the shared Rentya lifecycle was defined.
- Dependencies on payments, signature, documents and access control were mapped.
- Scenarios for arrears, cancellation, payment retry and access-state changes were included.
Solution architecture
The implementation architecture separates GizoBOX customer surfaces and facility-specific configuration from the shared Rentya rental logic. Customer interface and operator panel use one API and data model for units, availability, bookings, documents, payments and rentals. An integration layer connects this state with signature, payments, document storage and access control in the physical facility.
- 01Customer
GizoBOX white-label experience
Facility map, unit selection, booking, formalisation, payment and rental self-service.
Next.jsTypeScriptResponsive UI - 02Operator
GizoBOX operations panel
Units, availability, bookings, rentals, documents, settlements, reporting and exceptions.
Next.jsTypeScriptRole-based UI - 03Shared core
Rentya rental lifecycle
Unit, booking, rental, document, payment and state-transition logic shared with the SaaS platform.
NestJSPrismaAPI - 04Data
Unit and rental state
Central model for operator, facility, units, customers, bookings, payments, documents and operational history.
PostgreSQLObject storage - 05Integrations
Payment, signature and access
External services formalise booking and translate controlled rental state into actions outside the application.
StripePrzelewy24SignFlowIoT / access API - 06Configuration
GizoBOX configuration layer
Branding, facility structure, unit types, pricing, communication and rules specific to the operator.
White-label configFacility rulesContent
Problems, decisions and implemented capabilities
A customer must choose a specific unit in a physical facility.
Connect the interactive map directly with unit records.
Map showing units together with position, attributes and availability.
Physical-unit selection becomes the start of the same booking workflow rather than a separate operator enquiry.
Indoor and outdoor units have different characteristics but the operator needs one rental process.
Model unit type and attributes as configuration within the shared lifecycle.
Shared availability and booking for indoor and outdoor units while retaining their attributes.
The operator does not need two separate workflows merely because the units have different physical forms.
A booking without documents and payment is not yet an active rental.
Treat formalisation as a controlled state transition.
Agreement, signature, payment and booking state connected with one rental record.
The system can distinguish interest, a reserved unit and a rental ready for activation.
Access to the physical facility should not be independent of rental state.
Connect the access-control layer with controlled operational states.
Access-permission integration with active rental and state-change handling.
The digital lifecycle can govern when a customer should receive or lose facility permission.
Full automation will not cover every facility exception.
Keep the operator panel as a decision and control layer.
Manual handling of bookings, states, payments, documents and exceptions.
The team can intervene without bypassing the data model or running a parallel process outside the system.
An operator-branded deployment can lead to maintaining a separate product fork.
Separate GizoBOX configuration from shared Rentya logic.
White-label branding, facility structure, pricing and integrations without duplicating the core lifecycle.
Changes to the core rental model can evolve as part of the shared platform rather than a single deployment.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Next.js + TypeScript | Customer and operator interfaces | A component-based frontend enables shared booking and panel patterns while retaining GizoBOX branding and context. | The white-label layer requires discipline in separating configuration from shared component behaviour. |
| NestJS / Node.js | API and rental lifecycle | Rules for units, bookings, documents, payments and access stay outside the interface and can be shared with the Rentya core. | More integrations and state transitions require testing idempotency and partial-failure scenarios. |
| PostgreSQL + Prisma | Consistent facility and rental model | Relationships between unit, availability, booking, customer and rental require a transactional source of truth. | Domain-model changes require controlled migrations, especially when active rentals are involved. |
| Stripe + Przelewy24 | Online payments | The deployment requires digital payments as part of booking formalisation and ongoing rental settlement. | Payment state comes from an external system, so webhooks and retries must be handled safely. |
| SignFlow / electronic signature | Agreement formalisation | Electronic signing keeps the rental document in the same workflow as booking and payment. | An external signature provider introduces asynchronous states and requires handling incomplete workflows. |
| Access-control API / IoT | Connection with the physical facility | Active rental needs to translate into appropriate facility permissions without manually maintaining two independent states. | The access layer needs safe fallback procedures because an integration issue cannot automatically mean losing control of the facility. |
Integrations and data flows
Stripe / Przelewy24
platform ↔ payment providerAuthorisation and recording of payments related to booking and rental.
Webhooks must tolerate retries, delays and events arriving out of order.
SignFlow
platform ↔ electronic signatureGenerating and signing documents related to rental formalisation.
Document state must be synchronised without treating an incomplete signature as an active rental.
Access control / IoT
platform → facility permissions + status feedbackGranting or revoking access according to controlled rental state and operator decisions.
The integration should handle communication failures, retries and an operator-controlled fallback path.
Document storage
platform ↔ storageSecure storage of agreements and documents connected with a specific booking or rental.
The domain record keeps the reference and permissions instead of making rental logic depend on the file itself.
AI, security and reliability
User access control
Operator panel and customer surfaces require separation of permissions for data and actions.
Idempotent integration events
A repeated payment, signature or access webhook should not create a second business effect.
Change audit trail
Changes to booking, rental, document and access state should leave a history useful for exception handling.
Operator fallback path
Integration with physical access cannot remove the possibility of controlled operator intervention.
Transactional state as source of truth
Availability and active rental derive from the shared data model rather than cache or interface state alone.
Implementation, testing and release
- 101 — Facility analysis
Represent the real GizoBOX facility structure and customer workflow.
- indoor/outdoor unit model
- customer and operator workflow map
- integration and exception list
Result: An implementation model was created that separates facility structure from the shared Rentya lifecycle.
- 202 — White-label and UX
Adapt the customer layer to the brand and physical facility.
- GizoBOX branding
- interactive unit map
- selection and booking-summary flow
Result: A customer can start booking from a specific unit shown in the facility context.
- 303 — Formalisation and settlement
Connect documents, signature and payment with booking and active rental.
- payment integration
- signature workflow
- formalisation and rental states
Result: Formalisation became a controlled stage of the same lifecycle rather than a separate process.
- 404 — Access and operations
Connect digital rental state with physical-facility operations.
- access integration
- operator panel
- exception and change-history handling
Result: The operator gained one control layer for units, rentals and access-related actions.
- 505 — Testing and production development
Validate the complete workflow and behaviour under partial-failure scenarios.
- end-to-end tests
- integration and webhook tests
- UX iterations based on use
Result: The deployment could continue evolving as a configuration of the shared platform rather than a separate product fork.
Lifecycle tests
Scenarios cover unit selection, booking, formalisation, payment, activation, state changes and rental termination.
Integration tests
Payments, signature and access require testing webhooks, connection failures and repeated events.
Operator-workflow tests
Manual handling and exceptions are tested so the operator can regain control without breaking data consistency.
Responsive tests
Map, booking and customer self-service need to remain usable across desktop and mobile devices.
Iterative release
Production development is delivered iteratively, allowing GizoBOX configuration to evolve without copying the platform core.
What confirms the project description
P1-E2 publishes only scope that can be connected with actual GizoBOX screens, project materials or the documented implementation model. Earlier claims about conversion growth and reduced handling time are not used as case-study outcomes because the repository does not include an approved baseline, measurement period and analytics source that would allow those metrics to be reproduced.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| GizoBOX has an operations panel for facility and rental workflows. | actual product screen | GB-01 — operator dashboard | Confirmed | The screen confirms the operations surface but does not show every role or module. |
| The implementation uses an interactive map to select a specific storage unit. | actual product screen | GB-02 — facility map | Confirmed | The material shows the selection interface and does not expose the complete backend availability logic. |
| The workflow includes a booking-summary stage before formalisation. | actual product screen | GB-03 — booking summary | Confirmed | The screen does not by itself prove payment or signature completion in every scenario. |
| The GizoBOX ecosystem includes a mobile customer self-service surface. | actual product screen | GB-04 — mobile interface | Confirmed | The material does not imply that all operator-panel features are available on mobile. |
| Indoor and outdoor units can be represented within one facility model. | implementation model diagram | GB-05 — facility model | Confirmed by the client | The diagram represents the logical implementation structure and does not disclose the complete technical data schema. |
| The customer journey progresses from unit selection to active rental and access. | process diagram | GB-06 — customer journey | Confirmed in the product | The public diagram shows the primary path and simplifies exceptions, cancellations and manual operator decisions. |
| Digital rental state is connected with the physical access layer. | implementation architecture diagram | GB-07 — digital ↔ physical | Confirmed in the product | The diagram does not disclose the protocol or complete topology of the access-control infrastructure. |
| The operator retains control over booking, rental and settlement exceptions. | workflow diagram | GB-08 — operator workflow | Confirmed in the product | The material describes decision categories and is not a complete facility operating manual. |
| GizoBOX configuration is separated from the shared Rentya core. | white-label diagram | GB-09 — white-label model | Confirmed in the product | The diagram shows the product-level responsibility boundary rather than the complete repository or deployment layout. |
| Documents, signature, payment and access form controlled stages of rental formalisation. | formalisation diagram | GB-10 — formalisation and access | Confirmed in the product | The exact order of individual integrations can depend on the payment method or operator-handling variant. |
How to read this information
- Actual screens confirm the presence of specific product surfaces but are not standalone proof of business impact.
- GB-05–GB-10 diagrams are simplified public representations and do not disclose confidential production topology.
- The indoor and outdoor unit information comes from the implementation context and is presented as an operator-configuration attribute.
- Payment, signature and access integrations are described by their workflow role without exposing infrastructure secrets or sensitive data.
- Percentage-based KPIs require a separate analytics source before they can be republished.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Unit selection | The physical unit and sales information can exist as separate contexts. | The interactive map leads to a specific unit record and booking. | Less ambiguity between what the customer selected and what the operator manages. |
| Indoor / outdoor | Different storage types can require separate presentation and handling. | Unit type is part of the shared facility and rental model. | One workflow can support a diverse physical inventory. |
| Formalisation | Agreement, payment and booking can require manual state reconciliation. | States are connected within one booking and rental lifecycle. | The operator has one context for deciding whether a rental can progress. |
| Access | Physical-facility permissions can be maintained independently of the rental application. | The access layer is connected with controlled rental state and operator decisions. | Rental changes can be reflected in facility operations without maintaining two independent decision sources. |
| Product evolution | Operator customisation can lead to a permanent code fork and product divergence. | GizoBOX configuration remains a layer on the shared Rentya core. | Shared lifecycle improvements can evolve without maintaining a completely separate product. |
Shared Rentya core
- Alternative
- A separate product built only for GizoBOX
- Trade-off
- Configuration requires clearly defined extension points rather than arbitrary changes throughout the system.
- Rationale
- A shared lifecycle reduces duplication and allows the core self-storage model to evolve for additional configurations.
Interactive map as part of booking
- Alternative
- A unit list without physical context
- Trade-off
- The map increases requirements for consistency of position, availability and responsive behaviour.
- Rationale
- For a specific facility, physical unit position is part of the customer's decision rather than decoration.
Access connected with rental state
- Alternative
- Independent manual permission management
- Trade-off
- An integration failure requires a fallback procedure and cannot prevent safe facility management.
- Rationale
- The connection reduces the number of places where the operator must manually maintain the same business state.
Automation with operator takeover
- Alternative
- A fully automatic workflow without manual control
- Trade-off
- The panel must support more states, reasons and operator decisions.
- Rationale
- A physical facility, payments and access create exceptions that should not be hidden by forcing an automatic happy path.
Key lessons learned
- A white-label deployment works best when operator configuration does not leak into shared logic in a way that makes future updates difficult.
- A physical facility map should be connected with the unit model and availability rather than exist as an isolated visualisation.
- Facility access should be treated as a consequence of controlled business state while retaining a safe operator fallback path.
- Indoor and outdoor units do not require two products when unit characteristics are modelled as domain data and rules.
- Payment and signature are asynchronous processes; the lifecycle must tolerate delay, retries and partial completion.
- A real implementation exposes exceptions that the reusable SaaS model should not ignore, and those exceptions help improve the shared core.
Which organisations this model is relevant for
Self-storage operators with mixed facilities
Businesses with indoor and outdoor units that want to manage them within one digital workflow.
Facilities moving to self-service
Operators that want to connect online booking, documents, payments and access while retaining an operations control panel.
Operators requiring white-label deployment
Brands that need their own frontend, pricing and configuration on a shared, evolving platform core.
Businesses connecting software with physical access
Organisations where a business decision in software should translate into permissions for a physical asset.
Operators modernising existing workflows
Businesses that need self-service without losing manual control of exceptions and facility operations.
Related expertise and services
Rentya — self-storage SaaS platform
The platform core behind the unit, booking and rental model used by GizoBOX.
Web application development
Design and development of operator panels, customer portals and workflow applications.
Mobile app development
Mobile customer self-service using the shared lifecycle and API.
Next.js
Frontend for facility map, booking, customer portal and operator panel.
Node.js
Backend for booking, rental, integration and state-transition logic.
API
Integration layer for payments, signature, documents and access control.
Gizo Rental
Another example of connecting a digital lifecycle with a physical asset and operator workflows.
Self-storage mobile app — search and booking
Article expanding on the mobile search and storage-booking journey.
Need a self-storage system adapted to a real facility?
We can connect booking, units, documents, payments, customer self-service and access control within one model, then configure it for the structure and workflows of a specific operator.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech delivered GizoBOX as a separate white-label implementation for a self-storage operator.
- 2
GizoBOX uses the shared Rentya model while retaining its own branding, facility structure and operator configuration.
- 3
The GizoBOX implementation handles indoor and outdoor storage units within one booking and rental model.
- 4
The interactive GizoBOX map connects the physical position of a unit with selection and the start of booking.
- 5
The GizoBOX workflow connects booking with documents, signature, payment and active rental.
- 6
The GizoBOX operator panel is used to control units, bookings, rentals, settlements and exception scenarios.
- 7
The access-control layer can be connected with active-rental state in the system.
- 8
Rentya and GizoBOX are presented by Softech as two different case studies: a SaaS platform and a specific operator implementation.
- 9
Actual GizoBOX screens confirm the presence of an operator panel, interactive map, booking summary and mobile interface.
- 10
The public GizoBOX case study does not publish earlier percentage-based KPIs without an approved baseline and analytics source.
- 11
The GizoBOX architecture separates operator configuration from the shared Rentya rental lifecycle.
- 12
Softech designed the implementation so automation does not remove controlled operator intervention.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
How is GizoBOX different from Rentya?
Rentya is the reusable SaaS platform core. GizoBOX is a specific white-label implementation in which that model was adapted to the brand, facility structure, indoor and outdoor units and workflows of a particular operator.
Can the system handle indoor and outdoor units together?
Yes. The implementation represents different unit types within one availability and rental model while retaining their location, attributes and operator-specific rules.
How does a customer choose a specific storage unit?
An interactive map connects the physical position of a unit with its availability and attributes, making the specific-unit selection the beginning of the same booking process.
Can the operator create or manage bookings manually?
Yes. The operator panel remains a control layer for situations that should not be forced through customer self-service alone.
How are documents and payments connected with the rental?
Agreement, signature and payment are parts of booking formalisation. Their state can determine progression to an active rental and the related permissions.
Can the implementation integrate with access control?
Yes. The deployment supports integration with the facility access layer so active-rental state can be connected with customer permissions.
Is GizoBOX a separate product from Rentya?
GizoBOX is a separate operator implementation and branded deployment. The shared technology core remains part of the Rentya platform approach.
Can this model be adapted to another self-storage facility?
Yes, but the configuration scope depends on unit structure, pricing policy, payments, documents, access control and the operating model of the specific facility.
