Booking site · Live
Sanovia
A direct booking site for a seven-tent glamping site on the San. The site owns the choosing; Booking.com owns the transaction.
Context & problem
A direct site that cannot take a booking.
Seven tents in a forest on the San, each named after a tree. Guests arrive already interested — from search, from a link, from someone who stayed there — and they need to do two things: choose a tent and a set of dates, and pay.
The property takes payment through Booking.com. It does not take it here.
A direct site under that constraint fails in one of two directions. It becomes a brochure that hands every visitor to a third-party listing where they start the decision over. Or it rebuilds a booking engine it does not own, and drifts out of step with the system that holds the real answer.
The site had to do the part it can do properly, and hand over cleanly at the point where it can't.
Constraints
Four things I did not get to choose.
- Booking.com owns the transaction
- No payment on this site, and no reservation record here. The booking exists only once Booking.com says it does.
- Availability and price are read, not held
- Both come from the Booking.com sync. The site displays them; it is not their source, and it does not get to correct them.
- The extras have no place in the reservation
- Kayak routes, bikes and an outdoor massage are things the property sells. The Booking.com reservation has no field for any of them.
- Seven tents, each named
- The guest is choosing a specific tent, not a room type. Inventory is small enough that the individual tent is the unit of choice.
Solution
Do the choosing here; carry it across.
- 01
Selection happens on this site, payment happens on theirs
The guest picks a tent and a date range here, and arrives at Booking.com with both already applied. The alternative was a link to the property's Booking.com page, which would have discarded every decision the guest had just made and asked for them again in a different interface.
Why it mattersThe guest answers the same two questions once.
- 02
The site proposes a tent; it does not promise one
Availability and price are read from the Booking.com sync rather than stored and maintained here. Nothing about a tent's state is authored on this site, so there is one source of truth rather than two that can disagree. Booking.com returns the conflict on arrival, so the site never promises a tent, it proposes one — availability logic is not duplicated here.
Why it mattersNothing on the page can contradict the system that holds the booking.
- 03
The extras leave the reservation and come back by email
Kayak, bike and massage are captured on this site and arranged by email, because the Booking.com reservation cannot carry them. They sit after the booking decision rather than inside it, so an extra the guest is still thinking about never sits between them and a confirmed stay.
Why it mattersThe property keeps selling the extras without letting them become a reason to abandon the booking.
Impact
What the site changes about the work.
- One decision, carried
- The tent and the dates are chosen once and travel with the guest into a system this site does not control.
- Nothing maintained twice
- Price and availability have a single source. There is no second copy on this site to fall behind.
- Extras stay sellable
- Three add-ons that the reservation cannot hold are still offered, without being placed in the path of the booking.
The claim is narrow. A direct site whose only job is the choosing can still carry the choice into a system it does not own, and can still sell what that system has no field for.
Target audience
Guests booking a short stay direct rather than through a listing, and a property owner running seven tents out of a single Booking.com account.