Booking — NORQ AI Hotel

This is a prototype, and everything on it works except the booking. NORQ AI Hotel is a fictional property. Pick dates, add children and a dog, compare rate plans, go all the way to a reference number — nothing is stored, no payment is taken and no room is held. The rooms, the prices and the calendar behave the way a real property's would. Back to Concierge AI.

Where the assistant hands over

The assistant and this page read the same booking system, so a price said out loud in a phone call is the price on the screen. It carries the conversation across as well: the guest says "two adults and a six-year-old, the last weekend of the month", and the link they are sent — by SMS after the call, or in the chat window — arrives with all of that already filled in, and with the room it recommended already on top.

Try it. Each of these opens this page the way a guest would arrive at it:

The handover is a query string — ?from=…&to=…&adults=2&children=6,9 — which is deliberately boring. Anything that can send a link can start a booking: the voice line, the chat widget, an email, a QR code in the room.

What is already booked

A calendar is only interesting once something is in it. These reservations are seeded into the prototype, which is why next weekend is nearly gone, why the Family rooms vanish over half-term, and why one Tuesday has a single Standard left. They are relative to the day you are reading this, so the demo never shows last month’s bookings.

Beyond what is listed here the calendar is a projection, not a ledger — deterministic, so the same dates always show the same rooms, and seasonal, so December looks like December. Connected to a property management system both the ledger and the projection are replaced by one answer from the system itself, and nothing above that call changes.

What is real here, and what is next

Working today
  • Date range picker with the nightly rate on every date
  • Seasonal and weekend pricing, and a discount for longer stays
  • Adults, children with ages, and pets — each priced, each able to rule a room out
  • Occupancy rules per room type, so a room that cannot take the party is not offered
  • Three rate plans per room: flexible, non-refundable, half board
  • Guest details, a price breakdown and a booking reference
  • English and Polish, and a deep link from the assistant
  • One booking API behind all of it, read by this page and by any assistant
  • Embeddable in one line on any site, isolated from its styling
The next one to two months
  • Live availability and rates from the property management system
  • Writing the reservation back, so the room is actually held
  • Payments and deposits, and the rules about when each is taken
  • Confirmation and reminder emails in the guest's language
  • Promotion codes, packages, and the spa added to a stay
  • A channel manager, so the site does not oversell against the portals
  • Concierge AI calling the booking API inside its own conversations

The split is deliberate. Everything a guest touches is built and can be reviewed now; what remains is integration with whatever system the property already runs, which is the part nobody can scope without seeing it. Tell us what you run and we will.

Putting it on your own site

The widget is one script and one empty element. It draws itself inside a shadow root, so your theme cannot restyle it by accident and it cannot leak styling into your pages — the same build runs here and would run on yours.

<div data-norq-booking data-lang="en"
     data-api="https://api.example.com"
     data-tenant="your-hotel"></div>
<script src="https://www.norq.ai/js/norq-booking.js" defer></script>

The two attributes are the property's booking system. The widget holds no rooms, no prices and no room descriptions of its own — it asks, and draws the answer. Which is also why there is nothing to redeploy when the hotel changes a rate.

One answer, not two

Everything on this page — the nightly rate on each date, the three rate plans, the room descriptions and the photographs — comes from one read-only API the booking system publishes. The widget computes nothing. Neither does the assistant: it calls the same endpoints, which is the only arrangement in which the number a guest is told on the telephone and the number they then see here cannot drift apart.

Assistants that are not ours can call it too, over MCP — a travel agent's, an OTA's, whatever a hotel group runs internally. They ask what is free, and get back a link that books it.

Read-only, on purpose. Nothing here holds a room or takes money: holding is a different verb with different failure modes, and not something an assistant should be able to do by accident. The guest finishes on this page. Tell us what system you run.

Start Your Data Transformation Journey

Discover practical, scalable solutions tailored to your business priorities.