The booking workflow assumed hotels were passive. We built a marketplace that made them active.

Cerbex connects travel brokers — tour operators and destination management companies — with hotels for group bookings. The workflow is more complex than a simple booking: brokers manage multi-city itineraries for groups of travelers, source hotels for each destination, and run a competitive bidding process where multiple hotels offer rates before a winner is selected.

The broker-facing system had been built and refined over time. It handled trip creation, hotel search, request management, and the booking lifecycle. But the hotel side of the marketplace was almost entirely absent — hotels received email notifications, responded through fragmented channels, and had no unified view of their pipeline, their offers, or their confirmed bookings.

The brief when I came on board: build the hotel-facing product from the ground up, and modernize the broker side with AI-native tooling. The scope also included a visual and UX overhaul of the existing hotel request landing page — the lightweight surface hotels use to submit offers without logging into the full UI — bringing it into line with the new booking detail flows and keeping the design language consistent across every surface a hotel might touch. What emerged from the full body of work was something larger than either brief: a structural rethinking of how hotels and brokers relate to each other.

The classic workflow in group hotel booking is sequential: a broker selects specific hotels they know and trust, sends a request for rates, and waits for offers. Hotels sit idle until they're contacted. If a broker doesn't know your hotel, you don't exist in their pipeline.

The insight that came out of iterative conversations between the CEO and his clients was that this constraint was artificial. Brokers don't just want their preferred hotels — they want the best hotel for a specific group at a specific price point. And hotels have empty rooms for dates that match groups they've never heard of. The information existed. The market didn't.

The marketplace concept: hotels can see every group coming to their area — not just the ones they were directly requested for — and choose to make an offer on any of them. Brokers get more competition; hotels get more opportunity. The system becomes active on both sides.

The mental model I kept returning to was a reservations manager mid-shift: phone calls, front desk escalations, a dozen browser tabs. They don't get focused work sessions. They need to triage in thirty seconds.

That question — what decision does this person need to make in the next thirty seconds? — shaped every design choice in the Hotel Center.

The broker workflow before the AI Trip Extractor: a client — often a smaller Asian travel agent — sends a trip description in whatever format they use. An email, a PDF, a Word document, a rough paste of text. The broker opens the Cerbex itinerary builder and manually re-enters every destination, date, room split, and budget, field by field. For a five-city tour with ten room categories, that's a meaningful block of time. And most tour operators run the same trip multiple times a year, each time re-entering data that already exists in a document somewhere.

The AI Trip Extractor makes the conversion automatic. The broker uploads the client's raw document — PDF, Word, Excel, CSV, or plain text — and the system extracts the structured itinerary data and populates the builder directly. Multiple trips in a series (the same route on different departure dates) can be generated simultaneously from a single document, rather than created one by one.

Brokers reported a 10× productivity improvement on trip creation. That number comes from removing the manual conversion step entirely, not from making it faster.

The first version of the Hotel Center exposed the booking lifecycle as brokers experience it: request → offer → booking → confirmation. This made sense from the system's perspective. It was wrong from the hotel's.

A hotel reservations manager doesn't track groups they rejected. The broker cares about the request stage — they sent it, they want visibility. The hotel only wants to track groups they've engaged with: the ones they made an offer on. Surfacing "requested but no offer made" groups in the hotel's pipeline added noise that belonged to the broker's mental model, not the hotel's.

The marketplace concept made this problem more acute and also resolved it. Once hotels could proactively make offers on any group in their area, the distinction between "a broker requested us specifically" and "we found this group on the market" became secondary to the shared question: did we make an offer? Requests from brokers and open-market groups are architecturally distinct in the backend — but in the hotel UI, they surface as the same entity: a group you can offer on, or have offered on.

I didn't erase the distinction entirely. Hotels still get value from knowing when a broker specifically requested them — it signals a prior relationship or a strong fit. So the distinction surfaces in three specific places: a dedicated "Requests" section on the dashboard (separate from the market feed), a "Requested" label on market-page items where relevant, and badge alerts that mirror the email notifications hotels already receive. The distinction is present but it's not the primary organizing logic.

This required conceptual, design, and coding work to reconcile. The backend stays clean — requests and market groups remain distinct entities. The hotel UI presents them as a unified surface. Getting that seam right, without leaking the backend model into the UI or losing information the hotel cares about, was the most technically and conceptually demanding part of the project.

I was product lead, designer, and co-developer on this project across a Python/Postgres/Next.js stack — spanning strategy and roadmap decisions through Figma designs to production code. The development process used Cursor and Claude Code throughout, with the majority of implementation AI-generated under my direction and review.

This isn't a footnote. The ability to move from design decision to working interface to backend integration within the same focused session — without handing off between roles — fundamentally changes the quality of the decisions. When you're the person who will implement it, the design is more honest. You don't spec things that are elegant on paper but painful to build. And when a design decision turns out to have backend implications, you can resolve them in the same thought, not across a two-day feedback cycle.

The AI Trip Extractor, the marketplace concept, the conceptual rethink of the request/offer model — each of these required rapid iteration between product thinking, design, and code. That loop being tight enough to run in real time is what made the project possible at this scope for a team this small.

The Hotel Center is live: dashboard, bookings pipeline, market, team management, offer and confirmation flows. The broker-side AI tooling — the Trip Extractor, hotel data extractor, and series trip creator — is in production. The system is currently in a limited rollout to an initial cohort of hotels, with structured feedback expected shortly.

What I'd do differently: I'd validate the hotel-side mental model earlier, before designing the full pipeline view. The insight that hotels don't track requests they didn't respond to sounds obvious in retrospect — but it only surfaced through design work on the full lifecycle. An earlier, rougher test with a single hotel reservations manager would have caught it before it was built.

I'd also invest earlier in the transition design between market and pipeline. Right now the dashboard carries both surfaces — the hotel's existing bookings and the open market feed — and they sit in separate sections. As the market grows in volume, the relative weighting of those surfaces will need to evolve. The architecture supports it; the UI will need to grow with it.

The marketplace concept is the piece I'm most satisfied with — not because it's technically sophisticated, but because it required questioning an assumption the whole industry takes for granted. Brokers choose hotels; hotels wait. The market makes that relationship genuinely bidirectional. That's worth more than any individual feature.