Spacez One: Console

Spacez One: Console is the property management system, the place a booking is supposed to be true. Before it, reservations reached Spacez from Airbnb, from Booking.com, from MakeMyTrip, from the website, and from whatever Spacez Captains recorded on the ground. Each channel kept its own version of the guest, the dates and the state of the stay.

That is survivable at a handful of properties and stops being survivable quickly. Nobody could answer what occupancy actually was, which stay a complaint belonged to, or whether a night had been double-sold, without someone opening five tabs and forming an opinion.

Not one engineering ticket was raised for the Console. The flow map, the mobile-web strategy, the screen-by-screen wireframes, the schema and all 42 modules are one person’s work, which is why the decisions below are as much about data shape as about interface.

7,800+ historical bookings were consolidated into a single property management system, with Airbnb, Booking.com, MakeMyTrip, the website and Spacez Captains all integrated into it. Reservation intake, guest records and issue routing run through one path now instead of five.

On top of it I built MIS dashboards tracking revenue, occupancy, unit economics and funnel metrics, the reporting layer that pricing and supply decisions are made from.

The order was the decision. Integrating the live channels first would have meant a system that was correct going forward and useless for any question about the past, and every pricing or supply question is a question about the past.

So the 7,800+ historical bookings were consolidated first, which forced the reconciliation problems into the open early: the same guest under three spellings, overlapping stays, channels disagreeing on a date. Resolving those defined what the schema actually had to survive before any live integration depended on it.

Only then did the channels get wired in, each one mapping into the shape the backfill had proven. Spacez Captains joined as a first-class source rather than an afterthought, so what happened at the property landed in the same record as the booking that caused it.

The hardest of those reconciliations was the least glamorous. A booking records where it came from, and that field had been typed by hand for years: four separate Airbnb accounts, a website booking marked as a repeat, an Airbnb guest who eventually booked direct, and two plain misspellings. Twenty-five spellings for fifteen real channels.

Operations is not at a desk. The Console is where a ticket gets raised, commented on and closed, and the people doing that are moving between 50+ properties. In a browser tab nothing reaches them, so a ticket only exists once somebody remembers to go and look for it.

The default answer is a native app: a second codebase, a second release cycle, and a store review sitting between every fix and the people waiting on it. The Console had no engineering tickets behind it, so that second codebase would have landed on the same person building the other 42 modules. The office would have run one version and the field another.

So the app is a shell around the live site. It gives up what a hand-built native app does better, and buys the one thing that mattered here: a single deploy updates the website and both store listings at once, with nothing to resubmit.

What the shell adds is the part a tab could not. Ticket comments and 24-hour overdue alerts arrive as notifications, tapping one opens that ticket, and the session survives a force quit.

Consolidation looks like an engineering chore until you notice every decision upstream of it is being made on numbers nobody can defend. The dashboards were the visible output; the schema arguments during the backfill were the actual work.