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.
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.
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.
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.
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.
Discover practical, scalable solutions tailored to your business priorities.