Spacez
15–20%
Relative lift in search-to-booking conversion, pre/post launch
5% → 35%
Website share of total bookings
45%+
Share of revenue from direct bookings
50%
Less manual handling of guest communication
Three different problems, one failure mode: the guest left the site to ask someone, and the booking went with them.
Overview
Spacez sells premium villas and private stays across Bengaluru and Mumbai. I joined as Associate Product Manager in January 2026 and own the product requirements and retrieval logic for the villa assistant.
Three problems compounded. Search matched keywords and filters, so a guest who wanted a workstay with a pool that took pets had to guess which terms the system indexed. Most bookings arrived through the OTAs, which set the margin and put the guest relationship a step away from us. And an average booking here is worth well above a night on Airbnb or the other platforms, so guests asked whether the rate could come down. It was the most frequent question we received, and one that always needed a person to answer.
All three had the same failure mode. The guest left the site to ask someone, and the question moved to WhatsApp with the booking still unmade.
Outcome
A pre/post comparison after launch showed a 15–20% relative lift in search-to-booking conversion.
Over the same period, pricing and coupon experiments moved website bookings from 5% to 35% of all bookings, and past 45% of revenue.
Pricing and booking-detail questions that previously reached a POC now resolve inside the session, so what escalates to the team is the set of cases needing a decision rather than the standing questionnaire.
Guest communication for check-in, check-out and property updates moved onto an n8n workflow, cutting manual handling by half.
Scoped to the three reasons guests left
Retrieval is hybrid. Semantic search alone drifts on values that have to match exactly, such as a property name, a locality or a bedroom count, while keyword search alone misses anything phrased as a preference. BM25 handles the literal half and embeddings the intent half.
Scope mattered more than ranking. The assistant covers property queries, live offers and ticket escalation, because those were the three reasons a guest left to message someone.
For offers, it reads the coupon system directly rather than a fixed script: it pulls the discount codes active at that moment, filters to the ones valid for the stay being viewed, and returns the combination giving the largest usable saving. A guest asking for a better rate gets the best rate the site can offer, in the same session.
For anything it cannot resolve, such as a negotiation beyond the published discounts or a booking detail with no source, it hands the thread to the POCs and business executives who own guest interactions. Answering the routine questions in place is what keeps that queue small.
Pricing ran as a separate track. Coupon and price tests were measured on booking share rather than click-through, so the reported number matched the business objective.
Reflection
The temptation with a retrieval feature is to keep tuning ranking. The decisions that moved conversion were about scope, putting offers and escalation inside the assistant rather than beside it, and defining the pre/post comparison before the build so the result could be measured rather than argued afterwards.