Gizo Rental is a production mobile application and web system designed by Softech for a multi-branch rental process covering access platforms, cranes, forklifts and other equipment. The solution organises the B2B customer journey from searching by technical parameters and reviewing availability through branch selection, geolocation and transport calculation to company verification, documents, electronic signature and payment or pre-authorisation. A shared domain model then moves the order through booking, release, transport, active rental, extension, return and final settlement. This case study describes product scope supported by existing screens, project materials and the system structure. It does not publish unapproved figures for conversion, user numbers, handling-time reduction or cost savings.
Business context and the situation before implementation
Equipment rental is a transactional and operational process in which the buying decision depends simultaneously on equipment parameters, job location, branch availability, transport cost, contractor credibility and financial terms. Gizo needed a self-service channel that remained connected to the operational reality of its branch network.
- The offer includes equipment with different technical parameters, use cases and transport requirements.
- Availability and order feasibility depend on a specific branch and date.
- Transport cost depends on the delivery address, route and business rules.
- A business customer must provide data required for verification, agreement and settlement.
- The operations team needs a shared order state from booking to rental closure.
Before state
Before the process was unified, information was established sequentially: the customer asked about equipment, an employee checked availability, branch and transport, and company data, documents and payment were handled separately. This model increased the number of interactions required to close one order and made the current stage harder for the customer to follow.
- Equipment parameters and availability required manual clarification.
- Transport pricing was separated from equipment and delivery-location selection.
- Contractor data was collected at several points in the process.
- Documents, signature and payment created separate communication paths.
- Release, active rental, extension and return information was not presented to the customer as one continuous journey.
Goals, success criteria and constraints
The work started by mapping the real rental journey and the points where customers and operators make decisions. Rather than reproducing documents one-to-one, the team defined the order model, availability rules, branch responsibility and controlled transitions between stages.
Product goals
- Create a mobile self-service rental channel for B2B customers.
- Connect the technical catalogue with availability and branch logic.
- Automate preliminary transport calculation based on location.
- Guide the customer through verification, documents and payment in one process.
- Create a consistent state model from booking to return and settlement.
- Give the operations team control over exceptions and decisions requiring intervention.
Success criteria
- A customer can find equipment by operational parameters without starting with a phone call.
- The delivery address and date form part of the order before documents are prepared.
- The system can connect an order with a branch and transport rules.
- Company data, signature and payment belong to the same order.
- Each lifecycle stage has an unambiguous status visible in the system.
- Extension and return are handled as controlled transitions rather than free-form notes.
Catalogue complexity
Equipment differs by working height, capacity, weight, drive and attachments, so discovery must use technical data rather than names alone.
Branch-level availability
The same equipment category may be available at another branch or date, affecting feasibility and cost.
Heavy-equipment transport
Distance is not the only factor; pricing must incorporate company rules and allow an operational decision.
B2B process
Before agreement and payment, the system must collect company data and connect it with a specific order.
External dependencies
Geocoding, routes, e-signing and payments are external services, so the flow must account for waiting, failure or retry.
Analysis and product decisions
- Category, specific equipment, date and delivery address were separated as distinct decisions.
- The data needed for a preliminary transport estimate and the point of manual review were defined.
- The contractor data required before agreement preparation was established.
- Document, signature and payment were connected with one order identifier.
- Statuses for booking, release, transport, active rental, extension, return and settlement were designed.
- Exceptions were considered: no availability, branch change, date change, declined payment and document correction.
Solution architecture
The architecture separates customer and operator channels from shared rental logic. The mobile application and web panel use an API responsible for catalogue, availability, branches, transport, contractors, documents, payments and states. Transactional data is stored centrally, while maps, routes, signing and payment are handled as separate dependencies.
- 01Customer channel
Mobile application
Catalogue, technical parameters, date, address, booking, documents, payment and rental status.
React NativeTypeScript - 02Operations channel
Web operations panel
Availability, branch decisions, exceptions, documents, payments and state changes.
ReactMaterial UITypeScript - 03Domain logic
Rental process API
Consistent rules for catalogue, booking, transport, verification and the order lifecycle.
Node.jsPHP - 04Data
Order and availability state
Central customer, equipment, branch, booking, document, payment and change-history data.
PostgreSQL/MySQLRedis - 05External services
Location, documents and settlement
Geocoding, route estimation, electronic signature, payments and file storage.
GeocodingRoute Estimation APIe-SignPayment APIS3/Blob Storage - 06Delivery
Production environment
Containerisation and service separation support releases, monitoring and further module development.
DockerKubernetes
Problems, decisions and implemented capabilities
The customer does not know which model fits the job.
Build discovery around technical parameters and categories.
Filtering by height, capacity, weight, drive and other equipment attributes.
The customer can narrow the offer before contacting a branch.
Availability depends on branch and date.
Connect the offer and booking with an operational location.
Branch selection and branch-aware equipment availability.
The order includes fulfilment-location context from the start.
Transport requires a separate manual calculation.
Make address and route part of the order flow.
Geocoding, route estimation and transport-cost rules.
Customer and operator work with the same location data.
Business-customer data is collected repeatedly.
Create one contractor profile connected with the order.
Company-data form and B2B verification stage.
Documents and payment use a consistent data set.
A paper or email agreement interrupts the mobile journey.
Connect document preparation with electronic signature.
Document generation and e-signing flow attached to the order.
Document status becomes part of the order lifecycle.
Deposit, advance payment or pre-authorisation is arranged outside the system.
Handle financial conditions within the same flow.
Payment and pre-authorisation integration with the booking.
The system can control whether the financial condition is met before release.
Team and customer use different descriptions of the current stage.
Define one rental state model.
States for booking, release, transport, active rental, extension, return and settlement.
Both sides can refer to the same order stage.
Extension and return create timing and financial exceptions.
Treat them as controlled model transitions rather than separate messages.
Extension validation, date change, return and final settlement.
The order history remains complete after the rental has started.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| React Native | Customer application for iOS and Android | One mobile product codebase helps maintain a common flow and interface on both platforms. | Device-dependent functions require testing on both systems and controlled handling of native libraries. |
| React + Material UI | Operations panel and web interfaces | A component-based interface supports complex forms, states and operational views. | Design-system consistency requires discipline as further modules are developed. |
| Node.js / PHP | API and rental-domain logic | The server layer centralises booking, transport, document, payment and state-change rules. | A multi-technology backend requires clearly defined responsibilities and API contracts. |
| PostgreSQL/MySQL + Redis | Transactional data, availability and supporting state | A relational model fits the links between customer, equipment, branch, document, payment and state. | Lifecycle-model changes require safe migrations and compatibility with existing orders. |
| Geocoding + Route Estimation API | Delivery address, branch selection and transport estimate | Location data is needed before a final manual transport offer is prepared. | An external API result is an estimate and must remain subject to the company’s operational rules. |
| Payment API + e-Sign | Financial conditions, documents and remote agreement completion | Connecting these steps completes the B2B self-service journey. | External-service statuses must be mapped to internal order states and handle delay or failure. |
Integrations and data flows
Geocoding and routes
address ↔ route dataDelivery-location normalisation, location comparison and transport-calculation support.
The result is validated by business rules; no response or an ambiguous address requires correction or an operator decision.
Electronic signature
order → document → signature statusRemote completion of documents connected with a specific rental.
The system must distinguish prepared, sent, signed, rejected and correction-required documents.
Payments and pre-authorisations
order ↔ payment providerHandling the financial condition before release and connecting the result with the order.
The returned status is handled independently of the customer screen, and a failed or expired operation can be retried according to rules.
Document storage
system ↔ controlled file storageStorage of agreements and materials connected with the order history.
Files are identified through their order and process-stage relationship, with access separated from the public catalogue.
AI, security and reliability
State consistency
Lifecycle transitions are validated so an order cannot bypass required document, financial or operational stages.
Contractor data
Company data is stored in the context of the account and order and used only by processes that require it.
Integration statuses
Signature and payment are treated as external processes whose result may arrive later or require a retry.
Order history
Rental, date and state changes create a continuous history needed by the customer and operations team.
Exception control
No availability, branch change, document correction and failed payment lead to an explicit decision-required state rather than disappearing into off-system communication.
Implementation, testing and release
- 1Phase 1
Process model and MVP scope
- Rental lifecycle map
- Customer, branch and operator roles
- Exception list and required data
Result: An unambiguous order definition and the stages the application and panel must support.
- 2Phase 2
Catalogue and mobile experience
- Technical-parameter filters
- Equipment detail and date
- Category and branch navigation
Result: The customer can start by matching equipment rather than sending a general enquiry.
- 3Phase 3
Availability, location and transport
- Equipment-to-branch relationship
- Delivery-address geocoding
- Transport-estimation rules
Result: The order contains the data needed to assess availability and logistics before agreement preparation.
- 4Phase 4
Contractor, documents and payment
- Company-data form and validation
- Document generation and signing
- Payment, deposit or pre-authorisation
Result: The principal formal steps belong to one order and have a controlled status.
- 5Phase 5
Rental operations and release
- Release and transport states
- Active rental, extension and return
- Customer and operator scenario testing
Result: The production process moves the order from booking to closure without losing stage history.
Catalogue and availability rules
Parameter filtering, branch relationship and no-availability behaviour were checked.
Addresses and transport
Tests covered valid, incomplete and ambiguous addresses as well as manual-correction scenarios.
Documents and payments
Transitions for preparation, signature, rejection, payment, failure and retry were verified.
Rental lifecycle
Scenarios covered booking, release, active period, date change, extension, return and closure.
Application and panel
Customer and operator flows were checked as one process using shared data.
What confirms the project description
The description was prepared from existing application screens, project materials and the functional system model. Verification concerns implemented processes and capabilities. Quantitative business outcomes are not presented because the repository does not contain an approved analytics export with a baseline, comparison period and data source.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The system includes an equipment catalogue based on technical parameters. | Production screen | GR-01 — equipment catalogue and filters | Confirmed | The material confirms the interface and filtering scope but does not show the complete equipment database. |
| The mobile application connects equipment selection with date, address and booking initiation. | Application screens | GR-02 — equipment detail and mobile flow | Confirmed | The screens do not confirm completed-booking volume or conversion. |
| The interface includes branch selection and equipment categories. | Application screen | GR-03 — branch and mobile catalogue | Confirmed | The material does not confirm the current number of branches or availability level. |
| The customer application and operations panel use shared rental-process logic. | Architecture model | GR-04 — logical solution architecture | Confirmed in the product | The diagram simplifies components and does not disclose confidential infrastructure topology. |
| The order model covers booking, release, active rental, extension, return and settlement. | Process model | GR-05 — rental lifecycle | Confirmed in the product | The diagram confirms designed stages, not the number of orders passing through each one. |
| Delivery address, branch and route rules form part of transport calculation. | Flow model | GR-06 — branch and transport selection | Confirmed in the product | The final price may require an operational decision and is not guaranteed by the route estimate alone. |
| Company verification, documents, signature and payment are connected with one order. | Flow model | GR-07 — verification, documents and payment | Confirmed in the product | The scope describes the product flow without disclosing providers, commercial terms or customer data. |
How to read this information
- Screens confirm that functions exist but do not prove use by a specific number of users.
- Diagrams simplify the architecture and are not customer infrastructure or security documentation.
- Earlier percentages for conversion, handling time and call volume are not published without a source.
- The number of branches and current operational scale should be reconfirmed periodically with the client.
- Impact statements describe process capability change rather than an approved financial result.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Equipment discovery | General enquiry followed by manual parameter clarification. | Catalogue and technical filters available in the application. | The customer starts with a better-matched equipment choice. |
| Branch and availability | Branch and date were established after receiving the enquiry. | Location and availability form part of the booking model. | The order reflects operational feasibility earlier. |
| Transport | Address and transport cost were calculated separately. | Geocoding, route and transport rules are connected with the order. | Customer and operator refer to one location data set. |
| Verification and agreement | Company data and documents moved through separate messages and files. | Contractor profile and document are attached to the order. | The risk of working with inconsistent data is reduced. |
| Payment | The financial condition was confirmed outside the main flow. | Payment or pre-authorisation has a status in the same order. | Equipment release can depend on an explicit financial-process result. |
| Active rental and return | Date changes, extension and return required additional communication. | The lifecycle includes controlled extension, return and settlement stages. | The order history remains complete after fulfilment starts. |
Mobile self-service with operator control
- Alternative
- Fully manual handling or full automation without intervention.
- Trade-off
- Not every case can be completed automatically, so the panel must support exceptions.
- Rationale
- Heavy-equipment rental requires customer convenience and operational accountability.
Automatic branch suggestion with override
- Alternative
- Always use the nearest branch or always decide manually.
- Trade-off
- The system must store both the rule result and final operational decision.
- Rationale
- The nearest location does not always have the right equipment or best transport option.
One lifecycle model
- Alternative
- Separate status lists for app, branch and payment.
- Trade-off
- The model requires precise transition rules and migrations as it evolves.
- Rationale
- A shared state reduces discrepancies between customer, document, payment and operations.
Map-assisted transport estimation
- Alternative
- Manual transport pricing only.
- Trade-off
- The estimate cannot replace company rules or decisions for unusual transport.
- Rationale
- Automated information accelerates order preparation while preserving operational control.
Payment and signature as external integrations
- Alternative
- Manual transfer confirmation and documents sent by email.
- Trade-off
- The system must handle asynchronous statuses, interruptions and retries.
- Rationale
- Integrations enable remote completion without losing the order trail.
Key lessons learned
- In rental software, the product catalogue cannot be separated from availability, location and logistics.
- The delivery address should appear early because it affects branch, transport and order feasibility.
- Contractor data should be collected once and reused in documents, payments and order history.
- Signature and payment need explicit intermediate states; redirecting to an external service does not complete the process.
- Extension and return are part of the product, not merely post-sale operations.
- The greatest value comes from one lifecycle model used by both the customer application and operations team.
Which organisations this model is relevant for
Construction equipment rental
Businesses managing fleets of access platforms, forklifts, cranes, generators and specialist equipment.
Multi-branch networks
Operators for whom equipment location, availability and transport affect every order.
Document-heavy B2B rental
Organisations requiring company verification, agreement, signature and financial conditions before release.
Rental with an active lifecycle
Businesses handling extensions, returns, settlements and changes after service starts.
Digitisation of existing operations
Teams adding a self-service application without losing branch-level process control.
Related expertise and services
Mobile app development
Design and development of production iOS and Android applications connected with business logic.
Web app development
Operations panels, customer portals and systems for complex workflows.
Business process automation
Connecting states, documents, payments and operator actions in controlled processes.
React Native
A shared mobile application layer for iOS and Android with native integration capability.
Node.js
APIs and services supporting transactional processes and external integrations.
Self-storage management system
A related example of digitising rental, documents, payments and operator workflows.
Foodeli — last-mile logistics
An example of a system where location, availability and field operations form one process.
Planning an equipment rental app or operations system?
We can turn catalogue, availability, branches, transport, documents, payments and the rental lifecycle into one coherent mobile and web product.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and implemented a production mobile application and web operations layer for Gizo equipment rental.
- 2
Gizo Rental supports equipment discovery by technical parameters and categories.
- 3
The booking flow connects selected equipment with date, delivery address and branch context.
- 4
The system uses geocoding and route data to support transport calculation.
- 5
The B2B customer flow includes contractor-data collection and validation.
- 6
Documents and electronic-signature status are connected with a specific order.
- 7
The solution supports payment, deposit or pre-authorisation as part of the rental process.
- 8
The shared lifecycle model covers booking, release, transport, active rental, extension, return and settlement.
- 9
The customer application and operations panel use shared rental-domain logic.
- 10
Gizo Rental was built as a multi-channel system covering a mobile application and web interface.
- 11
The public case study does not publish unapproved conversion, user-count or handling-time reduction figures.
- 12
Materials GR-01–GR-07 document the catalogue, mobile application, architecture and key process flows.
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 does the system select a branch for an order?
The delivery address and selected equipment are evaluated against branch-level availability. The system can indicate the relevant branch while allowing the operations team to control the final decision.
How is equipment transport cost calculated?
The address is geocoded and the estimate uses distance or route data together with transport-pricing rules. Detailed tariffs remain configurable within the business model.
Does the application support business customers?
Yes. The flow collects B2B contractor data required for verification, document preparation and payment processing.
Can the agreement and payment be completed remotely?
The solution scope includes preparation of documents for electronic signature and handling of payment, deposit or pre-authorisation according to order rules.
How does the system manage an active rental?
The order moves through controlled states covering reservation, release, transport, the active period, extension, return and settlement.
Can a customer extend a rental?
The lifecycle model includes extension as a separate stage requiring availability, timing and settlement checks.
Does the mobile app work with an operations panel?
Yes. The customer application and web operations layer use shared domain logic so order data and statuses remain consistent.
