Work

Case study

Custom Booking Platform

PlazaCubes — flex-space operator, Düsseldorf

OfficeRnD / Booking / Payments / Multi-location

A public booking website that carries the full journey for meeting rooms, day offices and day passes — discovery, live availability, pricing and checkout — with OfficeRnD kept at the centre of operations through a dedicated application layer.

Client: PlazaCubes, Düsseldorf
Role: Custom development
Platform: OfficeRnD
Scope: Booking / Payments / Middleware
Market: Germany / Europe

PlazaCubes booking website: location listing with filters and the mobile checkout step — bookings.plazacubes.de — live implementation. Real screens; no mock-ups.

The situation

PlazaCubes operates flexible workspace in Düsseldorf with several product types — meeting rooms, day offices and day passes — on an established OfficeRnD setup. The public website was expected to carry the full sales journey. Standard portal behaviour did not provide the desired customer journey.

What we changed

We built a custom booking website connected to OfficeRnD, allowing the public-facing site and the operational platform to work together without forcing customers into a disconnected journey. An application / API layer handles the communication with OfficeRnD and the surrounding services.

Listing page with filters for booking type, date, time, capacity and amenities, and resource cards with live prices — Location discovery and workspace listing — filters for booking type, date, time and capacity; live availability and pricing per resource.

Checkout step one of three: contact details form with the booking summary, date, time window and price including VAT — Booking and checkout flow — selected time window, live price calculation with VAT, then a three-step contact → invoice → payment checkout on the operator's site.

What connects behind the scenes

The website reads availability and pricing through the application layer and writes bookings back to OfficeRnD. Payments, invoicing and notifications hang off the same layer, so the frontend never talks to third-party APIs directly.

System diagram: customer actions flow into the custom website experience, through an application and API layer, into OfficeRnD as source of truth and out to payments, invoicing and notifications — Website and operational workflow. Solid lines: synchronous read/write. Dashed: asynchronous integration.

What we built

Listing and location page driven by OfficeRnD resources, with filters for booking type, date, time, capacity and amenities
Meeting room, day office and day pass products in one browsing experience
Room detail with calendar, time presets and half-hour slots reflecting live availability
Live price calculation including VAT, half-day and full-day tariffs
Three-step checkout — contact, invoice details, payment — on the operator's own domain
Application / API layer between the website and OfficeRnD
Multi-language ready frontend architecture; production deployment and monitoring

Technical considerations

OfficeRnD as source of truth: Resources, availability, members and bookings are read from and written to OfficeRnD. The website never holds a parallel copy that can drift.
Middleware instead of direct calls: An application layer handles authentication, availability and pricing, validation, mapping and caching, so the frontend stays simple and API changes are isolated.
Sales process first: The booking and checkout flow was designed around how the operator actually sells — not around the default portal steps.
Built to extend: New locations, products and languages can be added without rebuilding the customer journey.

The result

The final architecture keeps the operator's branded customer journey on the public website while OfficeRnD remains connected to the underlying operational workflow.